Subject: HTTP 301 responses for POST

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 19 Dec 2008 16:18:12 +0100

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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 19 Dec 2008 20:08:20 +0100 (CET)

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

> 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

---

From: Eric Lawrence <[email-masked]>
Date: Sun, 21 Dec 2008 18:56:20 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Stenberg
Sent: Friday, December 19, 2008 2:08 PM
To: [email-masked]
Subject: Re: HTTP 301 responses for POST

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 23 Dec 2008 09:06:51 +0100 (CET)

On Sun, 21 Dec 2008, Eric Lawrence wrote:

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Dec 2008 14:24:21 +0100

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 23 Dec 2008 11:53:10 -0500

Hi Julian,

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

The current "Note" for 301 is:

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

---

From: "Robert Brewer" <[email-masked]>
Date: Tue, 23 Dec 2008 10:16:27 -0800

Cyrus Daboo wrote:
> >> perhaps not clearly stated, assumption that the new request shall
> >> use the same method as the request triggering the response.
> >
> 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").
> 

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
[email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 23 Dec 2008 19:22:00 +0100

>http://web.archive.org/web/*/http://ppewww.ph.gla.ac.uk/~flavell/www/pos

http://www.alanflavell.org.uk/www/post-redirect.html by way of Molly
Mockford, I believe.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/