W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: UPGRADE: 'HTTPS' header causing compatibility issues.

From: Eero Häkkinen <e.hakkinen@samsung.com>
Date: Wed, 01 Jul 2015 16:53:40 +0300
Message-id: <5593F0E4.6020500@samsung.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Richard Barnes <rbarnes@mozilla.com>
Cc: Mike West <mkwst@google.com>, Ilya Grigorik <igrigorik@google.com>, Anne van Kesteren <annevk@annevk.nl>, "Nottingham, Mark" <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

Received on Wednesday, 1 July 2015 16:22:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC