Closed (duplicate)
Project:
Secure Pages
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Jun 2009 at 18:57 UTC
Updated:
1 Oct 2015 at 15:26 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mrfelton commentedI agree that a 301 seems more appropriate. no?
Comment #2
hass commentedUse API functions for "header" in Drupal, please. See http://api.drupal.org/api/function/drupal_set_header/6
Comment #3
mjpa commentedI personally feel this issue is only related to changing the redirect to a 301 (which the patch does fine), the module uses header() in quite a few places and changing to drupal_set_header() should be a separat issue
Comment #4
scottystang commentedI think I have the same problem in that requests to http://mysite.com are using 302 redirects to https://mysite.com instead of 301.
How do I fix this? My .htaccess and httpd.conf files are using 301 redirects properly, but I think the issue I'm having is with the Drupal core files/functions. I can't find the module that is specified above.
Comment #5
dave kopecekThe patch works for me. It would be great if this could be rolled into 6.x-1.x
Comment #6
matthandHas this been committed? It should be. A 302 redirect is NOT recognized by Google for their search ranking. If you use this module without this patch your site will virtually disappear from Google searches.
Comment #7
dpearcefl commentedI agree. Can we get this patch included?
Comment #8
grendzy commentedThat's an extraordinary claim, and is contrary to the citations provided by the OP (as well as personal experience).
The situation is a little more complicated now that the redirect can vary depending on a user's role, so in many cases a 302 is more correct.
Probably the simplest solution is to add a radio button for 301/302, that would also enable custom modules to add more fancy logic by fiddling with the global $conf.
Comment #9
scott m. sanders commentedIt seems true though that if you move to HTTPS from HTTP and Secure Pages does a 302 instead of 301 that your existing Google, Bing, etc. results of HTTP will not automatically go to its HTTPS equivalent and thus will diminish quickly -- though they should rebuild after a while, but the whole point of using a proper 301 redirect is to keep them. (I am no fan of "SEO," but this seems to be the case.)
I was just shown this myself on one of my sites. Luckily there is a patch, but I may be a bit late.
Comment #10
scott m. sanders commentedChange 302 redirect to 301 redirect (D7)
Comment #11
techypaul commentedJust FYI: With regards to #8, our entire site was removed by google after this (we force use ssl across the site). We are back up after making the changes required as per the patch.
Comment #12
roderikThe patch in this issue was still for D6, though the status says D7.
Here's a D7 patch with an admin screen, as was hinted at in the original issue summary. It's because I want to be able to switch things back immediately if strange problems arise, but may be useful for people with special needs. (I don't know of them.)
I kept the default behavior the same (sending a 302) out of fear of breaking existing sites on upgrade. Please discuss the sense in this, and check the wording in the settings page. Thanks.
Comment #13
hanoii@roderik apparently forgot to upload a patch, which I am doing right now. I do believe 301 is the way to go mainly for SEO reasons and because it makes more sense to have a 301 instead of a 302.
Comment #14
john franklin commentedA version of the D6 patch that uses drupal_set_header() in both the securepages_goto() function and the admin/build/securepages/test handler.
Comment #15
davidwbarratt commentedI think #2381857: Possibility to change HTTP response code of the URL redirect is probably a better solution since it's user configurable.