After upgrade from 6.x-1.9 to 6.x-2.0 or 6.x-2.1, many pages that should be redirected to https are instead displaying a white screen with the words "302 found" at the top of the page. The url shown in the browser is the correct URL for the target page.

If I comment out line 162 of securepages.module:

print "302 Found";

and clear the cache, then the redirect appears to complete successfully (at least on the pages I've checked).

CommentFileSizeAuthor
#4 Screen_Shot_2013-11-19_at_1.14.39_PM.png245.83 KBgrendzy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gordon’s picture

gordon CreditAttribution: gordon commented
Version: 6.x-2.1 » 6.x-2.x-dev
Status: Active » Fixed

I think this is something different in how the bufferering is use to be done. I have removed the line which should help things.

grendzy’s picture

grendzy CreditAttribution: grendzy commented
Category: Support request » Bug report
Status: Fixed » Needs work

I believe outputting "302 Found" is correct. A non-empty body is necessary for Drupal to cache the response. rclemings, are you using Boost? Other boost users have reported this: #1415292: Securepages prints "302 Found" which is cached by Boost as is..

According to rfc2616, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

Gordon, if we can determine this issue is caused be the Boost bug, what do you think about reverting the last change? Boost is fundamentally incompatible with securepages anyway, because it cannot differentiate between HTTP and HTTPS pages (see #1070048: New folder structure).

rclemings’s picture

rclemings CreditAttribution: rclemings commented

No, not using Boost. And in any case there is no hyperlink, just the words "302 Found" in plain text, so that users are left staring at those two words with no redirect and no idea of what they should do next.

grendzy’s picture

grendzy CreditAttribution: grendzy commented
FileSize
Screen_Shot_2013-11-19_at_1.14.39_PM.png245.83 KB
grendzy’s picture

grendzy CreditAttribution: grendzy commented

Hmmm, that is really strange. When you see the "302 found" message in your browser, what is the HTTP status code? (you can determine this from the network inspector in Chrome). I'm not able to reproduce that with 6.x-2.0. If you have an opportunity to test with a fresh D6 install, can you report the outcome here?

I agree the code could be improved by adding an actual link as the RFC says (the original message was just added as filler to make drupal_page_set_cache() happy).

grendzy’s picture

grendzy CreditAttribution: grendzy commented

One note, the reason this wasn't caught by the tests is the redirect test assertion was commented out, due to caching headers being absent from D6 (unlike Drupal 7). I found a different way to test the cache behavior, so this test has been fixed: 1ad73a9 on 6.x-2.x