-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For Apache, prefer 308 Permanent Redirect to 301 Moved Permanently #137
base: master
Are you sure you want to change the base?
Conversation
Applies to the modern configuration only. Relates to mozilla#117.
x-ref: "308 Permanent Redirect" mozilla#117 "For Apache, prefer 308 Permanent Redirect to 301 Moved Permanently" mozilla#137
x-ref: "308 Permanent Redirect" mozilla#117 "For Apache, prefer 308 Permanent Redirect to 301 Moved Permanently" mozilla#137
x-ref: "308 Permanent Redirect" mozilla#117 "For Apache, prefer 308 Permanent Redirect to 301 Moved Permanently" mozilla#137
lighttpd mod_redirect in lighttpd 1.4.75 and later takes a more nuanced approach by default and uses 301 Moved Permanently for all GET/HEAD requests or for HTTP/1.0 requests with other HTTP methods. For HTTP/1.1 or later, lighttpd mod_redirect uses 308 Permanent Redirect for HTTP methods which are not GET/HEAD. The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) https://www.rfc-editor.org/rfc/rfc7238 For redirection involving HSTS, all clear-text http requests are redirected unconditionally to https. Absent HTTP version support similar to what is in lighttpd 1.4.75, 308 Permanent Redirect should be used for all HSTS redirects, as that is the proper behavior for methods which are not GET/HEAD. If a small number of end-users encounter problems with this recommended setting with specific old clients, then that small number of end-users can adjust the configs to use 301 instead of 308, and trade-off HSTS redirecting all HTTP methods other than GET/HEAD to HTTP GET method to the https location. |
@janbrasna you added a label that this change is blocked by the spec. I understand that the implementation in this PR modifies the guidelines to add the permanent redirect code to the spec, but I do not think we should implement it that way. If, in the future, we generate older versions of the site, we should do so from source control, or source control snapshots of the site generated at certain tags. We are not currently testing that the current site including templates works with all prior versions of the guidelines, are we? I don't see the utility of doing so. |
Applies to the modern configuration only.
Relates to #117.