Adrian Hope-Bailie wrote on 01.07.2015 15:41:
> WRT caching, it seems to me that a server that supports the upgrade
> will do a redirect when it first receives this header and should
> simply use Cache-Control : no-store in the redirect response
That's true for redirect responses to requests containing a "Prefer:
upgrade-insecure-requests" header field.
> and never use the Vary header anyway. It's likely that in the upgrade
> scenario this flow will only happen once per client and so the value
> of caching this step is low.
I do not think that this works in all cases because the server must
serve also clients which do not send the "Prefer:
upgrade-insecure-requests" header field, because there may be
intermediate caches and because the server must provide different
responses to the clients do send the "Prefer: upgrade-insecure-requests"
header field than to the ones which do not.
If the server uses neither "Vary: Prefer" nor "Cache-Control:
no-store"/"Cache-Control: private" (or similar), it is possible that all
clients get the same response from an intermediate cache regardless of
whether or not the client did or did not send the "Prefer:
upgrade-insecure-requests" header field. Thus the response is incorrect
either for the ones which did send the header field or to the ones which
did not send that.
There are basically three ways to serve both the clients which do send
the "Prefer: upgrade-insecure-requests" and the ones which do not:
1. The server can disable caching completely using "Cache-Control:
no-store" for all responses. In that case the server-driven redirect
negotiation is done repeatedly for each and every request
separately. This gives correct result and may have considerable
performance impact.
2. The server can disable all intermediate caches using "Cache-Control:
private" (or similar). In that case the server-driven redirect
negotiation is done once for each end every client separately (but
not repeatedly for the same client).
3. The server can delegate caching and redirect negotiation to caches
using "Vary: Prefer" at least for all non-redirect responses. That
way request from the first client sending the "Prefer:
upgrade-insecure-requests" header field after the ones which do not
reaches the server and the server and respond differently than to
the earlier clients request.
BR,
Eero
Received on Wednesday, 1 July 2015 16:22:18 UTC