A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

HTTP: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
mNo edit summary
(Add HTTP 0.9 (and Legacy Shoutcast support))
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This page is an attempt to document some discrepancies between browsers and RFC 2616 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.
This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.
 
== Header parsing: newlines ==
 
http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0123.html
 
== Header parsing: handling "duplicates" ==
 
https://bugzilla.mozilla.org/show_bug.cgi?id=376756
 
== Content-Encoding ==
 
Under certain conditions this header needs to be stripped: http://hg.mozilla.org/mozilla-central/file/366b5c0c02d3/netwerk/protocol/http/nsHttpChannel.cpp#l4042
 
Not raised. Monkey patched in Fetch.
 
== Content-Length ==
 
In cases where Content-Length doesn't equal the actual content length, browsers truncate to the Content-Length value if it's smaller, but behaviour varies if Content-Length value is larger than actual content. Test results: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-49011736
 
== Content-Type parsing ==
 
Pretty sure I (Anne) raised this at some point. A trailing ";" after a MIME type is considered invalid, but works fine in all implementations.
 
mnot: relevant spec -  http://httpwg.github.io/specs/rfc7231.html#media.type  I don't remember this being raised; we can either record it as errata or work it into the next revision.
 
'''Raised:''': http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031
 
Potential replacement: http://mimesniff.spec.whatwg.org/#parsing-a-mime-type
 


== Redirects ==
== Redirects ==
Line 7: Line 36:
'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225
'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225


== Location header ==
mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx
 
(Seems this is mostly solved now. Would still be good to explicitly require behavior here. Maybe in Fetch.)
 
 
== Location header: URLs ==


Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.
Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.


'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276
'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276
mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.
== Location header: duplicates ==
Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.
== Location header: fragment ==
https://bugzilla.mozilla.org/show_bug.cgi?id=1034819


== Content-Location header ==
== Content-Location header ==
Line 20: Line 65:


This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)
This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)


== Accept header ==
== Accept header ==
Line 26: Line 72:


(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)
(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)


== Requiring two interoperable browser implementations ==
== Requiring two interoperable browser implementations ==


To proof that RFC 2616 can be implemented there should be two compatible implementations in browsers.
To prove that RFC 2616 can be implemented there should be two compatible implementations in browsers.


'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html
'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html


== Assume Vary: User-Agent ==
mnot: That'll happen when RFC723x go to full Standard.
 
 
== Assume Vary: Cookie ==
 
http://www.ietf.org/mail-archive/web/http-state/current/msg01447.html


UAs and intermediary caches should act as if all responses had Vary: User-Agent specified since many pages on the Web serve different content depending on the User-Agent header but do not bother specifying Vary: User-Agent.
== HTTP 0.9 (and Legacy Shoutcast support) ==


'''Raised:''' http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0114.html
See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/7_cMXoKXAwAJ


[[Category:Spec_coordination]]
[[Category:Spec_coordination]]

Latest revision as of 12:45, 21 January 2017

This page is an attempt to document some discrepancies between browsers and RFC 2068 (and its successor, RFC 2616) because the HTTP WG seems unwilling to resolve those issues. Hopefully one day someone writes HTTP5 and takes this into account.

Header parsing: newlines

http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0123.html

Header parsing: handling "duplicates"

https://bugzilla.mozilla.org/show_bug.cgi?id=376756

Content-Encoding

Under certain conditions this header needs to be stripped: http://hg.mozilla.org/mozilla-central/file/366b5c0c02d3/netwerk/protocol/http/nsHttpChannel.cpp#l4042

Not raised. Monkey patched in Fetch.

Content-Length

In cases where Content-Length doesn't equal the actual content length, browsers truncate to the Content-Length value if it's smaller, but behaviour varies if Content-Length value is larger than actual content. Test results: https://github.com/slightlyoff/ServiceWorker/issues/362#issuecomment-49011736

Content-Type parsing

Pretty sure I (Anne) raised this at some point. A trailing ";" after a MIME type is considered invalid, but works fine in all implementations.

mnot: relevant spec - http://httpwg.github.io/specs/rfc7231.html#media.type I don't remember this being raised; we can either record it as errata or work it into the next revision.

Raised:: http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

Potential replacement: http://mimesniff.spec.whatwg.org/#parsing-a-mime-type


Redirects

For 301 and 302 redirects browsers uniformly ignore HTTP and use GET for the subsequent request if the initial request uses an unsafe method. (And the user is not prompted.)

Raised: http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg225

mnot: See http://httpwg.github.io/specs/rfc7231.html#status.3xx

(Seems this is mostly solved now. Would still be good to explicitly require behavior here. Maybe in Fetch.)


Location header: URLs

Browsers handle relative URIs and URIs with invalid characters in interoperable fashion.

Raised: http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg276

mnot: see note in: http://httpwg.github.io/specs/rfc7231.html#header.location If there's an updated URL spec that's able to be referenced when 7231 is revised, we can point at that.


Location header: duplicates

Nothing defines what happens with multiple Location headers. Apparently if their values match it is okay, but otherwise a network error.

Location header: fragment

https://bugzilla.mozilla.org/show_bug.cgi?id=1034819

Content-Location header

Browsers cannot support this header.

Raised: http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg190

This has apparently been fixed by making Content-Location have no UA conformance criteria. (It's not clear what it's good for at this point.)


Accept header

Accept header should preferably be done without spaces.

(not raised, odinho: I came across a site that didn't like the spaces, the developer said he'd gotten it off php.net or stackoverflow. He fixed the site. This could be disputed.)


Requiring two interoperable browser implementations

To prove that RFC 2616 can be implemented there should be two compatible implementations in browsers.

Raised: http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0222.html

mnot: That'll happen when RFC723x go to full Standard.


Assume Vary: Cookie

http://www.ietf.org/mail-archive/web/http-state/current/msg01447.html

HTTP 0.9 (and Legacy Shoutcast support)

See https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/7_cMXoKXAwAJ