[Mono-bugs] [Bug 73048][Nor] Changed - XSP gives an error occasionally, while using mod_mono does not

[bugzilla-daemon@bugzilla.ximian.com]

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 bugzilla@patearl.net.

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 gonzalo@ximian.com  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 bugzilla@patearl.net  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.