RE: 301/302

Requiring everyone to re-write their scripts is too heavy a price to pay
for protocol purity. We must accept that backwards compatibility is a
requirement and support 301/302 as they have been deployed. That doesn't
stop us from introducing 303 as the "correct" way to redirect to GET and
it doesn't stop us from declaring that we will not introduce any new
responses dealing with redirect to GET, but we need to support 301/302
as deployed.

			Yaron



> -----Original Message-----
> From:	Roy T. Fielding [SMTP:fielding@kiwi.ics.uci.edu]
> Sent:	Saturday, July 26, 1997 11:03 PM
> To:	Yaron Goland
> Cc:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: 301/302 
> 
> >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

Received on Monday, 28 July 1997 15:29:14 UTC