Re: #160: Redirects and non-GET methods

On 2011-07-18 13:02, Amos Jeffries wrote:
> On 18/07/11 19:05, Julian Reschke wrote:
>> On 2011-07-18 04:21, Amos Jeffries wrote:
>>> ...
>>> This MSIE handling of 301 is a big problem in some installations. To the
>>> point that they are migrating their customers away from MSIE just to get
>>> the Firefox/Chrome behaviour.
>>> ...
>>
>> How so? Why don't they fix their sites? Details, please.
>
> 301 - Portals enforcing policy of no unencrypted content past the border
> and bouncing the http:// requests to https:// at the gateway.
> They require all inbound http:// get redirected to https:// without
> bothering the user. Method remaining unchanged through the redirect. 301
> is perfect here, as the domain is fixed and all http:// URLs are
> permanently redirected to their https:// exact equivalents. For MSIE
> this only works on POST.

As far as I can tell, IE changes the method *only* for POST; whereas the 
other UAs change it for all methods. For this use case, the IE behavior 
seems to be strictly better, no?

> 307 - Portals doing policy agreements and splash pages. They require at
> minimum an arbitrary page of content to be visible to the user
> regardless of whether the request first made was a GET, CONNECT, POST
> etc. 307 seems to fit best until the 428 starts working on all requests.
> Preserving the method is important here.
>
> 3 months ago when I last saw this needed only Firefox and Chrome were
> doing 307 right. This is the first I've seen with MSIE on the good list
> there.

We've tested this several times over the last years (for XHR), and all 
but Safari seemed to do the right thing here.

BTW: what is 428?

>
>>> ...
>>>> All that said, GET and POST are vastly more common for browsers to
>>>> handle than other methods. Having reasonable requirements for GET and
>>>> POST would be a welcome step forward.
>>>>
>>>> Adam
>>>
>>> Even just idempotent / non-idempotent separation would be great. That
>>> also leaves it open for consistency with future methods.
>>> ...
>>
>> That doesn't work, as given a new method name, you don't know whether
>> it's idempotent or not.
>
> Thats one of the things the new drafts require them to indicate now,
> with unknowns treated as non-idempotent by default. yes?

That may be fine for prompting, but definitively not for the question of 
silently changing the method.

Best regards, Julian

Received on Monday, 18 July 2011 11:27:24 UTC