Since there seems to be some disagreement on this, and the RFC doesn't really specify which it is but instead makes a point of leaving it open for discussion, and there are many other popular servers out there that behave differently than apache and therefore some people may come to expect (nay even depend on) behavior different than apache.... What about just making it configurable in the httpd.conf, with the default value the current way? Why make it very difficult for some people to migrate to apache on such an open-ended issue?
If we change the behavior, you are correct in that the possibility exists to get confused about the session id, but in some cases that might even be desireable, for instance, if you're trying to cobble together several different web apps with a common login or something like that without doing an invasive rewrite of the authentication part of each app... It would be nice as an apache administrator to have that option in a case like that. So making it configurable with the default value of the current behavior might make everyone happy.... Dave -----Original Message----- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 11:04 AM To: [EMAIL PROTECTED] Subject: Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified) status Ryan Eberhard wrote: > Despite the quote from Roy Fielding, I stand by my claim that > Set-Cookie > is a response-header and not an entity-header. I would say a cookie is an entity header, in that in its typical use, the cookie value is bound somehow to the page that comes along with it. For example, a cookie might (and often does) contain a session id, while the content of the page is delivered unique to the session. If the cookie is considered a request header, then the possiblity exists for a different session id to be delivered with the original content, which does not necessarily match that session id. Regards, Graham -- ----------------------------------------- [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
