Re: Bug 18388: cookies
On Mon, 30 Aug 2004, Geoffrey Young wrote: [replying to my words - largely chopped] 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-devm=99298523417784w=2 That thread seems to be the same basic issue, but with reference to RFC1945. 2616 includes additional explanation, and seems more clearly to support the view that not only cookies but arbitrary unknown headers (if any) should be allowed. In the bug report 18388, Ryan J Eberhard wrote: It is also important to note that all other major web servers (IIS, iPlanet, and Domino) will return Set-Cookie headers on a 304 status. I'm in no position to confirm or deny that, but it tends to support the proposition, and suggest that if it caused trouble in the Real World then we could expect to know about it. 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... Hmm. Would proposing it in STATUS for a vote be appropriate here? I think if anyone wants to veto it, we should have a reason that addresses Doug's and Ryan's arguments on the record. -- Nick Kew
Re: Bug 18388: cookies
Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Bug 18388: cookies
On Tue, 31 Aug 2004, Jim Jagielski wrote: Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. I strongly agree. Roy? --Cliff
Re: Bug 18388: cookies
[sent this yesterday, but it bounced] 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... Umm, not really -- cookies are just broken by design. That's why they aren't in HTTP/1.1 and why they are not listed in 304. However, it is kind of pointless to only partly implement them, so go ahead and add Set-Cookie and Set-Cookie2 to the 304 list. Both the original Netscape spec and RFC 2965 allow Set-Cookie* to be sent on any response and expect it to be passed along in a 304, so we might as well allow folks to do totally moronic things with cookies. Roy
Re: Bug 18388: cookies
At 11:53 AM 8/31/2004, Cliff Woolley wrote: On Tue, 31 Aug 2004, Jim Jagielski wrote: Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. I strongly agree. Roy? As Roy just stated, cookies aren't in RFC 2616. Go ahead and apply this fix - I understand both perspectives; cookies as connection/session/auth data, and cookies as content metadata. The specification is really lacking in definition/. Bill
Bug 18388: cookies
Trawling through a few bugs, this one looks valid to me: namely, Set-Cookie headers should be enabled on 304 responses. The current behaviour has a rationale, but I believe it's incorrectly applied. Set-Cookie is a response header and does not affect a cached entity body, so there's no reason to suppress it. The patch is a one-liner. Unless anyone can come up with a reason why it might open a security hole, I'll apply it. -- Nick Kew
Re: Bug 18388: cookies
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)? In both cases, it *is* new information about the response, in which case the full response has, in a sense, been modifed? Nick Kew wrote: Trawling through a few bugs, this one looks valid to me: namely, Set-Cookie headers should be enabled on 304 responses. The current behaviour has a rationale, but I believe it's incorrectly applied. Set-Cookie is a response header and does not affect a cached entity body, so there's no reason to suppress it. The patch is a one-liner. Unless anyone can come up with a reason why it might open a security hole, I'll apply it. -- Nick Kew -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Bug 18388: cookies
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
Re: Bug 18388: cookies
Is it metadata about the body? In many cases, a cookie is semantically information about the session; it might have nothing to do with the particular body at all. On 29-Aug-04, at 5:57 PM, 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)? In both cases, it *is* new information about the response, in which case the full response has, in a sense, been modifed?
