Assuming "Switch back to http pages when there are no matches" is enabled, when viewing a https page, then going to the home page (or) logging out (which by default, redirects to the home page), weird things happen. For example, if logged in, it will render the home page as not being logged in. (I know an issue has been brought up on this before). In chrome, the URI is https, but all css and js URLs are called from http and subsequently chrome "blocks" the non-secure files, rendering the home page without a theme...

The workaround I have found, which rather surprisingly works quite well, is to set the $base_url to "https".

So, before, I had my base_url set to:

$base_url = 'http://www.mywebsite.com';  // NO trailing slash!

and simply changed it to:

$base_url = 'https://www.mywebsite.com';  // NO trailing slash!

By changing the $base_url to https, when viewing the home page, it will force everything as https along with one or two non-ssl subsequent page requests, until "whatever cache" (??) has time to update itself and properly redirect back to http.

Hope this helps others in a similar situation.

CommentFileSizeAuthor
#8 2023901.patch589 bytesgordon
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

philsward’s picture

Oh, I need to note that the workaround still doesn't really help the "home page logged out" issue, but it at least keeps Chrome from "breaking"

philsward’s picture

Yeah, there's some sort of caching going on which is affecting the home page... If I flush the "page and else" cache through admin_menu, the homepage redirects properly to http and resets the page as being logged in.

Anyway to set it up so the homepage always has a page flush when viewed from https -> http? Pondering aloud if the flush should happen before the check for https -> http or after...

BTW, if this needs to be assigned as a bug report, feel free to switch it.

gordon’s picture

this is most likely that you have a blank line in the ignore pages config.

philsward’s picture

Just checked and I'm not seeing a blank line... Would it matter if I have URL's for things that aren't actually part of my Drupal install?

For example, I have */advagg* as an ignore, but I'm not currently using advagg (it's still not quite ready for prime time in my situation). I have it there as a "future" thing...

Any other thoughts? And yes, the settings.php https=on switch has been set.

philsward’s picture

Hate to say it, but after some playing around, my "fix" isn't much of a fix... It unfortunately creates all sorts of other issues with the site once the caches begin to fill.

gordon’s picture

I have added to the latest dev version a new debug mode which can be enabled. I am hoping that it will give you enough information when it is enabled to allow you to work out your issue.

Let me know how you go.

philsward’s picture

Hum... looking like it's an issue with Boost :-/

I "think" boost caches the page as the http version and since the static html page doesn't know to redirect over to http from https, it serves the https page but all of the static links point to the http version, freaking out Chrome. Probably a lot more going on than that, but after some testing, this is the theory I've come up with.

I'm guessing the following issue for Boost is the same thing:

https://drupal.org/node/1995742

Not sure which module is the offending one in this situation... If I recall, this was the same reason I disabled Boost when the site was on D6. Hate to get rid of boost though...

Thoughts?

gordon’s picture

Status: Active » Needs review
FileSize
589 bytes

Here is a small patch which turns off boast caching for the current page.

Basically when we redirect to the secure/insecure version of the page, I am telling boast not to cache.

How ever the problem is most likely that boast can't tell the difference between https and http pages so it serves out the https cached version when it is on a no cached version.

I don't think this patch will work. If you can get the boast developers to let me know what I can do from securepages.

philsward’s picture

Unfortunately, it doesn't seem to help :-/

I know boost has a check for https URLs:

Bypass the boost cache for ssl requests.
Ticking this is recommended if you use the securepages module.

But it doesn't seem to help out any.

philsward’s picture

Eh, I had a feeling I would post too early...

Let me get back to you on this. I had that securepages boost option disabled and now that it's enabled, it's working. I want to wait until caches get cleared and whatnot before I say one way or the other. I'll give it a day or so and let you know.

On a side note, I disabled the option a few days ago when the problem first cropped up. I ended up leaving it disabled since there was an apparent problem somewhere and just hadn't gotten around to re-enabling it.

And... On yet another side note, I am purposely not boost caching any of the ssl pages. (Explicitly excluding them in boost)

philsward’s picture

Welp, so-far after running on the site over the last 24 hours, it seems to be working quite well! To be honest, this is the absolute best I have seen secure pages and boost working together :-) I had all sorts of problems with the two back on D6 and ended up ditching Boost because of it.

There's still two issues I am having:

  1. User logs in, goes to home page and they appear logged out
  2. Boost caching a https page results in that page being cached as http and continually served as http

I know the first problem already has an issue created, but I don't know about the second...

Rajan Kumar’s picture

1. After enabled Bypass the boost cache for ssl requests. on the .htaccess tab of Boost setting.
you will need to re-add the .htaccess generation information into your .htaccess file like
Add/Update these lines in your .htaccess file of your drupal core

### BOOST START ###

# Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
RewriteRule .* - [E=boostpath:normal]

# Caching for anonymous users
# Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
RewriteCond %{HTTPS} on [OR]
RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [S=3]

# GZIP
RewriteCond %{HTTP:Accept-encoding} !gzip
RewriteRule .* - [S=1]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html,E=no-gzip:1]

# NORMAL
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

### BOOST END ###

2. Now, In your Boost Settings tab, you have the Cache specific pages section where you can explicitly tell Boost not to cache pages that will be HTTPS. For example, you might have your /contact page secure, so tell boost not to cache your /contact page.