RE: Questions (errata?) about caching authenticated responses

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: donderdag 27 juli 2000 1:02
> To: Joris Dobbelsteen
> Cc: 'Mark Nottingham'
> Subject: RE: Questions (errata?) about caching authenticated responses
>
>
> Quoting Joris Dobbelsteen <joris.dobbelsteen@mail.com>:
>
> > >   Cache-Control: public, max-age=0, must-revalidate
> >
> > can't you just send Cache-Control: public, s-maxage=0,
> proxy-revalidate
> > This in order to let the user agent benefit from it's own (private)
> > cache?
>
> s-maxage isn't widely supported, as far as I can tell.
> max-age is safer.

Looked at RFC2616 only, don't have experience with that. So i assume that
you are right...

>
>
> > Agree,
> > however you need to cache the 'access denied' document if
> AUTHORIZATION
> > is
> > not used, so there are 2 items with the same URL (if you
> want optimal
> > caching and it is allowed by the server).
>
> That isn't possible in the HTTP.
>

I think it can be possible, however it's not supported by any cache, nor is
it described in the RFCs (the 401 status code is not cachable according to
the RFC I assume) how to do it. But we better conform to the real standards
and forget this option, until maybe a new version of HTTP.
OK, so (in HTTP/1.1) that is not supported...

>
> > > If you wanted to have user-specific copies cached, I suppose
> > > you could use
> > > the Vary mechanism:
> > >
> > >   Vary: Authorization
> >
> > Usually you store user-specific only in the private cache, e.g.
> > cache-control: private, so you don't waste space on the
> proxy, since all
> > documents are regenerated (like CGI, ASP and PHP). Most
> users work on
> > one
> > machine only (most of the time).
> > All right, this means only unauthenticated responses are
> returned from
> > the
> > cache, but don't server send for documents that require
> authentication
> > and
> > are not authenticated (yet) normally the HTTP/1.1 401 Unauthorized
> > reponse
> > code? You should rater reserve cache space for the
> unauthorized document
> > and
> > the authorized (authenticated) document.
>
> I'm not sure I understand the question.
>

Can always take a guess...

Use the headers:
cache-control: public
Vary: Authorization

This means if a user authenticates to the server, a document is still
downloaded from the server. If no authorization header is included you will
most likely get a 401 status code, what will be send to give the user agent
a chance to send authentication data. This means only the 401 status code
can be cached (if allowed by the RFC), and other responses are not cached by
a shared cache.
In this cache you:
* Don't benefit from the shared cache, since the 401 status code is (most
likely) not cached.
* You could use the header "cache-control: private", since it won't make any
difference

If you get a document (HTTP/1.1 200 reponse) then you whould benefit from
the shared cache, but it won't leave the possibility open for the client to
authenticate, since it's not required. Some User-agent (clients) won't
authenticate unless explicitly requested. At least I think this is what a
saw when developing a HTTP/1.1 proxy server and did some testing with
IE/4.0+. I did some console dumps of the requests.
In this cace you would:
* benefit from a shared cache, at least for unauthenticated requests
* get no authorization from (some) clients. They connect anonymously.

Correct???

>
> Cheers,
>

Received on Thursday, 27 July 2000 13:31:54 UTC