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=73048 --- shadow/73048 2005-02-27 06:45:00.000000000 -0500 +++ shadow/73048.tmp.18183 2005-03-17 02:46:33.000000000 -0500 @@ -97,6 +97,45 @@ problem.. hmm. ------- Additional Comments From [EMAIL PROTECTED] 2005-02-27 06:44 ------- Oh, wait. Tomorrow i'll test with IE. I remember from another bug that IE sends 2 extra bytes '\r\n'. That might be the problem... + +------- Additional Comments From [EMAIL PROTECTED] 2005-03-17 02:46 ------- +I had the same problem with IE and I did a network trace with +Ethereal. In the request that fails, IE's behaviour looks rather +strange. It sends the HTTP post request and then -immediately- sends +TCP FIN without waiting for a reply. + +Looking at the successful response before it, we see the reason why. +XSP sends back a 200, followed by the data. Right after that, as part +of the same request, it sends back a 400. The exact data that causes +the bad response is indeed an empty CRLF pair. + +The entire HTTP request looks to be within two packets. I saved the +data from the packets here: + + http://patearl.net/files/ie_packets.txt + +I wrote a quick work-around to get things going on my end. Here's the +synopsis: + +In InitialWorkerRequest: + +bool GetRequestLine () { + string req = null; + try { + req = ReadLine (); + } catch { + } + if (req == null) return false; + req = req.Trim (); + + // ADDED THESE LINES + if (req == "") { + gotSomeInput = false; + return false; + } + +It works for me, but I didn't really analyze if it was always correct. + The data from the packets may provide some illumination. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
