HTTP

2012-09-20T14:23:49Z

Odinho: odinho: accept header shouldn't have spaces

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.

== 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

== Location header ==

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

== 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 proof 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

[[Category:Spec_coordination]]

WHATWG Wiki - User contributions [en]

HTTP