W3C home > Mailing lists > Public > www-tag@w3.org > November 2013

Re: X-HTTP-Method-Override request header

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 7 Nov 2013 12:13:04 +0000
Message-ID: <CADnb78gaT1SAnm+99DkEpDMCJgpnP2ooUtUQ8724C98-f5P9ew@mail.gmail.com>
To: Robin Berjon <robin@w3.org>
Cc: Steve Klabnik <steve@steveklabnik.com>, "www-tag.w3.org" <www-tag@w3.org>
On Wed, Nov 6, 2013 at 2:35 PM, Robin Berjon <robin@w3.org> wrote:
> On 06/11/2013 14:34 , Anne van Kesteren wrote:
>> Given the cross-origin complexity it just does not quite seem worth it
>> in order to get this declarative.
> Every time I've heard this use case come up though it's been in same-origin
> situations. It could be thus limited. I'm not a huge fan of the idea, but
> I'm pretty sure that it's make the request go away.

I'm tempted to say same difference again. The problem is that even if
you only do it same-origin, the fetch semantics will be different.
There might be a way to make this work by introducing <form
crossorigin> and allowing <form method> to have different values
there. Though note that it cannot really be as open ended as
XMLHttpRequest is as <form method=dialog> already has different

>> Because only 307/308 preserve the method.
> Ah, so you meant 307-8. It's not clear to me that (if compatibly possible)
> the method shouldn't be preserved for 301-3 too, under XHR. Method changing
> is certainly surprising to developers.

They also depend on this. There's a bunch of forms that have <form
action=/tralala> and than /tralala will redirect back to the page the
form was on. And rather than 303 as they should, they'll use 302.

Last I checked the HTTP WG and some browsers are trying to restrict
the rewriting to POST for 301/302. (303 has to do the rewrite per
specification.) But it's all rather messy and not very interoperable.

> Chrome changes POST to GET but not DELETE or PUT for 301-2; changes all
> three for 303 and 308; none for 307. It doesn't prompt.

Seems like a bug in 308, otherwise as close to ideal as we'll get.

Received on Thursday, 7 November 2013 12:13:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:59 UTC