Re: LYNX-DEV two curiosities from IETF HTTP session.

jg@pa.dec.com (Jim Gettys) wrote:
>Here's what I think needs to happen:
>
>It looks to me as though we may need a clarification to Rev-01 on 305 (use 
>this proxy for a single request) to to match the existing Lynx behavior, 
>if that is actually the "right thing" for the desired semantics (single 
>time redirection to a proxy). (previous comments say that we're pretty close 
>to that now in Rev-01, but a bit of further tweaking is needed).
>
>And the full "go use this proxy forever" functionality (i.e. what we called 
>306) needs to get addressed somehow, but in an independent (not HTTP/1.1 
>document (and concievably, outside of HTTP altogether, if that seems the 
>right solution.).  This one nees to deal with all the security/trust problems 
>identified in the discussion on 306 in the mailing list. 	

	I thought it had already been decided in the HTTP-WG list
(http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0245.html) that:

	(1) Josh's draft-cohen-http-305-306-responses-00.txt would be
	    dropped from Rev-01;
	(2) Josh and Ari would generate a new 306 proposal (which could
	    include a "go use this proxy forever" directive, but has
	    other options, depending on what's in the Set-Proxy: header
	    for that status); and
	(3) 305 would become a one-shot, from-origin-server-only,
	    redirection to a proxy via a Location: header, as described
	    in Rev-01 (draft-ietf-http-v11-spec-rev-01):

	10.3.6 305 Use Proxy

	 The requested resource MUST be accessed through the proxy given
	by the Location field. The Location field gives the URL of the
	proxy. The recipient is expected to repeat this single request
	via the proxy. 305 responses MUST only be generated by origin
	servers.


That description doesn't say what to do about the method.  My suggestion
was to add a sentence about that issue, and my present bias is to make it
303-like ;(oops, not 304 that I wrote in my earlier message): e.g.:

	          The redirected request SHOULD be made with a GET
	method.

That would make 305 utterly safe, and it's not obvious to me why a
POST or other non-safe request would ever be redirected to a proxy
with intention that the content be retained (it's most likely to be
used by scripts homologously to 302/303), so I doubt this would pose
a functionality problem.

	Released versions of Lynx prompt the user about 305 redirection
for a POST:

	P)roceed, use G)ET, or C)ancel?

and users have been "conditioned" to choose G or C for such prompts,
so making 305 303-like should not be a serious problem with those
versions.  The current Lynx development code (scheduled for release
as v2.8 this month) treats 305 as 307-like (doesn't include the
option to use G)ET), but it would take just a few minutes to change
that to 303-like behavior for the actual release. 

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Wednesday, 10 December 1997 09:30:47 UTC