W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: list of pending proposals

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 14 Sep 1995 16:06:23 -0700
Message-Id: <199509142306.QAA14943@bert.amazon.com>
To: Ari Luotonen <luotonen@netscape.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Ari Luotonen writes:
 > >  > > 2. Proxies should be allowed to forward requests for methods that they
 > >  > > do not understand, instead of being required to return 501.
 > >  > conditionally or uncondititonally?
 > > 
 > > I'd prefer if they MUST forward requests, with certain constraints
 > > (e.g. when no protocol translation is required), but that might not be
 > > backward compatible enough.
 > Absolutely not.  New methods can open up new security leaks from
 > inside of firewall, and the default should always be to deny access to
 > something that the firewall proxy doesn't understand.
 > Cheers,
 > --
 > Ari Luotonen				ari@netscape.com
 > Netscape Communications Corp.		http://home.netscape.com/people/ari/
 > 501 East Middlefield Road
 > Mountain View, CA 94043, USA		Netscape Server Development Team

OK, ok.  I don't mind having it be configurable.  What I do mind is
having the default structure of the net set up to make it hard to add
private methods that anyone can get to without negotiating with all
the proxy operators in the world.  HTTP is extensible, and decisions
about the forwarding policy have a huge impact on that extensibility.
To me it makes sense to allow unknown method requests by default in
the outward direction from a protected net, and to have the control be
configurable in the incoming direction.

I also argued before that (e.g.)
	GET	/cgi-bin/delete-all-files
is no worse than

and that the origin HTTP server is an adequate place to control this,
and a better place to control this than any proxy could be.

Received on Thursday, 14 September 1995 16:12:37 UTC

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