Re: Testing W3C's HTTPS setup

On Mon, Sep 21, 2015 at 1:48 PM, Jose Kahan <jose.kahan@w3.org> wrote:

> We need a solution that will allow to assume all content is https,
> in perpetuity, without needing to upgrade all legacy content.
>

That seems like an unfortunate design decision. I hope you'll change your
mind over time. :)


> > 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.
>
> That's how we set it up.
>

Great! In that case, I still don't understand the problem. If
Firefox/Safari/Edge don't support the features that you need, and you're
not redirecting them, what is the problem that would cause you to roll back
the change?

> * 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. :)
>
> That doesn't make sense. When browsing protected resources, you need
> HTTP, you cannot downgrade it to HTTP systematically. What I think
> you mean to say is that for public resources, apply the rule you said.
> I may be missing some of the context in your statement.
>

I'm sure the setup you're working with will have some special cases (like
resources behind the login wall being HTTPS-only). Those special cases
shouldn't see any change in behavior from today, however, right? Firefox
still works correctly on those pages.

I suppose I should have been more specific. If you don't see an
`upgrade-insecure-requests` header in a request for a page which requires
`upgrade-insecure-requests` to function correctly, then you should
downgrade that request from HTTPS to HTTP. Does that make sense?

-mike