Switching from HTTPS to HTTP Rendered Media Tags Remain Stuck on HTTPS [#2037051]

Hi All,

We're using an SSL/HTTPS connection for administrator/editor logins only.

If while editing a story, or loading a page or view for the first time while logged in, and under HTTPS - everything works fine. All related media placed in the body of posts using embedded media tags renders fine and are served via SSL/HTTPS

However, after the user has logged out, the media images that were being served via SSL/HTTPS, continue to load as HTTPS even when the pages are requested via HTTP.

When all of the Drupal caches are cleared - either via drush cc all, or via Administration » Configuration » Development » Clear all Caches - everything is fine and all of of the embedded media is now served via HTTP.

We're using a self-signed certificated (for admin access only), which means the problem becomes apparent for anonymous users when images being incorrectly served via HTTPS are blocked by some browsers.

We have core Page and Block caching disabled and have turned off Boost caching. We've also ensured that View caching is disabled.

Although this makes no difference to the problem, we also have the following in our settings.php file:

if (isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) == 'on') {
  $base_url = 'https://oursite.domain.com';
}
else {
  $base_url = 'http://oursite.domain.com';
}

Thoughts?

Any suggestions as to where to look for the problem? How are the rendered media embed tags (as HTML) being stored?

Comments

Comment #1

plinto commented 8 July 2013 at 11:35

I am having the same issue

Comment #2

anthony.bouch commented 8 July 2013 at 11:53

Okay - I think I've found the issue - here at...

RFC: Disable caching for media filter (7.x-2.x-dev)
https://drupal.org/node/2017761

and

RFC: Disable caching for media filter (7.x-2.0-unstable7)
https://drupal.org/node/1984424

Obviously I'd vote in favour of not caching media filtered text - since this will likely be an issue for others switching from HTTP to HTTPS (and anyone that clears the entire Drupal cache while logged in under HTTPS which will cause all subsequent page views under HTTPS to create cached filtered media tags as HTTPS).

Or maybe there's a better way? Do the rendered paths need to be absolute? What about a Media filter option to render relative URLs?

As a temporary work-around, we've implemented a custom logout module (called custom_logout) - which we needed anyway to force the user back to HTTP after they have logged out (since a custom action and trigger to redirect to HTTP does not work - it doesn't destroy the session).

By calling media_filter_invalidate_caches(); we can be sure that all of the rendered media tags will be returned to plain HTTP on subsequent page views.

/**
 * Experimental user logout and redirect to home page
 * and back to HTTP.
 *
 * Implements hook_user_logout($account)
 *  
 */
function custom_logout_user_logout($account){
    global $base_url;
    $url = "http://" . file_uri_target($base_url);
    session_destroy();
    media_filter_invalidate_caches();
    drupal_goto($path=$url);
}

Thoughts?

The only down side to this approach, is that if a user was busy reloading pages, clearing caches, editing, previewing - whatever - while logged in, and forgot to log out before leaving the site - there will likely be HTTPS filtered media tags stuck in the cache.

Comment #3

jcisio commented 8 July 2013 at 11:56

I was pointed to this issue. There was similar issue in Scald #2012906: Protocol is not considered in the caching logic but it was fixed easily because Scald uses its own caching system. With Media, the easiest way (but it kills a kitten) is to patch core. Make filter not cacheable is an important performance problem, especially when there is a resource intensive filter (like the core HTML Filter which uses DOM manipulation, or HTML Purifier etc.).

Comment #4

jcisio commented 8 July 2013 at 12:00

#2 you might want to use hook_exit to clear cache if https, and don't have this problem. But of course it is only for your site, where https usage is very rare.

Comment #5

anthony.bouch commented 8 July 2013 at 12:56

thanks @jcisio - wow - the Scald module looks interesting.

Thinking about the media filter problem some more - we rarely host a Drupal site without a cache (Boost or Varnish) in front of it - so perhaps an option on the media filter to prevent caching would work as well.

Comment #6

ahoeben commented 30 July 2013 at 20:33

Couldn't media make sure that all the urls it creates are scheme-relative?
Ie: actively replace "http(s)://example.com/sites/default/files/test.jpg" with "//example.com/sites/default/files/test.jpg"
This would fix the issue at hand, and could be done without changing core.

Here's a bit of drupal-related (though not this-issue-related) discussion about scheme-relative urls:
https://drupal.org/node/1783278#comment-6474470