Advagg + CDN integration + Far Future enabled [#2085617]

Hi Mike,

This issues is related to the following

https://drupal.org/node/2083691#comment-7844527
https://drupal.org/node/2046299

The problem is that the preg_replace pattern, instead of just replacing the far future part of the address, is removing the host that is being used to map to the external CDN.

Could you also explain a little bit more about why the far future setting was interfering with the file generation?

Many thanks

Comment	File	Size	Author
#1	advagg-2085617-1-fix-cdn-farfuture-hostname.patch	512 bytes	mikeytown2
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mikeytown2 CreditAttribution: mikeytown2 commented 11 September 2013 at 01:01

Status:

Active

» Fixed

File	Size
advagg-2085617-1-fix-cdn-farfuture-hostname.patch	512 bytes

Thanks for the bug report. Following patch has been committed.

advagg_menu uses the results from file_create_url('public://advagg_css') for the aggregate generating callback, thus it was getting set to cdn/farfuture/xxxxxx/xxxxxx:xxxxxx/sites/default/files/advagg_css instead of sites/default/files/advagg_css.

Another part of it is farfuture doesn't work correctly unless the CDN is on a different web server as the Drupal site. Having no CSS just because of that misconfiguration doesn't seem like a good option.

Last part has to do with advagg_mod's shared directory option. This prevents the simple usage of just doing $directory_path = file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath(); which is what the image module does inside of image_menu.

The nice thing is all advagg files send out far-future headers and on the status report page it will alert you if far-future headers for advagg is not working; thus the usage of CDN's far-future feature for AdvAgg is truly redundant.

Comment #2

OriginalSauce CreditAttribution: OriginalSauce commented 11 September 2013 at 10:10

Thanks Mike, quick reply and helpful info+patch,

I have one further simple question based on your response regarding far-future headers

From the advagg code and the info above, I believe the headers should be very similar to those set by the CDN module, is this correct? This is purely for my info, so I can know whether to track down the discrepancy.

Image type header, set by CDN module
Accept-Ranges bytes
Access-Control-Allow-Orig... *
Alternate-Protocol 80:quic
Cache-Control max-age=290304000, no-transform, public
Content-Length 23592
Content-Type image/jpeg
Date Wed, 11 Sep 2013 09:44:03 GMT
Expires Tue, 20 Jan 2037 04:20:42 GMT
Last-Modified Wed, 20 Jan 1988 04:20:42 GMT

With advagg enabled, instead I see (including JS types, basically all those handled by advagg)
Status report does not flag headers not working.

Accept-Ranges bytes
Alternate-Protocol 80:quic
Cache-Control max-age=1209600
Content-Encoding gzip
Content-Length 1359
Content-Type text/css
Date Wed, 11 Sep 2013 09:44:01 GMT
Etag "53c-4e5d9cdb99c40"
Expires Wed, 25 Sep 2013 09:43:30 GMT
Last-Modified Sun, 08 Sep 2013 06:58:49 GMT

Cheers

Comment #3

OriginalSauce CreditAttribution: OriginalSauce commented 11 September 2013 at 11:07

Update:

Forget the above comment, I've traced the cause of the difference in headers. I've left the comment above as is for informational purposes

Resolution:
The .htaccess file found in advagg_css/advagg_js and the directives therein, were being ignored.

Thanks

Comment #4

OriginalSauce CreditAttribution: OriginalSauce commented 11 September 2013 at 14:44

Another Update to help those who might be testing similar functionality, and bearing in mind there is some integration between Advagg + CDN module

If you have CDN module + far-future enabled via that module, the headers lose their far-future setting created by advagg. With far-future disabled, the headers are as expected, set by advagg.

So at the moment you can either have the image resources which you map to an external CDN via CDN module, with far-future headers, but not in CSS/JS resources, or the other way around, but not both at the same time.

Comment #5

mikeytown2 CreditAttribution: mikeytown2 commented 11 September 2013 at 18:14

You should be able to have both at the same time. Far-future for CSS/JS via AdvAgg & Far-future for everything else via CDN.

The .htaccess rules found inside of the advagg_css/js dirs can be placed in the webroot level .htaccess file without any modifications. Be sure to paste it in at the bottom of the webroot .htaccess file.

Comment #6

OriginalSauce CreditAttribution: OriginalSauce commented 12 September 2013 at 11:26

Thanks Mike, appreciate you spending time to look at the issues.

Sorry I probably wasn't clear enough before.

Due to another existing server config, the htaccess rules set by advagg were getting ignored, I cleared that and the rules are being applied as expected from the original dir path.

What is happening now, is that as soon as the far-future optioned is enabled in the CDN module, the advagg headers are getting lost/removed. Disable that option again and everything is ok, but of course the other (those mapped, e.g images) files do not get far-future headers.

I've opened an issue in the CDN module as this is very probably not caused by advagg, unless advagg does some further processing I haven't traced yet when far-future option is ticked.