- From: Mike West <mkwst@google.com>
- Date: Mon, 21 Sep 2015 13:27:48 +0200
- To: Jose Kahan <jose.kahan@w3.org>
- Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Received on Monday, 21 September 2015 11:28:35 UTC
On Mon, Sep 21, 2015 at 1:22 PM, Jose Kahan <jose.kahan@w3.org> wrote: > As you say, firefox doesn't seem to support this header when the > server sends it. > In that case, why are you redirecting it to HTTPS and serving the HSTS header? > > Wouldn't it be better to fix the absolute HTTP links? That would solve > the > > problem for Firefox, and browsers like Safari that don't support the > > upgrade feature at all. > > That's not possible. We have too much content and this is what > the combination of HSTS and Upgrade-Insecure-Requests is supposed > to do. > I do hope that you see `upgrade-insecure-requests` as a transitional phase, and that you're working to fix the mixed content errors on the site, rather than relying on browser support in perpetuity. If there's no other available solution at the moment that fixes > firefox's behavior, we'll have to roll-back. > I guess it's not clear to me why you're fine with the current setup for browsers like Safari, but aren't fine with it for Firefox? Wouldn't you just treat Firefox like every other browser that doesn't support the upgrade directive? That is: * If you don't see an `upgrade-insecure-requests` header in the navigation to `http://w3.org/`, don't redirect to HTTPS. * If you don't see an `upgrade-insecure-requests` header in a navigation to `https://w3.org`, downgrade to HTTP (and don't serve HSTS)? This use case is why we added the signaling header. :) -mike
Received on Monday, 21 September 2015 11:28:35 UTC