On Sun, 29 Aug 2004, Jim Jagielski wrote: > I myself would "define" the cookie header as an entity header, > since it *is* meta data about the body, but I can also see > it as a more traditional "response header" as well. > But wouldn't adding new info about the response (either > as a response header or entity header) invalidate it > actually *being* 304 (Not Modified)?
Would it? A cookie is not data about the body. The nearest analogy amongst headers explicitly discussed in rfc2616 is authentication, and the relevnt authentication headers *are* returned with a 304. So are Content-Location, ETag and Vary: surely headers that would invalidate the 304-ness if they were to change between requests? Perhaps a better approach to 304 headers would be to explicitly exclude entity headers as enumerated in rfc2616, rather than explicitly include non-entity headers? That means the default for proprietary extensions (which HTTP explicitly permits) becomes to allow them in a 304. -- Nick Kew
