Re: X-HTTP-Method-Override request header

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. Is it redirects, non-browser clients, legacy browsers, servers?
Some of those are in our control, others are not.

Changing <form> to support PUT and DELETE is hard and unlikely to
happen. 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.


-- 
http://annevankesteren.nl/

Received on Wednesday, 6 November 2013 13:11:59 UTC