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 Friday, 29 August 1997 12:55:52 UTC