93209 - should not discard the remainder of the packet after a 100 Continue response

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[vaag]

Mozilla seems not to be able to render this site (and its links) properly, only
source code. None of the other browsers have problems with SpiderNet.

Comment 1

[Bradley Baetz (:bbaetz)]

-> networking: http, and confirming, and updating summary.

Using testProtocols, I can see that we appear to be losing the response headers,
and most of the beginning of the response. The beginning of the data (when
sending an http/1.1 request) is:

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
MIME-Version: 1.0
Server: TeleFinder/5.7.3
Date: Thu, 2 Aug 2001 10:11:45 GMT
Last-modified: Thu, 12 Jul 2001 11:18:13 GMT
Content-type: text/html
Accept-ranges: bytes
Content-Length: 6843

<data>...
I guess we're handling the 100 incorrectly. The server SHOULD NOT be sending
such a response to us, although its allowed to.

In fact, looking at it more, according to http logs, we're reading 1460 bytes in
the first ODA, seeing the 100 response, and throwing the rest of the input away.
Oops. We then get the rest of the data (from the middle of the page), think its
a 0.9 response, and things go downhill from there.

-> darin

Comment 2

[Darin Fisher]

Attachment: v1.0 fixes the problem

Comment 3

[Darin Fisher]

Attachment: v1.1 same patch minus some stuff for bug 88792

Comment 4

[Darin Fisher]

bbaetz says: r=bbaetz

Comment 5

[Doug Turner (:dougt)]

The test before calling delete are not needed:

 if (mChunkedDecoder)
         delete mChunkedDecoder;
+
+    if (mResponseHead)
+        delete mResponseHead;


Is the |reset| assignment really needed:
+        PRBool reset = PR_FALSE;
+        mConnection->OnHeadersAvailable(this, &reset);


fix that and sr.

Comment 6

[Darin Fisher]

agreed.. the if()'s can be removed.  i'm initializing reset so i don't have to
worry if OnHeadersAvailable fails to set it.  new patch coming.

Comment 7

[Darin Fisher]

Attachment: v1.2 revised per comments from dougt

Comment 8

[Darin Fisher]

fixed-on-trunk

Comment 9

[Tom Everingham]

verified on the trunk:

win NT4 2001080804
mac os9 2001080810
linux rh6 2001080810

Comment 10

[Darin Fisher]

fixed-on-branch