[Mono-bugs] [Bug 79112][Wis] Changed - HttpListenerRequest.InputStream.Read blocks indefinitively

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sun Aug 20 17:26:34 EDT 2006


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by miguel at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=79112

--- shadow/79112	2006-08-20 17:10:39.000000000 -0400
+++ shadow/79112.tmp.8079	2006-08-20 17:26:34.000000000 -0400
@@ -173,6 +173,31 @@
                 Console.WriteLine ("Done");
         }
 }
 
 I instrumented bits of the code, this is using the non-chunked code
 path which might be responsible for this.
+
+------- Additional Comments From miguel at ximian.com  2006-08-20 17:26 -------
+Commited a fix, but I want Gonzalo to review one of my changes:
+
+	The bug fix is that we update the "available" variable as soon as
+	we consume data from Read, this means that a second call into Read
+	wont block.   Available was only being updated on a secondary code
+	path, now we alwaysupdate it after using FillFromBuffer.
+
+	The second component is what I believe the right behavior should
+	be.  There was a check for "if count > available" that set count
+	to available in that case.   The idea was to limit the data read
+	from the buffer that belonged to this particular request, to allow
+	pipelining. 
+
+	But this test was done after FillFromBuffer, which assumed that
+	all the data held in the buffer (the one used by FillFromBuffer)
+	must belong to the this request, and only future data did not.
+
+	I think my change is correct, but it assumes that the initialized
+	RequestStream will be used for other pipelined HTTP requests,
+	which is not something am 100% sure of, so Gonzalo needs to check
+	this. 
+
+


More information about the mono-bugs mailing list