- From: Dave Kristol <dmk@bell-labs.com>
- Date: Tue, 8 Jul 1997 17:16:11 -0400
- To: Koen Holtman <koen@win.tue.nl>
- Cc: dwm@xpasc.com, koen@win.tue.nl, frystyk@w3.org, http-wg@cuckoo.hpl.hp.com
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
Received on Tuesday, 8 July 1997 14:55:52 UTC