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.
[EMAIL PROTECTED] 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
>
>[EMAIL PROTECTED] changed:
>
> What |Removed |Added
>----------------------------------------------------------------------------
> Status|NEW |RESOLVED
> Resolution| |INVALID
>
>
>
>------- Additional Comments From [EMAIL PROTECTED] 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."
>
>
>
