[FIXr]Handling of 1xx provisional responses not RFC2616-compliant

RESOLVED FIXED in mozilla1.6beta

Status

()

P2
normal
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: jorton, Assigned: bzbarsky)

Tracking

Trunk
mozilla1.6beta
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031008

Mozilla handles provisional responses with the "100" code correctly, but RFC2616
requires that any 1xx responses are handled the same--section 10.1:

   A client MUST be prepared to accept one or more 1xx status responses
   prior to a regular response, even if the client does not expect a 100
   (Continue) status message. Unexpected 1xx status responses MAY be
   ignored by a user agent.



Reproducible: Always

Steps to Reproduce:
Here's an nph- CGI script you can use with Apache to reproduce it:

#!/bin/sh

printf "HTTP/1.1 101 Blah\r\n"
printf "Header: foo\n"
printf "\r\n"
printf "HTTP/1.1 101 Blee\r\n"
printf "\r\n"
printf "HTTP/1.1 200 OK\r\n"
echo "Server: fish"
echo "Content-type: text/html"
printf "\r\n"
echo "This is content!"

install this as cgi-bin/nph-101 then request it with Mozilla.
Actual Results:  
Mozilla renders:

HTTP/1.1 101 Blee

HTTP/1.1 200 OK
Server: fish
Content-type: text/html

This is content!


Expected Results:  
Mozilla should render just:

This is content!

Comment 1

15 years ago
Confirmed (based on reading the RFC and LXR), but not tested.

I think we just need to change this line in nsHttpTransaction:
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpTransact
ion.cpp#591

591         // discard this response if it is a 100 continue.
592         if (mResponseHead->Status() == 100) {
593             LOG(("ignoring 100 response\n"));
594             mHaveStatusLine = PR_FALSE;
595             mResponseHead->Reset();
596             return NS_OK;
597         }
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

15 years ago
Created attachment 134722 [details] [diff] [review]
Something like that?
(Assignee)

Updated

15 years ago
Attachment #134722 - Flags: review?(darin)

Comment 3

15 years ago
Comment on attachment 134722 [details] [diff] [review]
Something like that?

r=darin if you update the LOG statement to something like "ignoring 1xx
response" ;)
Attachment #134722 - Flags: review?(darin) → review+
(Assignee)

Comment 4

15 years ago
Created attachment 134728 [details] [diff] [review]
Better logging
Attachment #134722 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #134728 - Flags: superreview?(darin)
Attachment #134728 - Flags: review?(darin)

Comment 5

15 years ago
Comment on attachment 134728 [details] [diff] [review]
Better logging

no need to log the exact status code.  it is already logged in ParseStatusLine.
 that's why i suggested "ignoring 1xx response\n"

since http logging is enabled by default, we should keep it brief (though of
course it is already super verbose!)
Attachment #134728 - Flags: superreview?(darin)
Attachment #134728 - Flags: superreview+
Attachment #134728 - Flags: review?(darin)
Attachment #134728 - Flags: review+
(Assignee)

Comment 6

15 years ago
Created attachment 134734 [details] [diff] [review]
Patch to that effect.
Attachment #134728 - Attachment is obsolete: true
(Assignee)

Comment 7

15 years ago
taking
Assignee: darin → bz-vacation
Priority: -- → P2
Summary: Handling of 1xx provisional responses not RFC2616-compliant → [FIXr]Handling of 1xx provisional responses not RFC2616-compliant
Target Milestone: --- → mozilla1.6beta
(Assignee)

Comment 8

15 years ago
Checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.