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