Re: Redirection of a POST as a GET

one thing - are there any security implications with a browser say 
automatically resubmitting some POST data to another server based on a 
redirect code?

Quite often this data will be usernames and passwords.

I'm not sure how comfortable I would be typing my username and password 
into a form, and then having my browser automatically sending that 
information off to another site without my knowledge because the site 
sent back a 307.  There's no obvious trust association.  By rights I 
really should have been redirected to the new site by the request that 
served the form.

For robots I can see the need to do that.  Maybe the answer is

1. Redefine 301/302 to allow GET after a POST, making the entire 
industry compliant.
2. Leave 303 as is.
3. MUST use 307 if you want it to be the same method.

servers and proxies and websites are going to bear the brunt of any 
changes to this - it's trivial to support both the new and old codes in 
a client, but when to choose which one to use in a server is another matter.

knowing there is widespread understanding of the new codes in browsers 
allows a server to start using them, but then there's the issue of the 
countless CGI applications that set their own return codes from script.  
A server hosting such a script could automatically translate the code I 
guess, with the expectation that if it was a POST, then translate 
301/302 to 303, with optional configuration override.

Adrien

Julian Reschke wrote:
>
> Anne van Kesteren schrieb:
>>
>> On Thu, 08 Mar 2007 00:57:14 +0100, Henrik Nordstrom 
>> <henrik@henriknordstrom.net> wrote:
>>> In terms of spec writing it's quite disappointing that this industry
>>> can't accept a clear and well specified "thats the wrong thing to do",
>>> and instead continues doing the wrong thing forever countless software
>>> generations after the implementation error has been pointed out.. This
>>> attitude is quite saddening for the future of the web..
>>
>> In terms of implementing it's quite disappointing that spec writers 
>> don't always see a clear message that the industry doesn't want it 
>> the way things are specified and instead requests a different approach.
>>
>>
>> (This is also true, for instance, with the fatal error handling rules 
>> in XML which clearly don't work for the web.)
>
> Well, I think it clearly does work (minus the Content-Type encoding 
> issue) for many things, such as feed reading (*), client-side XSLT, or 
> WebDAV. All of these are part of the web.
>
> It doesn't work well for XHTML, but that's because the most widely 
> used user agent doesn't support it. I think it's incorrect to blame 
> fatal error handling here.
>
> Best regards, Julian
>
> (*) The RSS/Atom support in IE7 IMHO requires well-formed content, and 
> gets away with it. Bravo!
>

Received on Thursday, 8 March 2007 11:02:48 UTC