Responses are cached with max-age=10800 #24690

emodric · 2017-10-25T15:48:22Z

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC?	no
Symfony version	3.4.0-BETA1

Since upgrading to Symfony 3.4.0-BETA1 fom 3.3.10, suddenly all responses started receiving Cache-Control header with private, max-age=10800, no-cache, private value and a response code 304 Not Modified, which means that responses are cached in browsers for 3 hours and only hard reload with Ctrl+R or Shift+R refreshes the page from backend.

git bisect says that the culprit is #24523. And indeed, reverting the commit in that PR fixes the issue for me, meaning Cache-Control header is back to no-cache, private and the response is 200 OK.

The text was updated successfully, but these errors were encountered:

xabbuh · 2017-10-25T16:23:08Z

Are you sure that you just do not have a listener which adds the Cache-Control header in case no session was started?

emodric · 2017-10-25T16:25:24Z

Well, the issue is present on authenticated requests too, so I doubt that's the problem.

nicolas-grekas · 2017-10-25T16:43:45Z

Fixed in #24691

emodric · 2017-10-25T16:56:36Z

Okay, after applying #24691, the header is private, max-age=0, no-cache, private, but the response is still 304 Not Modified. Not sure if that is right...

P.S. Sorry for not specifying before that the response was also 304 instead of 200. I've updated the bug description now.

nicolas-grekas · 2017-10-25T17:07:33Z

304 can only happen when doing conditional validation, which means something is responding (what?) based on a header sent by your browser (If-Modified-Since of If-Match). Please check on your side.

emodric · 2017-10-25T17:40:26Z

@nicolas-grekas I will dig deeper tomorrow to try and find why 304 happens, but the fact is that before #24523, response was 200 OK, and after it's 304 Not Modified and in both cases, my request is identical, and contains If-Modified-Since header.

emodric · 2017-10-25T18:32:19Z

Okay, I think that it might be Apache who sends 304 back to the browser, as I've done tests with Symfony's built in server and no 304 appears.

However, before #24523, response from Symfony was:

HTTP/1.1 200 OK
Cache-Control: no-cache, private

and after:

HTTP/1.1 200 OK
Cache-Control: private, max-age=10800
Cache-Control: no-cache, private

and then after #24691:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Cache-Control: no-cache, private

If Apache is indeed responsible for 304, duplicated Cache-Control headers might be the reason why? WDYT @nicolas-grekas ?

Tobion · 2017-10-26T00:46:13Z

What might happen is that Apache generates an ETag header now due to the presence of the max-age directive. (Just a guess. I wouldn't know why it should be based on that)
And then the browser does a conditional get with the etag. Apache then returns 304 as the reponse didn't change.

emodric · 2017-10-26T05:26:09Z

Although multiple Cache-Controlheaders are supposed to be valid, Apache may also act out due to missing no-cache section in the first header.

I can provide HAR files for requests and responses if that would help. In any case, I'm not sure if it is okay to have a max-age if users don't explicity say so in their controllers.

Tobion · 2017-10-26T10:24:48Z

whether the no-cache directive is there or not, should not make a difference. max-age=0 should mean the same as an expires header in the past. no-cache would just say, the client needs to revalidate. but that is the case anyway due to max-age=0. no-cache just ensures stale responses are not used as well. but that is not the case anyway since you receive a 304.

so to me #24691 fixes the problem and 304 is not a problem. and if you don't want to support conditional get, you can just configure your server or add a no-store cache control yourself to the response.

…olas-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [HttpFoundation] Fix caching of session-enabled pages | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #24690 | License | MIT | Doc PR | - Commits ------- 572e02c [HttpFoundation] Fix caching of session-enabled pages

emodric · 2017-10-26T10:45:09Z

@Tobion If you say so :) But just to be clear, I experienced this on a developer machine where I have Apache installed with a default configuration, so the chances that many developers run into this is high I'd say. Receiving 304 instead of 200 all of a sudden because of the different caching headers could potentially be considered a BC break in my opinion.

Tobion · 2017-10-26T10:53:15Z

What functionality breaks? The page still works doesn't it? The only "break" is when you use functional tests and assert response status 200. But there you don't get a 304 because you don't send conditional gets in functional tests.

emodric · 2017-10-26T11:05:21Z

I was thinking more about the infrastructure if it expects to receive 200 and now starts receiving 304. This is just a wild guess, nothing more. If you say it's a non issue, who am I to argue :)

emodric · 2017-10-26T11:51:27Z

Sorry for being a pain, but I've played around with my site with this fix, and sorry to say, but browser still caches my responses in the backend of my custom app, when I'm fully authenticated.

I realize that this is not necessarily Symfony's fault, but many users will not know the difference and will have their apps broken and blame Symfony.

xabbuh added the Status: Waiting feedback label Oct 25, 2017

nicolas-grekas mentioned this issue Oct 25, 2017

[HttpFoundation] Fix caching of session-enabled pages #24691

Merged

Tobion closed this as completed Oct 26, 2017

emodric mentioned this issue Nov 7, 2017

Session always started after 3.4.0-BETA3 update #24849

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Responses are cached with max-age=10800 #24690

Responses are cached with max-age=10800 #24690

Responses are cached with max-age=10800 #24690

Responses are cached with max-age=10800 #24690

Comments