Re: 301/302

Roy T. Fielding:
>
  [Yaron:]
>>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.

Well, they *could* become subject to change based on implementation
experience.  

Put it simply, if Yaron can find a some sites which depend on
redirects after POST requests and break horribly when the POST stays a
POST, then I would be very inclined to support:

 a) declaring 301/302 obsolete, historic, and unsafe, 
 b) allowing browsers to change the 301/302 method into a GET
    if they think they can be more compatible with obsolete software
    by doing so, and 
 c) assigning the semantics originally intended for 301/302 to
    fresh codes.

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

CGI script maintenance is a pain, even if these scripts are provably
broken in some sense.  I see no reason why 1.1 should inflict CGI
maintenance costs which could be avoided by some spec maintenance.

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

I think you mean the above to be a proof that declaring 301 and 302
obsolete leads to an explosion of complexity, but I fail to follow
your line of reasoning.

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

I don't think we are anywhere near that point for the 301/302 issue.
If someone can show problems with existing scripts, I think we have
all the reason we need to revise the spec.

>....Roy

Koen.

Received on Tuesday, 29 July 1997 12:47:52 UTC