Re: 301/302

On Fri, 29 Aug 1997, Koen Holtman wrote:

> Klaus Weide:
> >
> [...]
> >The message where I proposed what is summarized above is at 
> ><URL: http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0402.html>.
> >(For some reason it doesn't show up immediately when one follows the
> >links into the archive from the Issues Page.)  There were several replies
> >that indicated agreement.
> 
> Being one of the people in Munich, I can report that we had no good
> reasons to prefer swapping over allocating a new code, it is just that
> we preferred swapping slightly more.  I also recall that we thought
> that swapping was the solution most often mentioned on the mailing
> list.
> 
> I do not think it is useful to spend too much time arguing which of
> the two is the better solution, we need to pick one and move on. 
> 
> Klaus, please tell us whether you can live with the spec using the
> swapping solution.  If you think that swapping is evil, we can try to
> get consensus on the 307 solution.  I for one can live with both
> solutions, and I think this is true for all people I discussed it with
> in Munich.

Given that, I would much really prefer to see consensus reached on the 307
proposal.

The swapping proposal has the advantage that it looks simpler.  It would
be a nice thing if this was the first HTTP RFC to be published, with no
prior history.  It is also easier to remember as a catchword, so I can
understand why it dominated the discussion.

IMO the alternative
 - takes account of the fact that previous RFCs have specified otherwise,
 - is better for those who have taken previous specs about 302 seriously,
 - is better for those who have taken RFC 2068 about 303 seriously,
 - is better for possible future use of 307 (now 302) functionality.

As an example for the 2nd and 3rd point, I offer Lynx as client
implementation.  A claim that no other (including server side) current
implementation of 303 exists which wwoul break ("The cat isn't really out
of the bag") would have to show this not only for servers in the usual 
sense, but for all CGI scripts etc.  

The disadvantages:
 - one more response code used,
 - an "aesthetically" less pleasing spec ("another wart"),
 - slightly less trivial editing changes.

I think the advantages outweigh the disadvantages.


    Klaus

Received on Friday, 29 August 1997 12:52:03 UTC