Re: 305 Use proxy
Josh (josh@netscape.com)
Wed, 19 Mar 1997 16:40:59 -0800 (PST)
> 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/
-----------------------------------------------------------------------------