StackOverflowNewbie
StackOverflowNewbie

Reputation: 40643

Caching not working in HTTPS

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:

  1. When I load a resource (say, resource-a) from an HTTP page (all resources will come from HTTP when on an HTTP page), I get a 200 OK. When I reload the page (or go to another HTTP page), resource-a gets a 304 Not Modified.
  2. When I load resource-a from an HTTPS page (all resources will from from HTTPS when on an HTTPS page), resource-a is loaded from HTTPS and get a 200 OK. And when I reload the page (or go to another HTTPS page), I get a 304 Not Modified.
  3. When I return to an HTTP page, resource-a still gets a 304 Not Modified.
  4. When I return to an HTTPS page, resource-a gets a 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

Answers (4)

Phung D. An
Phung D. An

Reputation: 2632

There is a bug with Chrome. So sad no-one care enough to fix that

https://helpx.adobe.com/mt/experience-manager/kb/cache-problems-on-chrome-with-SSL-certificate-errors.html

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

JorisG
JorisG

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

rajukoyilandy
rajukoyilandy

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

Chris Heald
Chris Heald

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

Related Questions