The module uses the http protocol, but items in Drupal's page cache are stored with the protocol. As a result, the page cache is cleared for http items but for remains for https, resulting in stale content being served over https.

Comments

barrett’s picture

Status: Active » Needs review
StatusFileSize
new2.32 KB
barrett’s picture

There's likely a more efficient means of doing this. It would also be nice to have a configuration option to tell the module if it should clear http, https, or both. For the moment, the patch at least solves the problem.

nielsvm’s picture

Status: Needs review » Needs work

Hi Barret,

Your patch might work for your scenario but it needs further groundwork to get it really done well. I have finished a major refactor of the HTTP requesting internals in which I kept https purging fully in mind. If you are interested short-term let me know, else you can assume https support to end up as experimental feature soon!

Niels

barrett’s picture

Version: » 7.x-1.x-dev

Thanks, Niels. We're definitely interested in this feature in the near-term. I'll see what I can do about re-rolling the patch against the revisions you've made to the module.

Thanks,
Barrett

nielsvm’s picture

Status: Needs work » Needs review
StatusFileSize
new398 bytes

@barrett, you are welcome!

I have worked on refactoring the underlying HTTP logic to - primarily improve performance and decrease the burden put on the queue api - support HTTPS support in the future. Although adding HTTPS support with GUI interface and everything isn't the highest priority right now, it should already work with a one-line hack.

Please upgrade to version *7.x-1.0-alpha2* which gives you many performance improvements already, then there is the patch attached to this comment. This should effectively give you https support during purging.

Please test carefully as purging happens 'atomic', which means that one single request failing will result in your full queues filling up. You can track everything happening in Drupal's standard logging system, errors are flagged as such.

Looking forward to your feedback,

Niels

anavarre’s picture

@Barrett: have you been able to test this?

nielsvm’s picture

Issue summary: View changes
Status: Needs review » Postponed

This will land in Acquia Purge one day but due the riskiness our current focus lies on getting a stable and working module out. The patch works for those in the meanwhile requiring SSL purging and I would love to see feedback on it. Again, all underpinnings to SSL purging are designed in but the last 1% has been removed: until I'm absolutely certain its safe to release.

alexku’s picture

Attaching a modified patch which makes https support optional and configurable in settings.php. Also it allows optionally skipping ssl verification in curl. Otherwise purge requests fail if ssl certificate is not valid.

To enable https purging and ssl verification skipping add this to settings.php:

  $conf['acquia_purge_protocol_schemes'] = array('http', 'https');
  $conf['acquia_purge_skip_ssl_verify'] = TRUE;
jaydub’s picture

We just ran into this issue as well as we just deployed HTTPS across our entire site on Acquia yesterday. We were not getting varnish PURGEs to do their thing and applying the patch and settings.php change resulted in successful PURGE to https bucket on Varnish.

technikh’s picture

The patch worked great for us. Don't forget to add this code to settings.php

$conf['acquia_purge_protocol_schemes'] = array('http', 'https');
$conf['acquia_purge_skip_ssl_verify'] = TRUE;
dstol’s picture

A small whitespace fix.

nielsvm’s picture

Status: Postponed » Closed (fixed)

Gentlemen,

I've got good news for all of you for the upcoming release 7.x-1.0:

(7.x-1.x *)$ git commit FAQ.txt README.txt ROADMAP.txt acquia_purge.diagnostics.inc acquia_purge.module
[7.x-1.x a2c61ca] 2100327: SSL support finally landed, no more hacks required. The feature gets enabled by adding "$conf['acquia_purge_https'] = TRUE;" to settings.php and disabling http:// happens by also adding "$conf['acquia_purge_http'] = FALSE;". In addition to just the support for it, I also added documentation and several safety valves to the diagnostic tests as just enabling it with many domains might absolutely crash sites, so it should help prevent casualties.
 5 files changed, 112 insertions(+), 12 deletions(-)

The implementation is different than the patches posted here above and in my opinion safer as well. Letting people mess directly with the protocol schemes array feels wrong to me and could open a can of worms if someone mistypes something there.

 Will Acquia Purge wipe SSL/https:// paths on my site?
-----------------------------------------------------------------
  Yes it will, once you added "$conf['acquia_purge_https'] = TRUE;" to your settings.php file. It is important to understand that just adding this setting will DOUBLE the total amount of purging going on as http:// will also see its paths purged, so you will need to monitor your site extra careful as the queue can go up without getting purged fast enough. If the queue does go up quickly, consider switching to cron mode (with 1-5 minute cron intervals) or disable http:// purging as well, see README.txt.
 My site redirects all http:// to https://, should Acquia Purge know about that?
-----------------------------------------------------------------
  Yes definitely, as that means that without your interference Acquia Purge will continue to wipe http:// paths and essentially ends up double purging with high queues and resource waste as result. By adding this to settings.php: "$conf['acquia_purge_http'] = FALSE;", you essentially disable all http:// purging.

So, I'm closing this ticket finally as fixed, as its soon available to all of you. Testers on the 7.x-1.x branch are welcome in the meanwhile to reopen the ticket if anything's found, but I don't expect so.

Niels