[Mono-bugs] [Bug 80017][Nor] New - 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	2006-11-23 08:13:39.000000000 -0500
+++ shadow/80017.tmp.28554	2006-11-23 08:13:39.000000000 -0500
@@ -0,0 +1,107 @@
+Bug#: 80017
+Product: Mono: Class Libraries
+Version: 1.1
+OS: other
+OS Details: Debian etch
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: System
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: stevenspencer01 at gmail.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: HTTP chunked encoding not working
+
+Description of Problem:
+When using the HTTP client classes
+(System.Net.HttpWebRequest/HttpWebResponse) to do an HTTP GET from a server
+that responds using chunked encoding, the message body is randomly truncated.
+
+This problem appears to arise when the server does separate socket send
+calls for each chunk in the response. The attached file
+ChunkEncodingTest.cs demonstrates the problem. The code should be
+straightforward but I summarise here:
+
+The test starts a thread which acts as the server. This thread:
+1. Creates a listening socket on the loopback interface, port 54321.
+2. Does an accept call to wait for the connection.
+3. When connection is received, it receives the HTTP request from the
+returned socket.
+4. Sends back the response ***line by line*** rather than constructing the
+whole message into a single byte array and doing a single send. This is how
+to recreate the problem. If the entire response is sent back with a single
+send, the problem disappears. However, I don't believe that this is a
+reasonable situation. If a server is going to respond with chunked
+encoding, it is quite likely to do separate sends for each chunk. If it
+constructed the response into one big buffer, it would then know the length
+of the response and would not have to use chunked encoding.
+
+The main thread of the test is the client code. It uses the System.Net
+classes mentioned above. After the request is made, the response is read
+from the response stream byte by byte until the end of the stream. All
+results are printed to standard output.
+
+It should also be noted that, using tcpdump, it is verified that the entire
+chunked message is sent.
+
+
+Steps to reproduce the problem:
+1. Compile attached file: mcs ChunkedEncodingTest.cs
+2. Run: mono ChunkedEncodingTest.exe
+3. Run again, as many times as you wish
+
+Actual Results:
+These vary. An example of the actual output is:
+
+"Server received request:
+GET / HTTP/1.1
+Connection: close
+Host: 127.0.0.1:54321
+
+
+Client received response headers:
+Transfer-Encoding: chunked
+
+
+Client received response body:
+012345670123456789abcEOS"
+
+The last line of the output (which represents the body of the chunked
+message with an EOS appended) will vary. Sometimes the expected output is
+seen. The amount of the message body that is seen varies. Sometimes it may be
+
+"0123EOS"
+
+sometimes it will be as above. Sometimes it will be some other randomly
+truncated portion of the message.
+
+
+Expected Results:
+The standard output should be the following
+
+"Server received request:
+GET / HTTP/1.1
+Connection: close
+Host: 127.0.0.1:54321
+
+
+Client received response headers:
+Transfer-Encoding: chunked
+
+
+Client received response body:
+012345670123456789abcdefabcdefghijklmnopqrstuvwxyzEOS"
+
+
+How often does this happen? 
+It happens on a regular basis. The expected results might be obtained 1 out
+of every 10 runs.
+
+
+Additional Information:
+Using Microsoft.NET on windows, the expected results were seen 50 out of 50
+times.