You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Eberhard <ry...@entegrity.com> on 2003/06/03 16:53:02 UTC
Bug 18388: Set-Cookie header not honored on 304 (Not modified) status
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."
>
>
>
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, June 5, 2003 4:52 PM -0400 Ryan Eberhard
<ry...@entegrity.com> wrote:
> I searched the site and did not see a document describing naming conventions
> for directives. If there is one and someone could send me the link, I would
> appreciate it.
Nope, there's nothing like that. Sorry.
The directive name is rather inconsequential and can be changed if someone has
a suggestion later on - the important part is the code. -- justin
Re: [PATCH] Bug 18388: Set-Cookie header not honored on 304 (Not
modified) status
Posted by Ryan Eberhard <ry...@entegrity.com>.
No one seems to have bitten on this patch... I have to admit that I
don't really like modifying server_rec and adding another configuration
directive either.
Would the group be more amenable to a patch that prevented the server
from returning a 304 (Not Modified) code when a Set-Cookie header is
present? This would reduce (hopefully slightly) the effectiveness of
the browser cache, but only when the server has a Set-Cookie header to
send. This should address the concern raised that cached page contents
and cookie values remain in-synch.
Ryan Eberhard
Ryan Eberhard wrote:
> I noticed one minor correction. In the comment line for the change to
> httpd.h I transposed "304" with "403". The comment line should read:
>
>"/** Allow SetCookie header on HTTP Not Modified (304) status? */"
>
>
> Ryan Eberhard wrote:
>
>> Attached is a patch to add a configuration directive to control
>> whether the server is allowed to issue Set-Cookie headers when the
>> HTTP status is 304 (Not Modified).
>>
>> Files changed:
>> http-2.0/include/httpd.h -- Added allow_setcookie_on_not_modfied
>> member to server_rec
>> http-2.0/server/config.c -- Initialization of new member to 0 to
>> preserve current behavior
>> http-2.0/modules/http/http_core.c -- Define directive and set...()
>> method
>> http-2.0/modules/http/http_protocol.c -- Emit Set-Cookie header if
>> status is 304 and directive allows
>>
>> Tests (performed with sniffer):
>> Status 200, directive missing -> Set-Cookie processed
>> Status 304, directive missing -> Set-Cookie ignored
>> Status 200, directive set to "Off" -> Set-Cookie processed
>> Status 304, directive set to "Off" -> Set-Cookie ignored
>> Status 200, directive set to "On" -> Set-Cookie processed
>> Status 304, directive set to "On" -> Set-Cookie processed
>>
>> I didn't see the source for the online documentation, e.g. "Directive
>> Index" and "Apache Core Features" (with the list of configuration
>> directives). If someone would please point me to that source base, I
>> will gladly submit a patch for the documentation too.
>>
>> Ryan Eberhard wrote:
>>
>>>> --On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
>>>> <ry...@entegrity.com> wrote:
>>>>
>>>> > 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.
>>>>
>>>> You are free to submit a patch that does this. -- justin
>>>
>>>
>>>
>>> Thanks. I will take this on. My initial thought is that this would
>>> be configured at server level and there probably should be a
>>> configuration directive, e.g. AllowSetCookieOnNotModified On | Off.
>>>
>>> I searched the site and did not see a document describing naming
>>> conventions for directives. If there is one and someone could send
>>> me the link, I would appreciate it.
>>>
>>> Ryan
>>>
>>>
>>
>>------------------------------------------------------------------------
>>
>>--- httpd.h.old 2003-06-06 13:04:18.000000000 -0400
>>+++ httpd.h 2003-06-06 11:00:57.000000000 -0400
>>@@ -1111,6 +1111,9 @@
>> int limit_req_fieldsize;
>> /** limit on number of request header fields */
>> int limit_req_fields;
>>+
>>+ /** Allow SetCookie header on HTTP Not Modified (403) status? */
>>+ int allow_setcookie_on_not_modified;
>> };
>>
>> typedef struct core_output_filter_ctx {
>>
>>
>>------------------------------------------------------------------------
>>
>>--- config.c.old 2003-06-06 13:01:52.000000000 -0400
>>+++ config.c 2003-06-06 11:01:55.000000000 -0400
>>@@ -1722,7 +1722,9 @@
>> s->limit_req_line = main_server->limit_req_line;
>> s->limit_req_fieldsize = main_server->limit_req_fieldsize;
>> s->limit_req_fields = main_server->limit_req_fields;
>>-
>>+
>>+ s->allow_setcookie_on_not_modified = 0;
>>+
>> *ps = s;
>>
>> return ap_parse_vhost_addrs(p, hostname, s);
>>
>>
>>------------------------------------------------------------------------
>>
>>--- http_core.c.old 2003-06-06 13:05:38.000000000 -0400
>>+++ http_core.c 2003-06-06 11:08:04.000000000 -0400
>>@@ -127,6 +127,18 @@
>> return NULL;
>> }
>>
>>+static const char *set_allow_setcookie_on_not_modified(cmd_parms *cmd,
>>+ void *dummy, int arg)
>>+{
>>+ const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
>>+ if (err != NULL) {
>>+ return err;
>>+ }
>>+
>>+ cmd->server->allow_setcookie_on_not_modified = (arg != 0);
>>+ return NULL;
>>+}
>>+
>> static const command_rec http_cmds[] = {
>> AP_INIT_TAKE1("KeepAliveTimeout", set_keep_alive_timeout, NULL, RSRC_CONF,
>> "Keep-Alive timeout duration (sec)"),
>>@@ -134,6 +146,11 @@
>> "Maximum number of Keep-Alive requests per connection, or 0 for infinite"),
>> AP_INIT_TAKE1("KeepAlive", set_keep_alive, NULL, RSRC_CONF,
>> "Whether persistent connections should be On or Off"),
>>+ AP_INIT_FLAG("AllowSetCookieOnNotModified",
>>+ set_allow_setcookie_on_not_modified,
>>+ NULL, RSRC_CONF,
>>+ "Whether allowing Set-Cookie headers on HTTP Not \
>>+ Modified (304) status should be On or Off"),
>> { NULL }
>> };
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>--- http_protocol.c.old 2003-06-06 13:05:39.000000000 -0400
>>+++ http_protocol.c 2003-06-06 13:08:38.000000000 -0400
>>@@ -1683,6 +1683,12 @@
>> "WWW-Authenticate",
>> "Proxy-Authenticate",
>> NULL);
>>+ if (r->server->allow_setcookie_on_not_modified) {
>>+ const char *sch = apr_table_get(r->headers_out, "Set-Cookie");
>>+ if (sch != NULL) {
>>+ form_header_field(&h, "Set-Cookie", sch);
>>+ }
>>+ }
>> }
>> else {
>> send_all_header_fields(&h, r);
>>
>>
>
RE: merge_dir_config calls
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
Sorry...I intended to put this on 'modules'...which I have now done...mea
culpa
> -----Original Message-----
> From: Marc M. Adkins [mailto:mmadki@Doorways.org]
> Sent: Monday, June 09, 2003 12:21 PM
> To: dev@httpd.apache.org
> Subject: merge_dir_config calls
merge_dir_config calls
Posted by "Marc M. Adkins" <mm...@Doorways.org>.
Apache 2.0.46, W2K, working on a module...
I'm tracing calls to the module's dir/svr create/merge calls (the ones
specified in the module data object along with a pointer to the command
array and the hook register function). I'm not clear on when Apache should
be calling the merge functions.
If I have in httpd.conf:
<Location /TEMP>
directive alpha
</Location>
<Location /alpha/xfer>
directive bravo
</Location>
or
<Directory C:/TEMP>
directive alpha
</Directory>
<Directory C:/TEMP/xfer>
directive bravo
</Directory>
should I be getting calls to merge the two directories in one or both of
these examples?
Currently the only dir merge call I get is from one unnamed directory to
another. I do, however, get appropriate server and directory creation calls
and calls to command handlers for directives I have defined in these
directories.
Hopefully the following trace will clarify more than obfuscate (I trace the
directory or server hostnames on the create calls, then copy them into the
allocated config areas so I can trace them again on the merge calls):
[T] gate_register_hook
[T] gate_cfg_svr_create((null))
[T] gate_cfg_dir_create((null))
[T] gate_cfg_dir_create(/TEMP)
[T] gate_cmd_syntax(alpha)
[T] gate_cfg_dir_create(/TEMP/xfer)
[T] gate_cmd_syntax(bravo)
[T] gate_cfg_dir_create((null))
[T] gate_cfg_svr_create(GATE.Doorways.home)
[T] gate_cmd_baseDir(C:\GATE/doc/htdocs)
[T] gate_cmd_syntax(macro)
[T] gate_cfg_dir_create(/tools)
[T] gate_cmd_syntax(backrub)
[T] gate_cfg_dir_create(/tools/info)
[T] gate_cmd_syntax(mofo)
[T] gate_cfg_dir_create(/tools/info)
[T] gate_cmd_baseDir(C:\GATE/doc/htdocs)
[T] gate_cfg_dir_create(C:/TEMP/)
[T] gate_cmd_baseDir(C:\GATE/doc/htdocs)
[T] gate_cfg_dir_create(C:/TEMP/xfer/)
[T] gate_cmd_baseDir(C:\GATE/doc/htdocs)
[T] gate_cfg_svr_merge((null), GATE.Doorways.home)
[T] gate_cfg_dir_merge((null), (null))
And that's it. Numerous directories created both inside of and outside of
virtual server blocks. A single server merge call that looks as I expect
and a single directory merge call that leaves me perplexed.
I'm probably misunderstanding how these calls are supposed to be used...any
clarification would be helpful.
thx
mma
Re: [PATCH] Bug 18388: Set-Cookie header not honored on 304 (Not
modified) status
Posted by Ryan Eberhard <ry...@entegrity.com>.
I noticed one minor correction. In the comment line for the change to
httpd.h I transposed "304" with "403". The comment line should read:
"/** Allow SetCookie header on HTTP Not Modified (304) status? */"
Ryan Eberhard wrote:
> Attached is a patch to add a configuration directive to control
> whether the server is allowed to issue Set-Cookie headers when the
> HTTP status is 304 (Not Modified).
>
> Files changed:
> http-2.0/include/httpd.h -- Added allow_setcookie_on_not_modfied
> member to server_rec
> http-2.0/server/config.c -- Initialization of new member to 0 to
> preserve current behavior
> http-2.0/modules/http/http_core.c -- Define directive and set...() method
> http-2.0/modules/http/http_protocol.c -- Emit Set-Cookie header if
> status is 304 and directive allows
>
> Tests (performed with sniffer):
> Status 200, directive missing -> Set-Cookie processed
> Status 304, directive missing -> Set-Cookie ignored
> Status 200, directive set to "Off" -> Set-Cookie processed
> Status 304, directive set to "Off" -> Set-Cookie ignored
> Status 200, directive set to "On" -> Set-Cookie processed
> Status 304, directive set to "On" -> Set-Cookie processed
>
> I didn't see the source for the online documentation, e.g. "Directive
> Index" and "Apache Core Features" (with the list of configuration
> directives). If someone would please point me to that source base, I
> will gladly submit a patch for the documentation too.
>
> Ryan Eberhard wrote:
>
>>> --On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
>>> <ry...@entegrity.com> wrote:
>>>
>>> > 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.
>>>
>>> You are free to submit a patch that does this. -- justin
>>
>>
>>
>> Thanks. I will take this on. My initial thought is that this would
>> be configured at server level and there probably should be a
>> configuration directive, e.g. AllowSetCookieOnNotModified On | Off.
>>
>> I searched the site and did not see a document describing naming
>> conventions for directives. If there is one and someone could send
>> me the link, I would appreciate it.
>>
>> Ryan
>>
>>
>
>------------------------------------------------------------------------
>
>--- httpd.h.old 2003-06-06 13:04:18.000000000 -0400
>+++ httpd.h 2003-06-06 11:00:57.000000000 -0400
>@@ -1111,6 +1111,9 @@
> int limit_req_fieldsize;
> /** limit on number of request header fields */
> int limit_req_fields;
>+
>+ /** Allow SetCookie header on HTTP Not Modified (403) status? */
>+ int allow_setcookie_on_not_modified;
> };
>
> typedef struct core_output_filter_ctx {
>
>
>------------------------------------------------------------------------
>
>--- config.c.old 2003-06-06 13:01:52.000000000 -0400
>+++ config.c 2003-06-06 11:01:55.000000000 -0400
>@@ -1722,7 +1722,9 @@
> s->limit_req_line = main_server->limit_req_line;
> s->limit_req_fieldsize = main_server->limit_req_fieldsize;
> s->limit_req_fields = main_server->limit_req_fields;
>-
>+
>+ s->allow_setcookie_on_not_modified = 0;
>+
> *ps = s;
>
> return ap_parse_vhost_addrs(p, hostname, s);
>
>
>------------------------------------------------------------------------
>
>--- http_core.c.old 2003-06-06 13:05:38.000000000 -0400
>+++ http_core.c 2003-06-06 11:08:04.000000000 -0400
>@@ -127,6 +127,18 @@
> return NULL;
> }
>
>+static const char *set_allow_setcookie_on_not_modified(cmd_parms *cmd,
>+ void *dummy, int arg)
>+{
>+ const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
>+ if (err != NULL) {
>+ return err;
>+ }
>+
>+ cmd->server->allow_setcookie_on_not_modified = (arg != 0);
>+ return NULL;
>+}
>+
> static const command_rec http_cmds[] = {
> AP_INIT_TAKE1("KeepAliveTimeout", set_keep_alive_timeout, NULL, RSRC_CONF,
> "Keep-Alive timeout duration (sec)"),
>@@ -134,6 +146,11 @@
> "Maximum number of Keep-Alive requests per connection, or 0 for infinite"),
> AP_INIT_TAKE1("KeepAlive", set_keep_alive, NULL, RSRC_CONF,
> "Whether persistent connections should be On or Off"),
>+ AP_INIT_FLAG("AllowSetCookieOnNotModified",
>+ set_allow_setcookie_on_not_modified,
>+ NULL, RSRC_CONF,
>+ "Whether allowing Set-Cookie headers on HTTP Not \
>+ Modified (304) status should be On or Off"),
> { NULL }
> };
>
>
>
>------------------------------------------------------------------------
>
>--- http_protocol.c.old 2003-06-06 13:05:39.000000000 -0400
>+++ http_protocol.c 2003-06-06 13:08:38.000000000 -0400
>@@ -1683,6 +1683,12 @@
> "WWW-Authenticate",
> "Proxy-Authenticate",
> NULL);
>+ if (r->server->allow_setcookie_on_not_modified) {
>+ const char *sch = apr_table_get(r->headers_out, "Set-Cookie");
>+ if (sch != NULL) {
>+ form_header_field(&h, "Set-Cookie", sch);
>+ }
>+ }
> }
> else {
> send_all_header_fields(&h, r);
>
>
[PATCH] Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Ryan Eberhard <ry...@entegrity.com>.
Attached is a patch to add a configuration directive to control whether
the server is allowed to issue Set-Cookie headers when the HTTP status
is 304 (Not Modified).
Files changed:
http-2.0/include/httpd.h -- Added allow_setcookie_on_not_modfied member
to server_rec
http-2.0/server/config.c -- Initialization of new member to 0 to
preserve current behavior
http-2.0/modules/http/http_core.c -- Define directive and set...() method
http-2.0/modules/http/http_protocol.c -- Emit Set-Cookie header if
status is 304 and directive allows
Tests (performed with sniffer):
Status 200, directive missing -> Set-Cookie processed
Status 304, directive missing -> Set-Cookie ignored
Status 200, directive set to "Off" -> Set-Cookie processed
Status 304, directive set to "Off" -> Set-Cookie ignored
Status 200, directive set to "On" -> Set-Cookie processed
Status 304, directive set to "On" -> Set-Cookie processed
I didn't see the source for the online documentation, e.g. "Directive
Index" and "Apache Core Features" (with the list of configuration
directives). If someone would please point me to that source base, I
will gladly submit a patch for the documentation too.
Ryan Eberhard wrote:
>> --On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
>> <ry...@entegrity.com> wrote:
>>
>> > 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.
>>
>> You are free to submit a patch that does this. -- justin
>
>
> Thanks. I will take this on. My initial thought is that this would
> be configured at server level and there probably should be a
> configuration directive, e.g. AllowSetCookieOnNotModified On | Off.
>
> I searched the site and did not see a document describing naming
> conventions for directives. If there is one and someone could send me
> the link, I would appreciate it.
>
> Ryan
>
>
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Ryan Eberhard <ry...@entegrity.com>.
> --On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
> <ry...@entegrity.com> wrote:
>
> > 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.
>
> You are free to submit a patch that does this. -- justin
Thanks. I will take this on. My initial thought is that this would be
configured at server level and there probably should be a configuration
directive, e.g. AllowSetCookieOnNotModified On | Off.
I searched the site and did not see a document describing naming
conventions for directives. If there is one and someone could send me
the link, I would appreciate it.
Ryan
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
<ry...@entegrity.com> wrote:
> 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.
You are free to submit a patch that does this. -- justin
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Ryan Eberhard <ry...@entegrity.com>.
> > 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."
>>
>>
>>
>
>
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified) status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Ryan Eberhard <ry...@entegrity.com> writes:
[...]
> 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.
--
Joe Schaefer
RE: Bug 18388: Set-Cookie header not honored on 304 (Not modified) status
Posted by David Burry <db...@tagnet.org>.
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:minfrin@sharp.fm]
Sent: Tuesday, June 03, 2003 11:04 AM
To: dev@httpd.apache.org
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
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Bug 18388: Set-Cookie header not honored on 304 (Not modified)
status
Posted by Ryan Eberhard <ry...@entegrity.com>.
All,
I apologize that I didn't see the discussion that had occurred on this
topic already... I had previously gone through the archives, but
neglected to before sending the previous mail.
Despite the quote from Roy Fielding, I stand by my claim that Set-Cookie
is a response-header and not an entity-header.
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."
>>
>>
>>
>
>