On 21 Jun 2001, Randal L. Schwartz wrote:
> Uh, it seems a bit fishy to me. "nothing's changed, but by the way,
> set this cookie please". Why change a cookie if nothing else has
> changed?
don't gimme this 'fishy' mumbo jumbo, i'm willing to accept a valid reason
why set-cookie shouldn't be included in a 304 response, but i have yet to
hear one.
let me restate some facts from the thread, quoting rfc 1945:
304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified since the date and
time specified in the If-Modified-Since field, the server must
respond with this status code and not send an Entity-Body to the
client. Header fields contained in the response should only include
information which is relevant to cache managers or which may have
changed independently of the entity's Last-Modified date. Examples
of relevant header fields include: Date, Server, and Expires. A
cache should update its cached entity to reflect any new field
values given in the 304 response.
in andrew's case it sounds like set-cookie falls into here:
"or which may have changed independently of the entity's Last-Modified
date"
quoting his email:
"The cookie records, in part, the time of the last access to
the site. Therefore for each access the cookie is updated."
that to me sounds like a header "which may have changed independently of
the entity's Last-Modified date".
the client stores cached files in a different place than cookies, so
set-cookie is not going to invalidate a cached file.
