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.
> >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

Josh Cohen				        Netscape Communications Corp.
Netscape Fire Department	     	       "Mighty Morphin' Proxy
Server Engineering             

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