- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 4 Jul 1997 22:17:20 +0200 (MET DST)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: koen@win.tue.nl, dmk@bell-labs.com, frystyk@w3.org, http-wg@cuckoo.hpl.hp.com
David W. Morris: > > > >On Fri, 4 Jul 1997, Koen Holtman wrote: > >> >Me too ... I have a single user proxy product which is a direct agent >> >for its owner and only user ... I see no reason to restrict the behavior >> >of such a proxy. >> >> I would argue that products like this are not proxies in the HTTP >> sense, but remote-controlled user agents. Thus, any HTTP proxy >> transparency rules do not apply to them. > >Perhaps, but the app is based on HTTP proxy support and not a private >protocol between the 'real' client and the application. Yes, but the HTTP at the outside of the remote-controlled user aggent does not care about what happens inside the user agent. > I don't see a need >to define a whole new mode of operation when thus far the proxy rules >generally apply. What I propose is not a new mode of operation, it is operation as a user agent. > I guess this is a lot like question of what an >HTTP server is, a client is, etc. From a protocol perspective the >server is everything that conspires to deliver the response and I would >interpret a proxy as everything that conspires to act as an agent for >the original / upstream client and hence would favor wording which does >not restrict behavior which otherwise doesn't compromise the reason behind >the protocol. My opinion is that wording which would allow a proxy to conspire with the user agent and rewrite authentication headers _does_ compromise the protocol: it compromises the trust relations encoded in the protocol. HTTP defines a proxy as an impartial, transparent middle-man: a proxy is supposed to be a reliable conduit, which both parties at either end can trust to act in a certain well-behaved, impartial way. >Dave Morris Koen.
Received on Friday, 4 July 1997 13:20:07 UTC