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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. + + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
