- From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
- Date: Thu, 27 Jul 2000 20:51:03 +0200
- To: 'Mark Nottingham' <mnot@mnot.net>
- Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
> -----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