[Mono-bugs] [Bug 80017][Nor] Changed - HTTP chunked encoding not working

[bugzilla-daemon at 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 stevenspencer01 at gmail.com.

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

--- shadow/80017	2007-08-09 00:32:52.000000000 -0400
+++ shadow/80017.tmp.30487	2007-08-13 07:32:40.000000000 -0400
@@ -117,6 +117,47 @@
 before closing the socket. That could indeed truncate the received
 data on the server as the Close on the server is translated into a TCP
 reset on the client if not all the data has been read.
 
 ------- Additional Comments From gonzalo.mono at gmail.com  2007-08-09 00:32 -------
 Steven? You there? Any comment on the server not lingering?
+
+------- Additional Comments From stevenspencer01 at gmail.com  2007-08-13 07:32 -------
+Hi Gonzalo,
+
+sorry for the delay - been a bit busy of late. I've just been looking
+at this again, since it was quite a while since I last did so. You're
+suggestion of a TCP reset being sent made me look a little closer at
+the tcpdump output and I noticed some additional information.
+
+Firstly, I don't think your suggestion of the server not lingering is
+what is happening. The code for the server (in the attached file)
+simply creates a socket and uses it in a very minimalistic way,
+without setting any specific options, so I imagine that it would have
+default TCP behaviour i.e. the closing socket will enter the time wait
+state and not necessarily terminate early.
+
+However, looking at the tcpdump output shows some interesting facts:
+
+1) When tcpdump is being run, the test code passes on a much more
+regular basis. It fails maybe 1 in 10 times (instead of about 9 in 10
+without tcpdump). Why? No idea presently.
+
+2) When the test fails, **all** of the data sent by the server is
+acknowledged by the client. Thus, the client IP stack has all of the
+data, but it gets discarded for some reason before it gets passed to
+the application code.
+
+3) When the test fails, after the last data ack from the client is
+sent, the handshaking for closing the connection begins. The server
+sends a FIN and, instead of responding with an ACK, the client
+responds with a RST. This clearly explains why the data that is being
+held in the client side IP stack is not being passed up to the
+application layer, but I don't know why the client would sent the RST.
+Is this potentially because the test program is such a short lived
+thing that it exits before the handshaking is complete? Because the
+process has finished, the host IP stack will then just abort any
+relevant outstanding TCP connections - I'm just hypothesising here.
+
+I'll modify my test to see if this is an issue and get back to you.
+
+Steven