Repository navigation
Should HSTS be used rather than HTTP -> HTTPS redirect? #62
Description
Currently, when the application is visited over HTTP, a 301 redirect response is given as per the spec:
2.1 HTTP Server
[..] When both
httpandhttpsURI schemes are supported, the server MUST redirect allhttpURIs to theirhttpscounterparts using a response with a 301 status code and aLocationheader.
But would it not be more desirable to use HTTP Strict Transport Security?
This has also come up on the Gitter chat:
Aaron Coburn
@acoburnFeb 02 01:59
Noting that a server may implement support for Strict-Transport-Security headers, which is considered best practice and more secure than merely relying on 3xx redirects https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security (HSTS is orthogonal to the Solid protocol specification, but the Solid protocol specification should not make HSTS difficult to implement)Sarven Capadisli
@csarvenFeb 02 10:02
True that. The current language didn't intend to ignore / overstep server's HSTS support. We should encourage HSTS.
See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
Activity
nerdcorenet commentedon Mar 8, 2024
These are two separate solutions to the same problem. I would advise to use them both.
A HSTS header is only interpreted by the web browser client software, and can be ignored (though this would be against the standards).
The 301 HTTP-to-HTTPS redirect ensures that the web server software will never allow connections to the "http://" schema on tcp/80 and will send all web browser client softwares to HTTPS on tcp/443 instead. This cannot be ignored by the web client.