Allow choice of 301 or 302 http status so links can be purged from search engines

Are you proposing a change?

Solved this by modifying one line on r4032login.module, where is hardcoded "302", so I changed it to "301".

Here is a patch.

Since I don't entirely agree with you, how about changing the patch to make the redirection code configurable? Then admins could pick 301, 302, or 307.

Good idea. Here is updated patch.

@deekayen can you clarify why you think 302 is the right error here? It seems that Google's interpretation of 302 results in clearly undesirable behavior in this scenario.

I don't feel strongly enough to block this any longer. Committed #4. I wasn't a fan of #6's ability to insert any random text into the HTTP header.

Committed to 7.x-1.x, 6.x-1.x, and 5.x-1.x.

I think this change was a mistake. Yes, for unpublished content you'd want a 301 perhaps. However, if the goal is to e.g. help an admin to log in if they got logged, you don't want a 301 which may be cached in their browser.

I would entertain inserting some conditional checks to do alternations between 301 and 302.

Here's a 7.x version that allows you to set a default code and match paths for the other code.

oops, that has a typo in the code comment. I'll fix after rolling the 6.

here's the corresponding 6.x patch

Since we're injecting a user-defined HTTP code, is there any point in adding extra #validate to the settings form to make sure a valid 301 or 302 setting was actually submitted vs someone firebugging the form?

@deekayen - normally the Drupal Form API only allows you to post the options defined in the form. If you modify the options Drupal gives this error message:

"An illegal choice has been detected. Please contact the site administrator."

Here's the 7.x patch with typo fixed.

And with support for the Variable module.

updating title. Since this wasn't released yet, moving back to feature.

committed to 7.x

and 6.x

This fix lacks real documentation of when to use which code or why one might be better than the other for a particular path. If we're going to give people this kind of interface I think we owe it to them to explain when they would want 302 vs. 301. I think it would be ideal to add some documentation before a releases explaining which one people should use and the conditions that they might want the other.

Mostly this makes me think the underlying issues are not understood well enough and we should explore the problem and potential solutions some more.

I think we need a bigger solution (that might be bigger than this issue). What about returning the 403 and putting the login form inside the page instead of doing a redirect. Is there a reason the module doesn't do that?

I agree I'm still not sure this is the right solution.

Maybe we should change this so instead of letting you have pages with a different redirect code, we instead skip the redirect and so serve the 403.

That should be effective in removing e.g. outdated content from search engines. We could have a default node/* pattern

this changes it so we skip the redirect on match, and by default don't redirect any node pages.

How about this?
It keeps the 403 header so that search engines can do the right thing.

I'm alright with keeping 403.

Combines the 2 approaches

This works in testing of a few scenarios.

Ok, thanks - since this provides everything the OP wanted, and also leaves the default behavior unchanged w.r.t. the prior release, let's include it.

committed to 7.cx, here's the corresponding patch for 6.x

tested locally and committed.

follow-up to delete variables in uninstall

committed to 6 and 7