--On Wednesday, June 4, 2003 11:33 AM -0400 Ryan Eberhard
<[EMAIL PROTECTED]> 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 th
ssed
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
e 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
Ad
d 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) ra
uration 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 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 conf
ookie 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
