lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev lynx2.8.4pre.4


From: David Woolley
Subject: Re: lynx-dev lynx2.8.4pre.4
Date: Thu, 12 Jul 2001 09:00:36 +0100 (BST)

> GET request for the page it's supposed to be displaying in my logs. And
> yes, no-cache headers are being used (both Cache-Control and Pragma). Even
> tried tossing a max-age=0 to see if that helped. No such luck.

Pragma: no-cache is actually only defined from client to server, although
it is fairly clear that the big 2 handle it the other way, otherwise
it wouldn't be se widely used in meta elements (which are bad ways of
controlling caches).

User agents, in particular, are allowed to cache very aggressively;
even the big 2 can be set to never revalidate a page or to revalidate
only once per session, but may use heuristics to decide to re-fetch
anyway.

I'm pretty sure that cache-control: no-cache is only defined client to
server too.

You would need at least no-store or must-revalidate or a Vary for
the cookie header (I think cookie may imply a vary, and I think clients
might reasonably be expected not to refetch just because of a cookie
change - client = private cache in the HTTP 1.1 terminology).

NB.  You must use cache-control: private to ensure that public caches
behave properly.

> violating any RFC by doing this. I can work around this by adding
> '?foo=bar' or some such to the URL (and will, if needed) but I find that

This only works because of previous abuse, unless you change the value
each time.  The intention was that the result of GET should depend only
on the URL and Accept type headers, and HTTP 1.1 only considers Accept
headers significant if you use Vary for them.


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]