- From: Yngve Nysaeter Pettersen <yngve@opera.com>
- Date: Fri, 19 Dec 2008 16:18:12 +0100
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
Received on Friday, 19 December 2008 15:18:46 UTC