Supporting HTTPS and HSTS on

Author(s) and publish date

Skip to 2 comments

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 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 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
  • 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 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 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.

Related RSS feed

Comments (2)

Comments for this post are closed.