[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