Dnn.platform: Page redirect always returns 301 (permanent) regardless of setting

[adam-j-mclellan]

Description of bug

Page redirect always returns 301 (permanent) regardless of setting.

Steps to reproduce

1. Create a new page
2. Redirect to an existing page (i.e. Home), DO NOT check "Permanent Redirect"
3. Load the page
4. Observe that the page is redirected using a 301 (permanent) redirect

Current behavior

The permanent redirect setting is not observed.

Expected behavior

The permanent redirect setting should be observed; in this case, the page should be redirected using a temporary redirect (302 or 307).

Screenshots

Additional context

I suspect this may be related to Advanced URL Management. Changing DNNFriendlyUrl to urlFormat="humanfriendly" (and accessing PageName.aspx) returns a 302 or 307 redirect as expected.

My primary dev system is Windows 10 running IIS 10, FYI.

Affected version

• [X] 9.4.4
• [X] 8.0.4
• [X] 7.4.2

Affected browser

• [X] Chrome
• [X] Firefox

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[adam-j-mclellan]

This is not stale

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[stale[bot]]

This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.

[adam-j-mclellan]

This is very much not stale and should not have been closed. Is it possible to reopen or do I need to log it again?

[adam-j-mclellan]

Just confirmed that this is still an issue as of 9.7.1

[mikesmeltzer]

I've confirmed this is still an issue in v9.8.

Can someone (@bdukes, @valadas, @mitchelsellers, @david-poindexter) assign this to me and I'll triage/fix it.

Thanks

[mitchelsellers]

@mikesmeltzer THanks for the dedication!

[mikesmeltzer]

I've tracked down this bug. For some reason, the code does not evaluate the user specified page redirect setting (Permanent or Temporary) to determine the appropriate response code but instead always forces both External and Internal page redirects to be 301 Permanent redirects based upon a static setting (ForwardExternalUrlsType).

I will submit a PR shortly that changes the logic so that the response code is based upon the page setting (Permanent or Temporary) instead of the static setting.

Additionally, since ForwardExternalUrlsType is statically defined, not driven by the database as other Friendly Url Settings are and is only used in this area in the platform; I recommend we deprecate the setting. I will submit a separate issue and PR for this.