When using HTTPS with CDN, the http is replaced to show https in the URL string. The CSS files aggregated by this module are usually built under http so whether http or https are being used, the http version of the CSS files are always used with the http urls for css images. When building the files, both versions must be created and then served differently depending on whether http or https is currently being used.

I submitted issue number 1204400 on the CDN module with a patch that will better support HTTPS on CDN by providing a different list instead of just swapping. The current way it is coded as well as my patch both rely on the page being served using HTTPS at the time. There isn't a way to get on demand https links. This will most likely have to change for this integration to work.

Let me know if there is any way I can help.

CommentFileSizeAuthor
#5 cdn-build_css_cache_https-1212184-5.patch1.11 KBdivThis
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chriscalip’s picture

chriscalip CreditAttribution: chriscalip commented

I'll accept a patch; or i'll put this on my to-do list.. been a bit busy with d7 stuff.

andreiashu’s picture

andreiashu CreditAttribution: andreiashu commented

I think this is due to the fact that Adv Aggregator doesn't call the hook_advagg_css_alter hook on HTTPS pages after it generated the bundle already on a HTTP only page. See this ticket: #1461492: Bundler/Adv Aggregator serves the same bundles for HTTPS pages as for HTTP ones

andreiashu’s picture

andreiashu CreditAttribution: andreiashu commented

Can anyone test the patch that I posted in Advagg issue queue to see if it fixes this problem (it did for me): http://drupal.org/node/1461492#comment-5676070

chriscalip’s picture

chriscalip CreditAttribution: chriscalip commented
Project: Parallel CSS - AdvAgg Plugin » CDN
Version: 6.x-1.x-dev » 7.x-2.x-dev
Component: Code » Module
Status: Active » Closed (won't fix)

Parallel CSS deprecated -- CDN now has this modules functionality.

divThis’s picture

divThis CreditAttribution: divThis commented
Status: Closed (won't fix) » Needs review
FileSize
cdn-build_css_cache_https-1212184-5.patch1.11 KB

This issue appears to still be unresolved. A patch is attached which should remedy the issue.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Priority: Major » Normal

I was going to say:

Alternatively, we could rely on protocol-relative URLs.

But that won't work if there's a different HTTPS CDN. So #5 looks good to me.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Category: bug » feature

The comments should be proper sentences though. Other than that, the only thing still needed, is review by at least one more person.

Also marking this as a *feature* request, because this is in fact a feature that's also not supported by Drupal core.

chriscalip’s picture

chriscalip CreditAttribution: chriscalip commented

Wim,

My apologies; I thought this was in parallel_css queue. I see this mistake has been corrected. Good Good..

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

@chriscalip: it was, but an analogous bug apparently exists in the CDN module, so it's fine :) Most definitely no harm done ;) :)

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Title: HTTPS not supported with CDN integration » Create different CSS aggregation files for HTTP and HTTPS
Status: Needs review » Fixed

#5 (@divThis') patch was for D7. I backported it to D6.

Note that this patch effectively makes it impossible to serve *one* set of CSS files when using protocol-relative (//cdn.com) URLs which can in theory be used to serve the exact same CSS files to both HTTP and HTTPS users. However, since this is such a rare edge case, that's fine.

- D7: http://drupalcode.org/project/cdn.git/commit/117239e
- D6: http://drupalcode.org/project/cdn.git/commit/8451c85

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

JeremyFrench’s picture

JeremyFrench CreditAttribution: JeremyFrench commented
Status: Closed (fixed) » Active

I think I may have to reopen this.

I am using CDN for HTTP only, however the CDN generated files are being used for HTTPS pages. So although the CSS is not an http link images in the CSS are links to http assets on the CDN. They should go to local files in this case.

The css link is https://mysite.com/sites/mysite/files/css/cdn_css_5qtf0Pb77_v0NEdGtFWz_fDEifI5jSB4SwzTke6xS-0.css

This is the same that is generated for the HTTP request so images in it are

http://mycdn.com/prefix/myimage.png

This is causing newer versions of chrome to give warnings about insecure pages. Is that a regression of this bug or something new?

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Status: Active » Closed (fixed)

Please create a new issue and refer to this one. This issue was almost a year old! Reopening it will only cause confusion.