HTTP 301 responses for POST

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP 301 responses for POST

Yngve Nysaeter Pettersen

Hello all,

The 301 and 302 sections of HTTPbis seems to make the implicit, or perhaps  
not clearly stated, assumption that the new request shall use the same  
method as the request triggering the response.

draft-ietf-httpbis-p2-semantics-05.txt sec. 9.3.2 for the 301 response  
says in part:

       Note: When automatically redirecting a POST request after
       receiving a 301 status code, some existing HTTP/1.0 user agents
       will erroneously change it into a GET request.

I may have mentioned this before, but just in case I didn't: With respect  
to WWW-clients (a.k.a Web Browsers) there are to the best of my knowledge  
no web browser that performs a POST->POST redirect for 301 or 302, whether  
or not they are HTTP 1.0 or HTTP 1.1 clients, they all change the method  
to GET.

The only browser that I am aware that ever did support it, with a dialog  
query, has been Opera. However, due to

   1)usabilty issues: Users had problems understanding what the question  
was about, and did not have the information needed to make an informed  
decision

   2) interoperability issues: I can't recall ever encountering a  
production web server that required such a redirected POST to be using  
POST. OTOH, I have encountered many web servers that returned 4XX or 5XX  
error codes when getting a POST query when they expected a GET.

it became necessary to remove the dialog handling for 301 and 302. It is  
now only used for 307 responses.

At least among web browsers it is now a de facto standard that 301 and 302  
results in GET requests for all queries, at least the GET and POST methods.

This difference between the language in the specification and the de facto  
standard is causing many queries from our customers when their testsuites  
fail on this point.

I think it would be an idea to see if the language for web clients can be  
made closer to the actual situation, and perhaps state that other  
(non-web) HTTP applications need to specifically define their handling of  
non-safe methods and redirects.

--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer     Email: [hidden email]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Reply | Threaded
Open this post in threaded view
|

Re: HTTP 301 responses for POST

Daniel Stenberg

On Fri, 19 Dec 2008, Yngve Nysaeter Pettersen wrote:

> I think it would be an idea to see if the language for web clients can be
> made closer to the actual situation, and perhaps state that other (non-web)
> HTTP applications need to specifically define their handling of non-safe
> methods and redirects.

I don't know what browsers that do what, but as an author of a library that is
very often used to emulate browser behavior we've had people "get bitten" by
this (libcurl defaults to POST => GET for 301 and 302) and as a consequence
recent versions of libcurl can be told to do POST in the second request as
well when following 301 and/or 302...

Meaning: there are already systems "out there" that do and assume both ways.
Both client-side and server-side.

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

RE: HTTP 301 responses for POST

Eric Lawrence-4

Can you please elaborate further here-- do specific examples come to mind?  

For as long as I can recall, Netscape, IE, Firefox, Safari, etc, have treated 301, 302, and 303 as "redirect with GET" while 307 is treated as "redirect with original method."  This matches Yngve's findings.

I would be fascinated to find a web browser that behaves differently.

Thanks!

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Stenberg
Sent: Friday, December 19, 2008 2:08 PM
To: [hidden email]
Subject: Re: HTTP 301 responses for POST


On Fri, 19 Dec 2008, Yngve Nysaeter Pettersen wrote:

> I think it would be an idea to see if the language for web clients can be
> made closer to the actual situation, and perhaps state that other (non-web)
> HTTP applications need to specifically define their handling of non-safe
> methods and redirects.

I don't know what browsers that do what, but as an author of a library that is
very often used to emulate browser behavior we've had people "get bitten" by
this (libcurl defaults to POST => GET for 301 and 302) and as a consequence
recent versions of libcurl can be told to do POST in the second request as
well when following 301 and/or 302...

Meaning: there are already systems "out there" that do and assume both ways.
Both client-side and server-side.

--

  / daniel.haxx.se


Reply | Threaded
Open this post in threaded view
|

RE: HTTP 301 responses for POST

Daniel Stenberg

On Sun, 21 Dec 2008, Eric Lawrence wrote:

> Can you please elaborate further here-- do specific examples come to mind?
>
> For as long as I can recall, Netscape, IE, Firefox, Safari, etc, have
> treated 301, 302, and 303 as "redirect with GET" while 307 is treated as
> "redirect with original method."  This matches Yngve's findings.
>
> I would be fascinated to find a web browser that behaves differently.

I don't have the specific users nor servers around to tell, no. I guess I'm
just saying that the wording in RFC2616 has made people go both ways and thus
boys ways is what we've felt necessary to support in our redirection-following
logic.

It's of course entirely possible that this was done for something that weren't
including any of the major browsers, but the fact remains. In my reading, a
POST that gets a 301 or 302 back, SHOULD NOT change that to a GET in the
subsequent request. The only clients who'd do that are those who want to mimic
old non-compliant browsers. Of course, that ends up just about all browsers I
guess (including libcurl in its default behavior).

--

  / daniel.haxx.se

Reply | Threaded
Open this post in threaded view
|

Re: HTTP 301 responses for POST

Julian Reschke
In reply to this post by Yngve Nysaeter Pettersen

Yngve Nysaeter Pettersen wrote:
>
> Hello all,
>
> The 301 and 302 sections of HTTPbis seems to make the implicit, or
> perhaps not clearly stated, assumption that the new request shall use
> the same method as the request triggering the response.

