W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: Issue 160 (Redirects and non-GET methods)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 20 Sep 2010 16:54:18 +0200
Message-ID: <4C97759A.4000604@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
On 19.09.2010 12:13, Julian Reschke wrote:
> ...
> The suggested fix for 1) is to allow UAs to do what they do today.
> However, it's not totally clear how far we want to go with that:
>
> 1a) We know that all major browsers rewrite the request method to GET
> when receiving a 301/302 on POST.
>
> 1b) Browsers do differ in their behavior for XmlHttpRequest, though. IE
> only rewrites POST, and leaves other methods alone. Other browsers seem
> to rewrite all methods (minus HEAD?). The fact that IE does only rewrite
> for POST suggests that breaking the RFC 2616 semantics is not needed for
> the other methods.
>
> 1c) There are other UAs that do not rewrite the method name at all, and
> indeed may be broken if they would start to do that (WebDAV clients
> getting a redirect on PROPFIND come to mind; I also see this behavior in
> Microsoft's XmlHttpRequest ActiveX control, though).
>
> My proposal is to say SHOULD NOT change the method, except for GET which
> can be changed to POST for compatibility with broken web content (which
> should use 303 instead).
> ...

This one is pretty urgent, as HTNL5 allows PUT and DELETE in HTML forms. 
Browser implementers who actually do that will have to decide what to do 
with 301s and 302s.

See related Mozilla bugzilla comment: 
<https://bugzilla.mozilla.org/show_bug.cgi?id=583288#c32>.

Best regards, Julian
Received on Monday, 20 September 2010 14:54:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:25 GMT