Received: (qmail 16200 invoked from network); 29 Jan 1998 20:47:14 -0000 Message-Id: Date: Thu, 29 Jan 1998 12:57:28 -0800 (PST) From: Dean Gaudet To: Andrew Brown Cc: apbugs@apache.org In-Reply-To: <199801291839.NAA20325@untraceable.net> Subject: Re: apache feature or bug? >Number: 1742 >Category: mod_cern_meta >Synopsis: mod_cern_meta doesn't do the right thing with 304 responses >Confidential: yes >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Thu Jan 29 12:50:01 PST 1998 >Last-Modified: Fri Jul 30 20:42:09 PDT 1999 >Originator: Andrew Brown >Organization: >Release: all >Environment: >Description: >How-To-Repeat: >Fix: >Audit-Trail: Synopsis-Changed-From: Re: apache feature or bug? Synopsis-Changed-To: mod_cern_meta doesn't do the right thing with 304 responses Synopsis-Changed-By: dgaudet Synopsis-Changed-When: Thu Jan 29 12:51:52 PST 1998 Originator-Changed-From-To: -Andrew Brown Originator-Changed-By: dgaudet Originator-Changed-When: Thu Jan 29 12:51:52 PST 1998 Release-Changed-From-To: -all Release-Changed-By: dgaudet Release-Changed-When: Thu Jan 29 12:51:52 PST 1998 Severity-Changed-From-To: serious-non-critical Severity-Changed-By: dgaudet Severity-Changed-When: Thu Jan 29 12:51:52 PST 1998 Responsible-Changed-From-To: gnats-admin-apache Responsible-Changed-By: dgaudet Responsible-Changed-When: Thu Jan 29 12:51:52 PST 1998 Responsible-Changed-Why: make gnats co-operat Category-Changed-From-To: pending-mod_cern_meta Category-Changed-By: dgaudet Category-Changed-When: Thu Jan 29 12:51:52 PST 1998 State-Changed-From-To: open-suspended State-Changed-By: brian State-Changed-When: Wed May 20 03:04:09 PDT 1998 State-Changed-Why: (suspended is the right state for this, as Dean looked at it and said while it's not 100% correct, it's not a big thing to worry about) State-Changed-From-To: suspended-closed State-Changed-By: fielding State-Changed-When: Fri Jul 30 20:42:07 PDT 1999 State-Changed-Why: The code is 100% correct, regardless. ....Roy >Unformatted: RFC2068 section 10.3.5 states: The response MUST include the following header fields: o Date o ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request o Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant 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. So yeah I suppose we should at least deal with these headers. But these headers tend to be controlled elsewhere in the server usually... so I really don't consider it to be a large issue. Dean On Thu, 29 Jan 1998, Andrew Brown wrote: > i have recently discovered something which would be either classified > as a "feature" or a "bug" so i figured i'd ask you. :) > > when using meta-files, the meta-file only gets fed to the browser in > the mime headers if the browser doesn't have the document cached. if > the browser has the current document cached (ie, it's cache is up to > date, and not stale), then it just receives a "304" directing it use > its cached copy. > > in our application, this could be considered a "nifty feature" since > the meta data we're adding directs the browser to a dynamically > generated version of the page with a prize on it. therefore, if they > don'tt see it the first time, they obviously weren't paying attention > and deserve to lose. > > it could also be considered a bug, since the meta data might be > performing some other function for the site. > > opinions? comments? flames? :) > > -- > |-----< "CODE WARRIOR" >-----| > codewarrior@daemon.org * "ah! i see you have the internet > twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" > warfare@graffiti.com * "information is power -- share the wealth." >