- From: Ari Luotonen <luotonen@netscape.com>
- Date: Thu, 20 Mar 1997 13:22:16 -0800 (PST)
- To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
- Cc: josh@netscape.com, http-wg@cuckoo.hpl.hp.com
> >example response: > >HTTP/1.1 305 Use Proxy > >set-proxy : http://proxy1.foo.com:8080/ scope=http://www.foo.com/services/ > > > >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 have serious reservations about allowing origin servers to generate 305's. It opens up a security hole that's hard to plug at this point with HTTP/1.1 anymore. This functionality is also redundant with existing, so-called "reverse proxy" functionality. I'm also reluctant to mud up the architectural design -- this would be the first time that we allow remote servers to dictate whether to use a proxy or not. Finally, it adds unnecessary overhead to clients (and intermediate proxies) that have to maintain potentially large tables of what proxy to use for a given site/URL. Let me elaborate on these issues one by one. Security hole: If 305 is allowed by origin servers, intermediate HTTP/1.1 proxies that do not understand 305's hop-by-hope requirement will let it through (I assume at this point it may be too late to impose the hop-by-hop requirement for 305, and expect it to be respected by all implementations). If a client gets a 305 sent by an evil origin server through a proxy, it will override the client's proxy settings, because the client thinks the proxy redirected it to another proxy. This security hole can completely cripple people behind a firewall where the only way out is through the corporate proxy. If some evil site sends a 305 that goes through to the client, the client will from then on try to use a proxy that is inaccessible for it (remember, it needs to go thru the company firewall proxy to get out). If this security hole is narrowed down by the scope rules, it at the same time limits the use of 305 for other uses which I would consider more reasonable for 305 -- namely load balancing between proxies, and diverting away load from a proxy that is scheduled to go down for maintenance. See below how 305 is not necessary for making server-originated proxy redirects. Redundant: 305 is by no means the only way the client can be instructed to go through a proxy. A regular 301/302 redirect could be used, pointing to a "reverse" proxy. A "reverse proxy" appears as a regular server, but is really a proxy when it comes to its content retrieval and management. As far as the client knows, it's an origin server. This has benefits: the real origin server is completele hidden, the users will never have to know about its existence. Also, it keeps the design cleaner where origin servers are origin servers, regarless the implementation style (regular, replicated, reverse proxy); and proxies remain a part of the transport mechanism which is controlled by a flow from client outward, not by origin servers (because they have no knowledge to control the proxy settings of clients). Mudding the architectural design: See above paragraph. Overhead on clients: Basically, 305 generated by origin servers implies having to maintain a proxy setting for every URL. This may be tolerable in clients, but it's worse on proxies which get a large amount of requests. Scope rules complicate things worse. The reasoning for scope rules is primarily to plug the security hole. I would like to get rid of the automatic scope rule restrictions altogether, which entails not allowing origin servers not to be allowed to send 305's at all, and use a combination of regular redirects and reverse proxies instead. By virtue of "trusted proxies" you can allow global proxy redirects (if scope is not present), which allows *all* requests earlier targeted for a given proxy, to be completely diverted to another. With auto-scope-rule-restrictions this would be next to useless, because every new site (at least) would require a new hop by the original proxy, just to get a new proxy redirect. Conclusion: I would definitely like to have a proxy redirect that can be generated by a proxy only. If people can come up with examples where 305 from origin servers is the only way to accomplish something that couldn't be done with regular redirect combined with a reverse proxy, then maybe we could have two separate proxy redirections: 305 Use proxy -- use proxy, generated by origin servers 306 Proxy redirect -- use another proxy instead, gen'd by proxies only Cheers, -- Ari Luotonen * * * Opinions my own, not Netscape's * * * Netscape Communications Corp. ari@netscape.com 501 East Middlefield Road http://home.netscape.com/people/ari/ Mountain View, CA 94043, USA Netscape Proxy Server Development
Received on Thursday, 20 March 1997 13:24:27 UTC