Re: X-HTTP-Method-Override request header

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


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


-- 
http://annevankesteren.nl/

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