>1) HTTP 1.0 script is written which expect to get GETs.
>2) HTTP 1.0 resource is programmed to redirect with a 301/302 to the
>HTTP/1.0 script
>3) Server is upgraded to HTTP/1.1 but the HTTP 1.0 resource and the HTTP
>1.0 script are not upgraded.
>4) HTTP/1.1 browser comes along and sends a POST to the HTTP 1.0
>resource and receives a 301/302. HTTP/1.1 browser sends a POST to the
>HTTP 1.0 script. The HTTP 1.0 script gets completely confused because it
>was expecting a GET and the user never sees the proper data.
>
>My suggestion is, as horrible as this is going to sound, that we change
>the definition of 301/302 to redirect to GET and make 303/304 be
>redirect, permanently or temporarily, with the same method. We can't
>force the whole world to rewrite all their scripts and our users aren't
>going to accept "Well gee, you know, the script is doing the wrong
>thing, it should send a 303 not a 301/302."
No. These issues were recognized and discussed in detail last year
and the year before that. They are not subject to change in the current
draft revision.
The current status hasn't changed in the past two years, so by any
reasonable definition those scripts (and the browser) have been broken
for a long, long time. The reason that there exists one and only one
special-case method-changing redirect is because, if that were not the
case, we would have to duplicate every single redirect code (not just
301 and 302) just to support that single special case.
This is guaranteed to cause problems with some existing scripts, but
there comes a point when the cost of not changing is far more than the
short-term problem of fixing every single CGI script that relies on
that bug.
....Roy