RE: 301/302

The 307 solution does not work because older scripts running on new
servers still send out 302 expecting a redirect to GET. We will break
all those scripts. Breaking those scripts is not an acceptable solution.
The 302/303 swap, on the other hand, does not break the huge base of
deployed scripts. There really is no other realistic option but to swap
302/303.
	Yaron

> -----Original Message-----
> From:	Foteos Macrides [SMTP:MACRIDES@SCI.WFBR.EDU]
> Sent:	Friday, August 29, 1997 1:50 PM
> To:	koen@win.tue.nl
> Cc:	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject:	Re: 301/302
> 
> koen@win.tue.nl (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.
> >>
> >>If the people present in Munich came to a different consensus, I
> would
> >>very much like to know why.
> >
> >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.
> 
> 	Klaus can answer for himself, but he shouldn't be on the spot
> alone.  I proposed the swap, and perhaps my verbose writting style
> created the impression that this was the solution most often mentioned
> on the list.  However, that was not my impression, e.g.:
> 
> 	Klaus,
> 	I thinks this would be the best solution we have so far.  It
> allows
> 	legacy server scripts and clients to work properly with HTTP 1.1
> while
> 	paving the way for 1.1 users to invoke the new and correct
> behaviors
> 	we've defined.
> 	From an implementation stand point it would be trivial to add an
> 	additional status code redirect.  But it remains to be seen
> whether we
> 	can make this change in consensus.
> 		-- Arthur Bierer <arthurbi@MICROSOFT.com>
> 
> 	Agreed.
> 		-- Yaron Goland <yarong@microsoft.com>
> 
> 	I think we now have a proposed solution for 301/302 (add 307),
> and
> 	hope it gets onto the issue list so that we can LAST CALL it.
> 		-- Larry Masinter <masinter@parc.xerox.com>
> 
> 	The 307 proposal works. Lets do it.
> 		-- David W. Morris <dwm@xpasc.com>
> 
> So I did a field test implementation, and Klaus has incorporated that
> into
> the Lynx development code set:
> 
> * The IETF has indicated intent to adopt KW's "status 307" proposal
> for
>   dealing with the status 302 problems, so HTTP.c and HTAlert.c
> implement
>   that now.  The 302 status is "General (temporary) Redirection" which
>   can be handled as 303 at the UA's discretion, so we do that in all
> cases,
>   rather than prompting the user whether to do that when the 302 is
> for
>   a POST submission.  The 307 (and 305) for POST submissions invokes a
>   prompt whether to P)roceed or C)ancel, without the Use G)ET option.
>   The 301 is treated as permanent, normally, but for POST submissions
>   still is treated as temporary and invokes a prompt which includes
> the
>   Use G)ET option, because scripts written to empirical behavior may
>   still be expecting that (it's virtually never encountered in
> redirections
>   of POSTs, though, because the document containing the form typically
>   is redirected, so the user only sees the form if a local copy has
> been
>   made, and it would be best to C)ancel and get a new local copy of
> the
>   document from the correct http/https URL, to serve as a BASE for the
>   form's ACTION). - FM
> 
> 
> This also avoids breaking Lynx v2.6, v2.7, and v2.7.1 (though Lynx is
> not a "MAJOR WWW SOFTWARE ORGANIZATION" :).
> 
> 				Fote
> 
> ======================================================================
> ===
>  Foteos Macrides            Worcester Foundation for Biomedical
> Research
>  MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
> ======================================================================
> ===

Received on Tuesday, 2 September 1997 20:46:59 UTC