Respect X-Forwarded-Proto

[GoogleCodeExporter]

We are running Apache server with mod_pagespeed in Amazon infrastructure behind 
Elastic Load Balancer. Load balancer handles also https requests so that they 
arrive to our Apache server as plain http. Apache thus sees all pages as plain 
http, and mod_pagespeed can also fetch all pages as http (or directly from 
server, this is not an issue). 

However, we have found no way of getting mod_pagespeed work with all urls in 
our setup. If trim_urls is on, pages served through https work correctly, but 
our service breaks in other parts (in some ajax content where html is pasted 
into page content). If trim_urls is off, all urls will have full path including 
domain and protocol part included (which in this case is http, despite load 
balancer receiving requests in https) inserted into them, so that the pages 
browsers receive through https include links to stylesheets and scripts with 
http as protocol - and browsers won't fetch these because of their security 
settings.

There seems to be no setting through which I could disable rewriting url 
domains and paths. What would solve the issue would be a setting which would 
simply enable us to tell mod_pagespeed to leave domain and path of each url as 
it is - in our case this would mean that they would always be relative to 
document root, but not specifying any protocol.

Or does anyone know any workaround to this issue?

Original issue reported on code.google.com by lari.loh...@gmail.com on 24 Oct 2012 at 10:26

• Blocked on: #503

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here's an idea that might work for you.

Can you make an Apache configuration setting that turns off mod_pagespeed if 
"XMLHttpRequest" is in the request-headers?

I feel like this is possible using Apache <If*> directives or possibly 
mod_rewrite, but I haven't figured out what to search for yet.


One thing that would definitely work, if you always have your Ajax HTML in a 
particular subdirectory, is to put in:

<Directory subdirectory_with_ajax_loaded_html/>
  ModPagespeed off
</Directory>

I realize this is just a workaround and only works if you have partitioned the 
directories to segregate your ajax-loaded HTML.  But it might help you get by 
this problem until we can fix bug 503.

Can you let us know if this helps?

Original comment by jmara...@google.com on 24 Oct 2012 at 12:05

• Changed state: RequestClarification

[GoogleCodeExporter]

Try this in your .conf file:
   SetEnvIf X-Requested-With XMLHttpRequest ajax_request
   RequestHeader set ModPagespeed off env=ajax_request

I just got this to work for me, testing with
    wget -q --save-headers --header=X-Requested-With:XMLHttpRequest URL | grep X-Mod-Pagespeed
    wget -q --save-headers URL | grep X-Mod-Pagespeed

This is a bit extreme as you get no optimization in the ajax-loaded file.  But 
you can tune this more using 
https://developers.google.com/speed/docs/mod_pagespeed/experiment, possibly 
adding some non-URL-changing optimizations .

But this is just a workaround until we can change our URL-writing to leave 
paths relative.

Original comment by jmara...@google.com on 24 Oct 2012 at 12:41

[GoogleCodeExporter]

I think the proper thing to do would be to use something like
ServerName https://www.example.com
UseCanonicalName on

Also, wouldn't MapRewriteDomain be an option here?

Original comment by morlov...@google.com on 24 Oct 2012 at 12:42

[GoogleCodeExporter]

I believe in this scenario, MapRewriteDomain won't help.

In the HTML, there are relative references to resources.   IIUC, As far as 
mod_pagespeed can tell, it's all HTTP.  Amazon Elastic Cloud terminates the SSL 
connection and communicates with apache/mps via HTTP (let's ignore the security 
implication of that for the moment).

When the browser sees the page as HTTPS, we want the browser to see the 
resources as HTTPS, otherwise there is a mixed content warning.  And I guess 
the user doesn't want resources under HTTPS if the page is HTTP because of 
performance.

So he wants the resources specified with relative references so the scheme is 
inherited from HTML.  And he gets that with trim_urls except when loading under 
Ajax, when mod_pagespeed cannot know the proper base URL for the page.

Hence my suggested workaround to simply turn off mps when serving Ajax pages.

Original comment by jmara...@google.com on 24 Oct 2012 at 12:55

[GoogleCodeExporter]

We're running mod_pagespeed behind an elastic load balancer with SSL 
termination in ELB, but we've managed to avoid this problem because of a quirk 
in our architecture. We are using various CDN providers for our static assets 
including CSS. We make the decision about which fully-qualified-domain to use 
for the CDN at runtime based on the user's account, geopip, etc. We include the 
http/https in the CSS domain+location so we don't have this same problem when 
relative urls are expanded.

One piece of info about ELB that might be helpful here is the various headers 
that are added. 

https://forums.aws.amazon.com/ann.jspa?annID=805

X-Forwarded-Proto contains either http or https, and it is the original 
protocol that the ELB received before forwarding to the http location on the 
web server. We use that header at runtime to determine which CDN location to 
use. This is a standard header for load balancing, maybe pagespeed could have a 
configuration option on using this header to determine how to rewrite asset 
urls?

Another potential way around this is to provide an option for extend-cache to 
not append the hostname and protocol when expanding relative urls in CSS. 

Original comment by jon.mars...@englishcentral.com on 24 Oct 2012 at 5:46

[GoogleCodeExporter]

It seems that this workaround from comment 3 works: 
   SetEnvIf X-Requested-With XMLHttpRequest ajax_request
   RequestHeader set ModPagespeed off env=ajax_request

Thanks a lot! With this workaround we can still continue using mod_pagespeed. 
However, as most of the pageviews on the site are served as ajax requests, 
we're end up actually using mod_pagespeed just on the first pageview - which is 
still better than nothing. 

Original comment by lari.loh...@gmail.com on 29 Oct 2012 at 11:52

[GoogleCodeExporter]

Summary was: Mod_pagespeed breaks https pages behind Amazon Elastic Load 
Balancer

As a more complete solution, it looks like we should respect X-Forwarded-Proto 
and update our base URL based on it.

Original comment by sligocki@google.com on 29 Oct 2012 at 4:49

• Changed title: Respect X-Forwarded-Proto
• Changed state: Accepted

[GoogleCodeExporter]

Original comment by sligocki@google.com on 1 Nov 2012 at 7:25

• Changed state: Started
• Added labels: Milestone-r23

[GoogleCodeExporter]

Original comment by sligocki@google.com on 1 Nov 2012 at 7:26

• Added labels: Milestone-v23
• Removed labels: Milestone-r23

[GoogleCodeExporter]

This issue was closed by revision r2136.

Original comment by sligocki@google.com on 5 Nov 2012 at 7:42

• Changed state: Fixed