W3C

Supporting HTTPS and HSTS on w3.org

Photo showing LED lights on the W3C servers at MIT.
W3C servers at MIT.

W3C advocates that the Web platform “actively prefer secure communication”. Thanks to recent work in the Web Application Security Working Group and supporting client implementations, and the deployment work of the W3C Systems Team, we are now able to provide HTTPS access to all W3C resources. All W3C documents, including Recommendations, DTDs, and vocabularies will be available with the authentication, integrity-protection, and confidentiality HTTPS supports.

HTTPS deployment posed some challenges based on our commitment to preserve substantial archives of historic material (for which we could not simply assume that all links were scheme-relative or convert all included content to HTTPS) and the desire to maintain availability to older clients in the field that might support only HTTP. Accordingly, our setup makes use of the Upgrade Insecure Requests spec, but does not force HTTPS on those who start from HTTP.

In detail

The upgrade to HTTPS/HSTS support involves the following:

  • Support of the Upgrade-Insecure-Requests HTTP request header for transparently requesting the upgrade of HTTP requests to HTTPS ones. Note that you will only get the benefits of this feature if your browser sends this header.
  • Support of the Strict-Transport-Security HTTP response header (HSTS) for instructing browsers that they should transparently transform all HTTP requests to HTTPS ones for all access to the www.w3.org domain. All recent browsers support this header. It allows to convert a site to HTTPS without needing to revise the content of all the legacy resources that may have hard-coded HTTP links. We have been supporting this header in lists.w3.org and other domains for a long time.
    This status is cached in the browser for a given time and will be refreshed each time you browse an HTTPS link to www.w3.org.
  • We’re not planning at this point of time to enforce server redirection of all HTTP requests to HTTPS ones for public resources. This is due to avoid breaking older software that can’t be upgraded, such as those in built-in devices. This may be done later at another milestone. As a consequence, if your browser doesn’t send the Upgrade-Insecure-Requests header, you’ll need to browse an HTTPS links pointing to www.w3.org to get the benefits of using HTTPS on our site.
  • Note that this change has no effect on namespaces. The actual namespace will continue to use HTTP, even if it is also served through HTTPS. This applies as well for XMI DTD, Schema, and SGML DTDs resources.

There may be some side-effects you need to be aware of:

  • Infinite loops happening if due to server or proxy configuration there are hard-coded redirects to an HTTP link after the HSTS header is cached in your browser. Please send the URL to to sysreq@w3.org so that we can fix it.
  • Mixed-content warnings. They will be raised if you’re using a browser that doesn’t support Strict-Transport-Security. The solution here is to update to a more recent browser.

2 thoughts on “Supporting HTTPS and HSTS on w3.org

  1. Why should you decide for me that I want to fetch the CSS 3 selectors specification via an encrypted channel?
    Why should you decide for me that I want to fetch it via an authenticated channel?
    Why should you decide for me whether I want to use a caching proxy?

    I have been using a caching proxy for years such that I can access the specifications when I am offline and such that they are loaded much faster on my slow internet connection. Thank you for breaking this.

Comments are closed.