W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: 305 Use proxy

From: Ari Luotonen <luotonen@netscape.com>
Date: Thu, 20 Mar 1997 13:22:16 -0800 (PST)
Message-Id: <199703202122.NAA03558@step.mcom.com>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: josh@netscape.com, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2793

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


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.


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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC