Re: X-HTTP-Method-Override request header

On 06/11/2013 14:34 , Anne van Kesteren wrote:
> On Wed, Nov 6, 2013 at 1:28 PM, Robin Berjon <robin@w3.org> wrote:
>>> Changing <form> to support PUT and DELETE is hard and unlikely to
>>> happen.
>>
>> Hard things have happened before though. Which is why previously in the
>> thread I pointed out the fact that if someone felt the need to lead this it
>> was possible.
>
> 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.

>> Redirects should certainly be fixed so as to ignore the "safe methods"
>> requirement from HTTP (or HTTP should be fixed to provide better advice).
>> Note that the issue is not just prompting, but also switching the method
>> from PUT/DELETE to GET.
>>
>> Why just 307 and not 301-3,8?
>
> 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.

Firefox changes POST to GET but not DELETE or PUT for 301-2; it changes 
all three for 303; none for 307-8. (It also prompts a lot.)

Safari changes all of POST, DELETE, and PUT to GET for 301-3 and 308 but 
not 307. It doesn't prompt.

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.

I haven't checked IE but I'm pretty sure it has a fourth combination. 
The only thing that seems consistent is that POST gets changed to GET 
for 301 and 302; the rest is an unreliable mess.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 6 November 2013 14:35:54 UTC