Re: User confirmation and 307 redirects

We know about the 307 issue, and I believe it has been addressed.  Essentially, any piece of code that can't put up UI can't auto-follow a 307.


_Mark

On Aug 19, 2010, at 5:36 AM, Julian Reschke wrote:

> On 19.08.2010 14:20, Anne van Kesteren wrote:
>> On Thu, 19 Aug 2010 14:17:53 +0200, Julian Reschke
>> <julian.reschke@gmx.de> wrote:
>>> Well, the server knows what's supposed to happen.
>>> 
>>> If the server wants you to do a POST to a new URI, and you don't want
>>> to do the POST, then doing a GET instead simply is a bug. Incorrect.
>>> Wrong. Bad.
>> 
>> It seems you are ignoring the concerns posted here. Not really sure how
>> to continue discussing this issue then.
> 
> The concern Adam voiced was that using a 307 on an unsafe request has interop problems because some browsers (Opera) come up with a confirmation dialogue, while others do not.
> 
> To this I added that a more severe interop problem is that one browser rewrites the method to GET (Safari).
> 
> Could you please elaborate what the other concern is? It appears you argued that rewriting the method to GET actually is okay. I disagree; if the server expects a POST, sending a GET instead doesn't help anybody at all. If the server *wanted* to receive a GET request it would have said so using 303. Sending a GET instead will probably display something in the browser, but will not be what the server expected, and thus, in particular, have not the expected *effect*.
> 
> I totally agree that we have various problems with both the spec and the implementations of 3xx. But can we please stick to those things that belong into this category, instead of claiming that what Safari does (and what is a severe and long-known bug) suddenly is "okay-ish"?
> 
> Best regards, Julian
>

Received on Thursday, 19 August 2010 17:56:14 UTC