Reputation: 40643
I had previously asked this question and mistakenly thought my problem didn't really exist (see: Caching and HTTPS). I was wrong; the problem does exist.
Here's the description of my problem:
200 OK
. When I reload the page (or go to another HTTP page), resource-a gets a 304 Not Modified
.200 OK
. And when I reload the page (or go to another HTTPS page), I get a 304 Not Modified
.304 Not Modified
.200 OK
. What happened to the cached copy? How can I make it cached?Here's an example for the headers:
Request URL: https://styles.mydomain.com/assets/styles/main.css
Request Method: GET
Status Code: 200 OK
Request Headers
Accept: text/css,*/*;q=0.1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Connection: keep-alive
Host: styles.mydomain.com
Referer: https://www.mydomain.com/sign-in/
User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Response Header
Accept-Ranges: bytes
Cache-Control: public
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 11836
Content-Type: text/css
Date: Tue, 02 Oct 2012 09:51:20 GMT
Expires: Fri, 30 Sep 2022 09:51:20 GMT
Keep-Alive: timeout=5, max=99
Last-Modified: Tue, 02 Oct 2012 09:25:30 GMT
Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.3.8
Vary: Accept-Encoding
Upvotes: 2
Views: 3285
Reputation: 2632
There is a bug with Chrome. So sad no-one care enough to fix that
https://bugs.chromium.org/p/chromium/issues/detail?id=110649#c8
any error with the certificate means the page will not be cached.
Upvotes: 1
Reputation: 83
I'm sorry but I don't see a If-Modified-Since
-requestheader, and if I'm correct (wiki) then, this header is required to allow the server to answer with a 304 Not Modified
.
So the problem is that your client is not sending the correct request, perhaps, your client does not use cached content from http for https requests. So did you refresh in https mode, to check if it is requested on a second https request?
Upvotes: 0
Reputation: 5471
Are you using any .htaccess
file? If yes, place below code in your .htaccess file for caching.
ExpiresActive On
ExpiresByType text/css "access plus 60 days"
Hope this can help you...
Upvotes: 0
Reputation: 62648
This is just a best-guess, but I suspect what's happening is that when you cache your resource over a HTTP connection (or load it from the cache for an unsecured session), it's marked as "not trusted" and is therefore not eligible to be loaded from the cache for a HTTPS connection.
Part of the intent of HTTPS is to ensure that resources were not just secured from eavesdropping in transit, but that they were not modified by a middleman. Consider the following scenario:
[HTTP] GET /foo.js (client -> middleman -> server)
Server replies "blue"
Middleman mutates "blue" into "green"
Client caches "green"
At this point, loading foo.js
from the cache would result in a tainted copy of foo.js
being loaded into your HTTPS session, thereby compromising the security of the entire page view. Since your HTTPS sessions can't validate the authenticity of the file (as it was not cached over a secure connection), it plays it safe and elects to load a new copy of the file to ensure that compromised resources are not loaded.
Your situation is somewhat interesting in that you have a secure-cached copy of the file, but you are returning it from the cache for a non-secure page. My guess is that this is tainting the file, such that it may not be re-used for secure caching. What browser are you using this in?
Edit: And a thought; since you have SSL available, what happens if you just always load the SSL version of the resource? If my guess is correct, this should prevent the cache from being tainted, and should allow the resource to remain cached.
Upvotes: 7