Re: ISSUE PROXY-AUTHORIZATION: Proposal wording
Dave Kristol (dmk@bell-labs.com)
Tue, 8 Jul 1997 17:16:11 -0400
At 9:34 PM +0200 7/8/97, Koen Holtman wrote:
> [...]
>I don't want proxies to be `creative'. I think that HTTP/1.x should
>not allow creative proxies, and am against weakening MUSTs to allow
>such creativity.
>
>If you want a new creative service in a proxy, call it a HTTP/1.1
>proxy which implements the `creative-authentication-rewrite' protocol
>extension on top of HTTP/1.1. The use of creative extensions can be
>negotiated either in-band or out-of-band.
This semantic fussing seems to get us nowhere. Is an "HTTP/1.1 proxy that
implements custom feature X" an HTTP/1.1 proxy or not? Your first
paragraph says "no"; your second implies "yes".
People choose to use a proxy for a number of reasons, always because they
expect to get some benefit. (Otherwise why use the proxy?) I presume they
understand the benefit *before* they start to use the proxy, although I
realize in some environments there can be an automatic configuration.
Understanding the benefit implies they know what the proxy does to/for them.
My original example, LPWA, is transparent except for a little bit of
substitution that only occurs at the user's prompting (by using escape
sequences to induce action). What should we say about content-filtering
proxies that mollify parents and politicians by blocking pre-programmed
stuff? They change the content in the server -> user agent direction. Can
they never be conforming HTTP/1.1 proxies thereby?
I think we're going to see lots of proxies appear that perform some useful
function between an origin server and a user agent, and they're not all
going to be specification-pure in the sense you (Koen) want them to be. I
think we need to have a way to say that a proxy conforms to HTTP/1.1 at all
times in terms of handling connections and content unless its defined
function dictates that it alter the content (or headers?). I agree in
advance that that's *way* too mushy a definition, but I also think that
declaring these functions non-conformant to HTTP/1.1 is too strict.
Dave Kristol