httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: Bug 18388: cookies
Date Mon, 30 Aug 2004 16:02:04 GMT


Nick Kew wrote:
> 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.

fwiw, this was discussed a few times in the archives.  the one that comes to
mind for me is this from doug:

  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=99298523417784&w=2

with a follow-up from roy:

  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=99298706923706&w=2

and an unanswered follow-up again from doug:

  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=99299111304649&w=2

personally, I tend to see it more from doug and nick's perspective and would
be inclined to fix a long-standing issue that never made sense to me, but
roy wrote the book and has unique insight here, so...

--Geoff

Mime
View raw message