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

>  From: Josh Cohen <joshco@microsoft.com>
>  Date: Tue, 6 Jan 1998 17:49:56 -0800 
>  To: "'jg@pa.dec.com'" <jg@pa.dec.com>, Paul Leach <paulle@microsoft.com>
>  Cc: Yaron Goland <yarong@microsoft.com>,
>          Foteos Macrides
>  	 <MACRIDES@SCI.WFBR.EDU>, lynx-dev@sig.net,
>          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: RE: LYNX-DEV two curiosities from IETF HTTP session.
>  
>  The question is "How do you know that the origin sent the 305
>    and not your (evil) proxy?"
>  
>  If you are a client, and you are talking through a proxy,
>   you know that. (your aware that your talking via a proxy).
>  
>  You should never receive a 305 in this case.  305 is HOP-by-HOP.
>  The proxy should handle it itself.
>  
>  The two cases when you might receive a 305 in this fashion are:
>  1) the proxy is an old proxy and just passes it to you.
>  2) the proxy is evil and generated it
>  
>  either way, your solution is to ignore it.
>   (it is an error to receive it this way)
>  
>  so, if your talking via a proxy, always ignore 305.
>  
>  --
>

I agree that it is more efficient that a proxy handle 305 on behalf of clients, 
but I don't see it as necessary. It isn't clear that forbidding a proxy 
to forward the response is a good idea; you would be forcing proxies to 
handle all URI types for a client, for example, and this has unfortunate 
implementation implications (and may have other subtle implications).

The fundamental issue is the trust issue: you've delegated the trust to 
your proxy, and if your trust is misplaced, all the work in the world in 
the client won't help you. I've got you so many ways to Sunday that this 
is the least of your problem. So I don't see such a restriction as a help, 
but just making more of a problem. 	
			- Jim
--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Thursday, 8 January 1998 10:31:27 UTC