Re: X-HTTP-Method-Override request header

On 06/11/2013 12:21 , Anne van Kesteren wrote:
> On Wed, Nov 6, 2013 at 11:19 AM, Steve Klabnik
> <steve@steveklabnik.com> wrote:
>> It's simply about options: if the header is present, it can
>> override, if _method is present, it can override.
>>
>> The point about XmlHttpRequest is totally true as well, I was
>> speaking in a purely HMTL context, without including it. Not
>> everyone uses AJAX.
>
> What I don't understand is why the header would be present. The
> header being present suggests the problem would be on the server, not
> the browser.

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 :)

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

Received on Wednesday, 6 November 2013 12:01:15 UTC