Yes. The relevant request logs look like:
# First request that is actually satisfied is the deepest, unsharded pagespeed request. This is sent to the actual origin ip chosen by our loadbalancer config in the vhost.
CNAME 443 127.0.0.1 ORIGIN-IP [2017-09-27T22:28:44.620Z] 876812 "GET /path/to/file.css HTTP/1.1" 200 - 1097 77108 M "Serf/1.3.8 (mod_pagespeed/1.12.34.2-0)" "ORIGIN-DOMAIN" 127.0.0.1 - 35.197.110.236 "text/css" TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 -
# Second request is the sharded pagespeed request made to the sharded domain. The server host header specifies the target domain, but this came in on the sharded domain's vhost, hence the "/URL" prefix that reverse the sharding.
CNAME 443 127.0.0.1 - [2017-09-27T22:28:44.620Z] 881638 "GET /URL/path/to/file.css HTTP/1.1" 200 - 632 77686 M "Serf/1.3.8 (mod_pagespeed/1.12.34.2-0)" "ORIGIN-DOMAIN" 127.0.0.1 - 35.197.110.236 "text/css" TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 -
# Third request is the original pagespeed request back to the original client.
CNAME 443 REQUESTER-IP - [2017-09-27T22:28:44.694Z] 1097869 "GET /URL/path/to/A.file.css.pagespeed.cf.SRCIGJU8Dx.css HTTP/1.1" 200 - 1094 77724 P "Amazon CloudFront" "ORIGIN-DOMAIN" REQUESTER-IP - 35.197.110.236 "text/css" TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 US
To be clear, we have two vhosts in our configuration:
One vhost for the target domain and another vhost for the cdn domain. It looks like the CDN requests come in on the cdn domain, get proxied back into apache for the cdn domain but without the pagespeed file extension which gets redirected again back into apache on the target vhost domain which finally goes through to the origin server. I expected the middle hop to be skipped.
- Augusto