W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: Redirection of a POST as a GET

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 08 Mar 2007 00:57:14 +0100
To: Anne van Kesteren <annevk@opera.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <1173311834.620.61.camel@henriknordstrom.net>
ons 2007-03-07 klockan 23:33 +0100 skrev Anne van Kesteren:

> Following the spec for this is not really feasible. We tried and failed.  
> It would make sense to simply change the specification imo...

Hmm.. perhaps it would work to rewrite the specs to allow the request to
be retried using either the original request method or a GET after a
POST resulting in a 301/302 redirect. I.e. not say that there is broken
user agents around but to also accept that broken behavior as an
alternative action.

  ... Alternatively if the request was a POST request the user agent
  MAY automatically retry the request as a GET request without requiring
  user confirmation.

As it's been specified since day 1 (before HTTP/1.0 even) that the
original request should be retried with the new Request-URI without
changing the request method we can not change the specs in such manner
that this would not be a correct thing to do. In terms of spec writing
the only possible choices is to clearly deprecate the 301/302 responses
as "broken beyond repair" in favor of the new 303 & 307 status codes and
hope the industry won't trash these as well, or to convince the industry
to fix up their act and start following the specs.. and I suspect you
won't be happy with either choice..

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


Received on Wednesday, 7 March 2007 23:57:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC