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

RESOLVED FIXED

Status

()

Core
Networking: HTTP
P1
normal
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: vaag, Assigned: Darin Fisher)

Tracking

({topembed})

Trunk
topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: r=bbaetz, sr=dougt, verified-on-trunk, URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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.
-> 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
Assignee: asa → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
OS: MacOS X → All
QA Contact: doronr → benc
Hardware: Macintosh → All
Summary: No rendering → should not discard the remainder of the packet after a 100 Continue response
(Assignee)

Updated

17 years ago
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4
(Assignee)

Comment 2

17 years ago
Created attachment 44410 [details] [diff] [review]
v1.0 fixes the problem
(Assignee)

Comment 3

17 years ago
Created attachment 44413 [details] [diff] [review]
v1.1 same patch minus some stuff for bug 88792
(Assignee)

Comment 4

17 years ago
bbaetz says: r=bbaetz
Status: NEW → ASSIGNED
(Assignee)

Updated

17 years ago
Keywords: patch, topembed
Whiteboard: r=bbaetz, sr=?

Comment 5

17 years ago
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.


(Assignee)

Comment 6

17 years ago
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.
(Assignee)

Comment 7

17 years ago
Created attachment 44426 [details] [diff] [review]
v1.2 revised per comments from dougt
(Assignee)

Updated

17 years ago
Whiteboard: r=bbaetz, sr=? → r=bbaetz, sr=dougt
(Assignee)

Comment 8

17 years ago
fixed-on-trunk
Whiteboard: r=bbaetz, sr=dougt → r=bbaetz, sr=dougt, fixed-on-trunk
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.4 → ---

Comment 9

16 years ago
verified on the trunk:

win NT4 2001080804
mac os9 2001080810
linux rh6 2001080810
QA Contact: benc → tever

Updated

16 years ago
Whiteboard: r=bbaetz, sr=dougt, fixed-on-trunk → r=bbaetz, sr=dougt, verified-on-trunk
(Assignee)

Comment 10

16 years ago
fixed-on-branch
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.