Re: X-HTTP-Method-Override request header

On 06/11/2013 14:11 , Anne van Kesteren wrote:
> On Wed, Nov 6, 2013 at 12:01 PM, Robin Berjon <robin@w3.org> wrote:
>> There are just several ways of doing the same thing. The server is likely to
>> respond to any of 1) the actual method; 2) the header; 3) a magic parameter.
>> (The order is probably defined for a given framework, probably not the same
>> for all, and most likely not documented.)
>>
>> If you're using a client that can set the method, you're probably doing
>> that.
>>
>> If you're using a client that allows you to set the header but not arbitrary
>> methods, you are likely better off using that than mucking about with
>> parameters. Admittedly, this isn't exactly a common situation. It can arise
>> if you're using a library that only exposes the HTTP method as a JS method
>> (foo.get(url)). There was also a lot of confusion about IE's behaviour for
>> PUT and DELETE for the longest time. IIRC IE didn't uppercase them and
>> instead blew up, leading lots of developers to think they weren't supported
>> (it's also possible they weren't in IE5 or something). I also think that the
>> header is preserved on redirects (which do happen, for trailing slashes and
>> the likes) whereas the behaviour of browsers when it comes to redirects on
>> "unsafe" methods is pretty much what the French refer to as "la Fête du
>> Slip".
>>
>> Otherwise, you use _method.
>>
>> Ah, the joys of Web development :)
>
> Look. If we want to solve the underlying problem, we need to know what
> it is.

You asked why the header was present, not what the problem is.

> Is it redirects, non-browser clients, legacy browsers, servers?
> Some of those are in our control, others are not.

All of the above, except AFAIK servers. Parts of it are already fixed 
through better XHR interop. Parts of it we can't fix.

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

> Redirects should work (307 anyway) though some browsers may
> still prompt because they are following a bogus HTTP requirement. That
> is something we could fix.

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?

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

Received on Wednesday, 6 November 2013 13:29:02 UTC