Question

I have the following situation:

• User makes request to PAGE A that displays a form (server stores cache of this page)
• User submits the form to CONTROLLER that is used for form submit
• CONTROLLER finds an error in user submitted data, sets a cookie ERRORS detailing such, and redirects the user back to PAGE A
• PAGE A shows the original content plus the ERRORS (server stores cache of this page)
• PAGE A deletes ERRORS cookie

This works, but only if I don’t use cache on my system for PAGE A.

Problem is that, after deleting the cookie, browser makes a request to my server without the cookie and gets a 304 Not Modified error and, as a result, the browser still shows the page with the error, instead of without (from the original request). Server stores cache properly (for page that has an error as well as an error-free page).

Basically the server has two cached pages now: PAGE A and PAGE A WITH ERRORS.

Browser, whose last known page was PAGE A WITH ERRORS asks for server a page with conditions of PAGE A, instead of PAGE A WITH ERRORS, since cookie does not exist anymore. But it thinks that the 304 response is about the PAGE A WITH ERRORS, instead of PAGE A. I even checked the data sent by the browser, it knows that it got PAGE A WITH ERRORS with the ERRORS cookie, yet accepts 304 not modified when making requests without that cookie. It does not validate its own cache against the conditions it was created under.

Doesn’t browser validate its cache with the cookies it has set?

And is there a workaround for it without setting some GET variables for each request? Another alternative is to tell servers to never cache pages that have such an ERRORS state set, but that would be a hack.

Answer 1

Apparently the solution was to include this as a response header:

Vary: Cookie

This will take cookies into account in caching engines.

EDIT:

There is a problem though: Chrome, Internet Explorer and Firefox work as expected, but Safari and Opera both ignore ‘Vary’ header when storing and validating cache.