Re: 305 Use proxy

> Roy said
> > Josh said
> 
> Well, for starters, please use a syntax that can be unambiguously parsed.
> That means enclose all URLs in "double-quotes" or <angle-brackets> if
> you intend them to be used alongside parameters.  I suggest using a
> syntax similar to Link in the RFC 2068 appendix, since it overcame the
> same set of problems.
> 
I expected that :)

> >Suggested rules:
> >Origin servers may NOT send 305, only proxies may send them.
> 
> Nope.  The original intended purpose of 305 is to allow an origin server
> to prevent access unless it goes through the appropriate proxy.
> 
I agree that an origin server based redirect is a good idea,
and although I cant quickly come up with a case for it which
couldnt acheive the same results by other means, I think
this functionality is worthwhile.  However, from a security
standpoint I think its hard to implement.

The two cases are for different uses.

> >The set-proxy header is HOP BY HOP, not end to end.
> 
> You mean that the 305 response is HOP by HOP -- it doesn't make any
> sense to just drop the header field.
Yes.
> 
> >On scope:
> 
> Hmmm, looks like a realm, smells like a realm, why not call it a realm?
> 
Realm has been used before, but its meaning has been made unclear 
since current definitions of Realm have turned into a text
description rather than a specific identifier.
To call this realm might lead to confusion.

> The original description only applied to the exact URL.  I agree that
> a realm would be more efficient, subject to a good set of security
> considerations.
Maybe it is wise to separate proxy originated redirects ( as a means
of load balancing ) from origin redirects.  
Maybe they could share the set-proxy header but use 306 as well as 305.

> >3) Loops / hop counts
> >What happens if proxy A redirects the client to proxy B which
> >redirects it back to A?
> 
> The same that happens on all auto-redirection loops.  It is actually
> noted in the section on 3xx responses.
I think we should leave this to the network designers.

> Create a new one.  The problem with using the Location header was that
> some older client might follow the HTTP rules and treat the response
> as if it were a 300, which would entice it to perform the original
> request on the URL in the Location header, which in this case would
> be the base proxy URL.  I suggest using "Proxy", since it seems more
> advisory in nature than "set-proxy".  Also, you should consider allowing
> the server to send multiple fields so that the client can be given a
> "choose one" option.
Well, I think set-proxy is clearer, since the header is really
advising an action which is 'set to this proxy' for this resource.
> 
> Why not include the notion of "trusted" proxies?  It should be possible
> for a user agent to collect a list of trusted proxies in much the same
> way it would collect a list of trusted cookie sites, and there won't
> be that many proxies for any given user agent.  The user agent could
> then be set to accept direction automatically from trusted proxies,
> and query for all others.
This is a reasonable idea, the list could be given to the client
at the beginning of its session, maybe through the Proxy AutoConfig
methods.

-----------------------------------------------------------------------------
Josh Cohen				        Netscape Communications Corp.
Netscape Fire Department	     	       "Mighty Morphin' Proxy
Ranger"
Server Engineering
josh@netscape.com                       http://home.netscape.com/people/josh/
-----------------------------------------------------------------------------

Received on Wednesday, 19 March 1997 16:40:52 UTC