Re: Comment on http 1.0 draft 01: authentication and caching

Koen Holtman writes:
> 
> In section 10 of <draft-ietf-http-v10-spec-01.txt>, it says:
> 
>    Proxies must be completely transparent regarding user agent
>    authentication. That is, they must forward the WWW-Authenticate and
>    Authorization headers untouched. HTTP/1.0 does not provide a means
>    for a client to be authenticated with a proxy.
> 
> I read this to imply that caching proxies may never cache responses to
> requests with Authorization headers.
I think, that once we have the pragma no-cache, this should be applied to
every non-cacheable responses. 
> Is this really the intended meaning?  It sounds like a wasteful
> requirement to me.
> 
> I feel that passing along Authorization headers untouched is fine as a
> default, but that there has to be some way to override this default.
> 
> A response message could contain a header to explicitly _allow_ a
> proxy cache not to be transparent, e.g.
> 
>    URI: <http://shopping.com/food/vegetables/carrots.gif>;
>         unvary="authorization"
> 
> The `unvary' would tell the cache that the response does not vary if
> the Authorization header varies, implying that no authentication is
> done on http://shopping.com/food/vegetables/carrots.gif.  This would
> allow the proxy cache to act non-transparently, to serve future
> requests for that picture from cache memory without ever contacting
> the origin server.
And the fact, that the no-cache pragma isn't applied, shall be a garantee,
that the result is cacheable.

Oops! If this is true, - is it, honorable collegaues in WG?
then in shttp draft this should be stated - as long, as any shttp
response isn't appropriate to cacheing, that a Pragma: no-cache 
MUST BE applied in every response, which contain encapsulated shttp messages.

My point is: if the presence/absence of the no-cache pragma means non-cacheable/
cacheable status of the message, then it's very easy to handle in cacheing
proxies the whole question. Oherwise the cacheing proxy should know about every
extension, which may concern cacheability status.
The requirement for caches, that the whole cacheing proxy should be as simple
as possible for better performance, I can't imagine other considerations, which
can overrule my position.
And the WG's point in this question?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Saturday, 12 August 1995 07:33:25 UTC