Permanent redirects

[marcelstoer]

Details

• Read the Docs project URL: https://nodemcu.readthedocs.io/
• Build URL (if applicable):
• Read the Docs username (if applicable):

Expected Result

The exact redirect configured as /en/latest/en/$rest -> /en/latest/ should redirect from https://nodemcu.readthedocs.io/en/latest/en/sdcard/ to https://nodemcu.readthedocs.io/en/latest/sdcard/ using HTTP 301 or 308.

Actual Result

HTTP 302, temporary redirect (ignore the discussion whether to use HTTP 302 or 303 or 307 for temporary redirects for now). I would assume that users rewriting URLs in the RTD context mean to do that with "permanent redirect" in mind.

[humitos]

I suppose that this is a 302 on purpose, because otherwise we will exposing a redirect that could be dangerous for the user if they make a mistake.

I would not change this and expose the users to this problem.

What's your current problem with the 302 that makes you need a 301?

[marcelstoer]

No real problem but I argue that it is semantically incorrect.

• My redirect rule is not temporary as the HTTP status suggests but permanent. I restructured my documentation (which made the rule necessary in the first place) and I don't intend to ever revert that. Should I need to change the structure again in some way a new, different rule would be required.
• Because of the above user agents will for ever have to make two requests. It's unnecessary to delay the delivery of the documentation to the user and put extra load on your infrastructure.

[marcelstoer]

Ah, it's obvious but missing on the above list...

If you send temporary redirects to search engine crawlers they won't update their index. Thus, they will forever keep the old URLs (-> more load on your infrastructure).

[davidfischer]

I think a 302 is the best choice. If you make a mistake with a 301 redirect, there isn't a good way to reverse that change. Chrome and Firefox cache 301s until the user manually clears their cache so a mistake is essentially permanent for users who don't manually clear their cache. I don't like to present users with choices where they can make nearly permanent mistakes.

[marcelstoer]

I appreciate your feedback and I understand you have a slightly different perspective. If you allowed us to edit a redirect rule (currently I can only add or remove) then you could simply add a "permanent yes/no" checkbox. That way we could tune our rules until everything works as expected - a which point we could enable the flag.

[davidfischer]

That's fair. I would consider it as an option but the default should be 302.

[humitos]

We do have a Redirect.http_status field that its default is 301, although we are not using it anywhere.

I think we could accept a PR that:

• create a migration to update the default to 302
• use this value when redirecting
• tests for the different cases

Then, we can handle special cases like this one manually (instead of building a whole UX/UI) initially.

[saadmk11]

@humitos I'm a bit confused about the second point. As one Project might have many Redirect objects which one should we use for redirecting.

[humitos]

@saadmk11 each Redirect object has a http_status value on its own. So, when one instance of a redirect that match the url, we access that field and return that status code.