Re: ISSUE PROXY-AUTHORIZATION: Proposal wording

At 05:16 PM 7/8/97 -0400, Dave Kristol wrote:

>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.

In the case of authentication or any other self contained "components" of
the protocol there is no reason not to allow a proxy to act authoritatively
on the behalf of it's user(s).

Another example is taken from the PEP spec: An elementary school wishes to
enforce a certain policy for accessing information on the Internet. The
local school proxy can act authoritatively as a retrieval filter on behalf
of the pupils instead of having distributed filtering enabled on each of
the user agents using the client.

The trust may be based on some out-of-band agreement which is of no concern
to HTTP as such. The only thing that HTTP cares about is that all HTTP
messages in and out of the proxy are compliant with the protocol.

What about simply saying that

   The WWW-Authenticate and Authorization header fields are end-to-end
headers 
   following the rules found in section 14.8 and 14.46. Both the Proxy-
   Authenticate and the Proxy-Authorization header fields are hop-by-hop
   headers (see section 13.5.1).

instead of

   Proxies MUST be completely transparent regarding user agent authentication 
   by origin servers. That is, they MUST forward the WWW-Authenticate and 
   Authorization headers untouched, and follow the rules found in section
14.8. 
   Both the Proxy-Authenticate and the Proxy-Authorization header fields are 
   hop-by-hop headers (see section 13.5.1).

Section 13.5.1 gives us the flexibility to leave open who is the "ultimate
recipient":

  o  End-to-end headers, which must be transmitted to the
     ultimate recipient of a request or response. End-to-end
     headers in responses must be stored as part of a cache entry
     and transmitted in any response formed from a cache entry.

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 8 July 1997 15:39:51 UTC