Just for the record: this text hasn't been changes since RFC2616...

> ...

I'm a bit uncomfortable changing the text for 301. After all, for
temporary redirects, two new alternatives are there (303 -> GET, 307 ->
same method).

We don't have the same thing for 301.

Do we need that?

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: HTTP 301 responses for POST

Cyrus Daboo-2

Hi Julian,

--On December 23, 2008 2:24:21 PM +0100 Julian Reschke
<[hidden email]> wrote:

>>
>> The 301 and 302 sections of HTTPbis seems to make the implicit, or
>> perhaps not clearly stated, assumption that the new request shall use
>> the same method as the request triggering the response.
>
> Just for the record: this text hasn't been changes since RFC2616...

The current "Note" for 301 is:

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

The reality is that it is not just HTTP/1.0 user agents that do this now
but also HTTP/1.1. I think we need to reflect this reality more clearly
(e.g., just remove the text "HTTP/1.0").

BTW this behavior is encouraged not only by user agents but also HTTP
client libraries that do it. e.g. check out the note in the Python
documentation:
<http://www.python.org/doc/2.5/lib/http-redirect-handler.html>.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

RE: HTTP 301 responses for POST

Robert Brewer-4

Cyrus Daboo wrote:

> --On December 23, 2008 2:24:21 PM +0100 Julian Reschke
> <[hidden email]> wrote:
>
> >> The 301 and 302 sections of HTTPbis seems to make the implicit, or
> >> perhaps not clearly stated, assumption that the new request shall
> >> use the same method as the request triggering the response.
> >
> > Just for the record: this text hasn't been changes since RFC2616...
>
> The current "Note" for 301 is:
>
>       Note: When automatically redirecting a POST request after
>       receiving a 301 status code, some existing HTTP/1.0 user agents
>       will erroneously change it into a GET request.
>
> The reality is that it is not just HTTP/1.0 user agents that do this
> now but also HTTP/1.1. I think we need to reflect this reality more
> clearly (e.g., just remove the text "HTTP/1.0").
>
> BTW this behavior is encouraged not only by user agents but also HTTP
> client libraries that do it. e.g. check out the note in the Python
> documentation:
> <http://www.python.org/doc/2.5/lib/http-redirect-handler.html>.

A.J. Flavell wrote what may be the most comprehensive article on this,
which is unfortunately only available in the wayback machine now:

http://web.archive.org/web/*/http://ppewww.ph.gla.ac.uk/~flavell/www/pos
t-redirect.html


Robert Brewer
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: HTTP 301 responses for POST

Bjoern Hoehrmann

* Robert Brewer wrote:
>A.J. Flavell wrote what may be the most comprehensive article on this,
>which is unfortunately only available in the wayback machine now:
>
>http://web.archive.org/web/*/http://ppewww.ph.gla.ac.uk/~flavell/www/pos
>t-redirect.html

http://www.alanflavell.org.uk/www/post-redirect.html by way of Molly
Mockford, I believe.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: HTTP 301 responses for POST

Mark Nottingham-2
In reply to this post by Yngve Nysaeter Pettersen
Now #160;
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160

On 20/12/2008, at 2:18 AM, Yngve Nysaeter Pettersen wrote:

>
> Hello all,
>
> The 301 and 302 sections of HTTPbis seems to make the implicit, or  
> perhaps not clearly stated, assumption that the new request shall  
> use the same method as the request triggering the response.
>
> draft-ietf-httpbis-p2-semantics-05.txt sec. 9.3.2 for the 301  
> response says in part:
>
>      Note: When automatically redirecting a POST request after
>      receiving a 301 status code, some existing HTTP/1.0 user agents
>      will erroneously change it into a GET request.
>
> I may have mentioned this before, but just in case I didn't: With  
> respect to WWW-clients (a.k.a Web Browsers) there are to the best of  
> my knowledge no web browser that performs a POST->POST redirect for  
> 301 or 302, whether or not they are HTTP 1.0 or HTTP 1.1 clients,  
> they all change the method to GET.
>
> The only browser that I am aware that ever did support it, with a  
> dialog query, has been Opera. However, due to
>
>  1)usabilty issues: Users had problems understanding what the  
> question was about, and did not have the information needed to make  
> an informed decision
>
>  2) interoperability issues: I can't recall ever encountering a  
> production web server that required such a redirected POST to be  
> using POST. OTOH, I have encountered many web servers that returned  
> 4XX or 5XX error codes when getting a POST query when they expected  
> a GET.
>
> it became necessary to remove the dialog handling for 301 and 302.  
> It is now only used for 307 responses.
>
> At least among web browsers it is now a de facto standard that 301  
> and 302 results in GET requests for all queries, at least the GET  
> and POST methods.
>
> This difference between the language in the specification and the de  
> facto standard is causing many queries from our customers when their  
> testsuites fail on this point.
>
> I think it would be an idea to see if the language for web clients  
> can be made closer to the actual situation, and perhaps state that  
> other (non-web) HTTP applications need to specifically define their  
> handling of non-safe methods and redirects.
>
> --
> Sincerely,
> Yngve N. Pettersen
> ********************************************************************
> Senior Developer     Email: [hidden email]
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
> ********************************************************************
>


--
Mark Nottingham     http://www.mnot.net/