- From: Jamie Lokier <jamie@shareable.org>
- Date: Wed, 24 Jun 2009 22:03:48 +0100
- To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Additionally, the default in PHP (at least my copy of v5.0.4) seems to be > "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, > pre-check=0", and I seem to recall that the MoinMoin wiki had that, too, > at least last year (but in that case I may be misremembering). > > Given the extensive use of no-store in situations where it does not seem > necessary, I have started wondering if Opera need to start ignoring the > no-store header in non-HTTPS responses, just like we currently only accept > must-revalidate (interpreted as re-validate on history navigation) only > for HTTPS responses. No decision has been reached yet. Oh. My. Goodness. You ignore must-revalidate? Thanks for letting me know that Opera is broken. "Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails." Do you have a suggested workaround for this client bug? The only one which comes to mind is redirecting to an HTTPS-equivalent page when the User-Agent indicates Opera. Something cheaper would be nice. If I've set must-revalidate, it's because I want my Etags revalidated, thank you. As in, when the user visits the page, they must not see an out of date page. It causes confusion if they do. Web applications, you know the sort of thing. Your interpretation that the directive wasn't really intended is just another step in a silly arms-race, where we have to add yet more workaround on the server side to compensate for clients who don't follow simple specifications. -- Jamie
Received on Wednesday, 24 June 2009 21:04:26 UTC