We're using Acquia web hosting with Varnish caching. They weren't immediately able to diagnose this problem and I wanted to share it here, as well.

Our site is a paid membership course. I have set up Secure Pages to activate HTTPS on only the Ubercart cart and checkout pages. On the public-facing [sales and promotion] pages, we take advantage of Varnish caching.

I don't use the typical Ubercart "product" nodes - I have a sales page with a
whose action is set to a custom menu_callback. When that menu_callback is loaded [with the appropriate arguments], it clears the user's cart, adds the appropriate "Enrollment" product, then drupal_goto()'s the Checkout page.

Because Varnish will not cache HTTPS pages, the sales page is insecure, but the checkout page is HTTPS. The checkout page loads properly via HTTPS - except it's in mixed mode. All the assets that were loaded previously, insecurely, such as CSS and JS files, and Images, are STILL loaded insecurely, but the PAGE ITSELF is loaded via HTTPS. (In IE, a nasty popup is displayed asking if the user wants to show insecure elements, and if they click no, the CSS and stuff just doesn't load, which is a TERRIBLE experience on your checkout page.)

I don't understand why the assets wouldn't load via HTTPS if the rest of the page was, except that maybe Varnish is keeping them cached. The last tricky part is that, if the User first visits the site at a non-forced HTTPS URL (such as the sales page), when they click Enroll and are redirected to the HTTPS-enforced cart, mixed mode does not occur, everything loads properly as HTTPS.

Any help? :)

Comments

Offlein’s picture

Offlein commented

After working with Acquia extensively, I've determined a workaround at least.

drupal_goto() was the culprit in my issue. If I use drupal_goto() with a local path, I can watch in Firebug's Net panel as the HTTP:// version of the path is called with an HTTP code 302. Then you can see Secure Pages give another HTTP code 302 and redirect to the HTTPS:// version. Since (I guess) the first call was to an HTTP:// URI, the assets are all loaded via HTTP://.

If I use an absolute path, however (with the HTTPS:// protocol built right in), the assets are all loaded via HTTPS from the get-go and this works properly.

The downside is that I have to hardcode a domain into my drupal_goto() which strikes me as Very Bad™. I think I'm going to try to write a drupal_goto_s() wrapper function that takes relative paths and appends the proper current domain, with the HTTPS protocol built-in, and then sends THAT to drupal_goto(). My contact at Acquia has recommended that if I do this, I post to the core team, too, to see what they thing. Will link to that post when I write it.

astonvictor’s picture

astonvictor commented
Status: Active » Closed (outdated)

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks