httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 54706] New: mod_cache stores and serves the headers specified in Cache-Control: no-cache= or private=
Date Fri, 15 Mar 2013 17:31:38 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=54706

            Bug ID: 54706
           Summary: mod_cache stores and serves the headers specified in
                    Cache-Control: no-cache= or private=
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_cache
          Assignee: bugs@httpd.apache.org
          Reporter: ylavic.dev@gmail.com
    Classification: Unclassified

The mod_cache module handles the Cache-Control directive "no-cache" the same
way whether it specifies a field-name (response header) or not, and "private"
with a field-name is also handled the same way, that is: treat as stale causing
revalidation (ie. send a conditional request to the origin).

According to the RFC2616 14.9.1 :
   no-cache
       If the no-cache directive does not specify a field-name, then a
      cache MUST NOT use the response to satisfy a subsequent request
      without successful revalidation with the origin server. This
      allows an origin server to prevent caching even by caches that
      have been configured to return stale responses to client requests.

      If the no-cache directive does specify one or more field-names,
      then a cache MAY use the response to satisfy a subsequent request,
      subject to any other restrictions on caching. However, the
      specified field-name(s) MUST NOT be sent in the response to a
      subsequent request without successful revalidation with the origin
      server. This allows an origin server to prevent the re-use of
      certain header fields in a response, while still allowing caching
      of the rest of the response.

My understanding is that no-cache with a field-name does concern that
field-name, not the whole response, hence mod_cache is allowed to serve the
cached response if the specified header is not there (with regard to the other
restrictions).

When the specified header is cached, a revalidation is required, and now the
problem is when the "revalidated" response is a 304 (Not Modified), but that
304 does not "overwrite" the headers specified in the no-cache or private
directives. Should mod_cache serve its cached headers or not ?

The RFC does not say anything about the private directive with a field-name,
can one consider it is the same as no-cache, or is it the same difference than
without a field-name (no-cache = revalidation, private = no store, hence
mod_cache would serve the cached headers with no-cache,but not with private...)
?

IMHO, either private or no-cache,mod_proxy should never store (or at least
serve) the headers specified with these directives.

The only applications I've seen so far implementing that feature use :
 Cache-Control: no-cache="Set-Cookie",
none uses private, or anything else than Set-Cookie,and of course these apps
don't overwrite the Set-Cookie on 304, how could they ?

Now consider the following scenario :

clientA => mod_cache:
GET /foo HTTP/1.1

mod_cache => origin:
GET /foo HTTP/1.1

origin => mod_cache:
HTTP/1.1 200
ETag: "etag"
Date: "date"
Expires: "expiry"
Cache-Control: private="Set-Cookie"
Set-Cookie: data=A

mod_cache => client:
HTTP/1.1 200
ETag: "etag"
Date: "date"
Expires: "expiry"
Cache-Control: private="Set-Cookie", max-age=3600
Set-Cookie: data=A

Later on :

clientB => mod_cache:
GET /foo HTTP/1.1
Cookie: data=B

mod_cache => origin:
GET /foo HTTP/1.1
Cookie: data=B
If-None-Match: "etag"
If-Modified-Since: "date"

origin => mod_cache (no Set-Cookie here, the origin wants to continue with
data=B) :
HTTP/1.1 304
ETag: "etag"

mod_cache => clientB:
HTTP/1.1 200 OK
ETag: "etag"
Date: "date"
Expires: "expiry"
Cache-Control: private="Set-Cookie", max-age=3600
Set-Cookie: data=A

That's actually how mod_cache is handling the scenario (with private or
no-cache), and clientB becomes clientA!

Both versions trunk, 2.4 and 2.2 handle no-cache with or without a header as
stale response as a whole.
Both trunk and 2.4 handle private with a header as stale response (as a whole).
Only 2.2 handles private with or without a header as no store (as a whole).

I have got different patches (for all the versions) to strip these headers,
should this bug be valid, but I need to know if they better not be stored or
stripped from the cache (private vs no-cache?).

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message