httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Eberhard <ryan.eberh...@entegrity.com>
Subject Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified) status
Date Wed, 04 Jun 2003 15:33:15 GMT
> > Despite the quote from Roy Fielding, I stand by my claim that
> > Set-Cookie is a response-header and not an entity-header.

> How so?  The extension-header mechanism for HTTP headers
> is in the entity-header section of 2616.  Since cookie 
> headers don't appear elsewhere within the 2616 spec, that 
> seems (to me) to be the only natural category for them.

>From RFC 2109, HTTP State Management, section 4.2.1:

   "To initiate a session, the
   origin server returns an extra response header to the client, Set-
   Cookie.  (The details follow later.)"

I made that statement because I consider state management (in the sense 
of an application where cookies are typically used) to be orthongonal 
from cache management issues, which are typically performance / network 
optimization related.

It seems strange that RFC 2616 doesn't mention Set-Cookie at all, since 
2109 predates that document.

On the suggestion that allowing Set-Cookie with 304 could result in 
mismatched content in the browser's local cache and session ID's, this 
is a good point, but it seems more likely that if content were being 
generated with respect to a particular session, then the 304 status 
would not be returned as the document would have changed.

I would appreciate the compromise where this behavior could be 
configured, particularly if there is a way for a module to update the 
behavior programmatically, e.g. without having to edit the configuration 
file.

My only other recourse is to try and force the server to not return a 
304 status, but instead return the content and a 200, when I have a 
cookie to set even though the correct content is in the browser's cache.

Ryan Eberhard wrote:

>All,
>
>I've reopened bug 18388 with the comments below.
>
>I'd love to have a discussion about Set-Cookie's proper definition -- 
>I believe it is a response-header (and thus allowed under a 304) rather than 
>an entity-header.  Given that, the proper algorithm would be to filter out 
>known entity-headers from processing under a 304 rather than explicit listing 
>of the other header types enumerated in RFC 2616.  Set-Cookie is just one 
>example of a header that is not mentioned at all in RFC 2616 (don't know if 
>there are others).
>
>Thanks,
>Ryan Eberhard
>
>Additional comments to bug 18388:
>
>Section 10.3.5 of RFC 2616 makes this statement:
>
>   "If the conditional GET used a strong cache validator (see section
>   13.3.3), the response SHOULD NOT include other entity-headers.
>   Otherwise (i.e., the conditional GET used a weak validator), the
>   response MUST NOT include other entity-headers; this prevents
>   inconsistencies between cached entity-bodies and updated headers."
>
>Note that only entity-headers are forbidden.
>
>Section 4.2 describes three sets of headers: request (defined in 5.3), response
>(defined in section 6.2), and entity (defined in section 7.1).
>
>Each of these three sections lists headers, but "Set-Cookie" is not listed in
>any of the three sets.
>
>Section 6.2 makes this statment:
>
>   "The response-header fields allow the server to pass additional
>   information about the response which cannot be placed in the Status-
>   Line."
>
>and...
>
>   "However, new or
>   experimental header fields MAY be given the semantics of response-
>   header fields if all parties in the communication recognize them to
>   be response-header fields. Unrecognized header fields are treated as
>   entity-header fields."
>
>While section 7.1 makes this statement:
>
>   "Entity-header fields define metainformation about the entity-body or,
>   if no body is present, about the resource identified by the request."
>
>Set-Cookie meets the test of universal acceptance as a known response-header and
>is much better defined as a response-header ("additional information") than as
>an entity-header ("metainformation about the entity-body").
>
>It is also important to note that other major web servers (IIS, iPlanet, and
>Domino) will return Set-Cookie headers on a 304 status.
>
>bugzilla@apache.org wrote:
>
>>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
>>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>>.
>>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
>>INSERTED IN THE BUG DATABASE.
>>
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18388
>>
>>Set-Cookie header not honored on 304 (Not modified) status
>>
>>trawick@apache.org changed:
>>
>>           What    |Removed                     |Added
>>----------------------------------------------------------------------------
>>             Status|NEW                         |RESOLVED
>>         Resolution|                            |INVALID
>>
>>
>>
>>------- Additional Comments From trawick@apache.org  2003-05-31 21:10 -------
>>This has been reported before (in the old PR database, against Apache 1.3).
>>The answer, in the words of Marc Slemko, is:
>>
>>"It is not valid to set a cookie in a 304 response.  Please see section 10.3.5
>>of RFC2616.  That is the reason Apache explictly lists headers that will be sent
>>and why Set-Cookie isn't one of them."
>>
>>  
>>
>
>


Mime
View raw message