On Fri, 4 Jul 1997, Koen Holtman wrote:

> David W. Morris:
> >
> >
> >On Fri, 4 Jul 1997, Koen Holtman wrote:
> >  Dave Morris wrote (supporting Dave Kristol):
> >> >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.

I guess you wouldn't want a creative proxy which would re-write
BASIC authentication into digest authentication either?  Renaming
a program to be a user-agent or client because it doesn't follow an
arbitrary rule doesn't accomplish anything in terms of trust, etc.
It could mean the omission of Via: headers.  Addition of two UA headers?

Allowing the ultimate UA to anticipate authentication requests is a much
bigger trust (but a mandatory operational requirement) compromise than
allowing a proxy to re-write authentication credentials. For practical
purposes, proxies are agents of the requesting client and any trust which
must exist is on behalf of the client/UA.

Received on Friday, 4 July 1997 14:01:14 UTC