Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Keep relative URLs relative after rewrite. #97

GoogleCodeExporter opened this issue Apr 6, 2015 · 9 comments

Keep relative URLs relative after rewrite. #97

GoogleCodeExporter opened this issue Apr 6, 2015 · 9 comments


Copy link

What steps will reproduce the problem? is the front end which makes sub-requests to 
(the backend which should only be accessed from

What happens?

mod_instaweb is installed on and so mod_pagespeed absolutifies URLs to which is not accessible from the user.

What we want to happen?

All sub-requests should go to . One simple solution would be to leave 
all resources which were originally relative URLs, still relative. A more 
complicated solution would be to implement domain mappings, telling us to move 
all resources from to .

Original issue reported on by on 17 Nov 2010 at 8:12

Copy link

Original comment by on 17 Nov 2010 at 8:17

  • Changed state: Duplicate

Copy link

Let's keep this bug around for the keep URLs relative. I think that makes a lot 
of sense separately.

Original comment by on 17 Nov 2010 at 8:32

  • Changed title: Keep relative URLs relative after rewrite.
  • Changed state: Accepted

Copy link

It appears this issue's resolution should fix Apache configurations involving 
vhost_alias and the use of VirtualDocumentRoot as well from my understanding of 
its use.

Original comment by on 6 Dec 2010 at 7:11

Copy link

FYI, take a look at
Domains which solves many of these issues.

Original comment by on 6 Dec 2010 at 4:26

Copy link

Thanks, sligocki, but this doesn't appear to addressing the vhost_alias issue 
that I am experiencing, should I start a separate issue perhaps?

The problem I appear to be having, and was hoping relative URL stickiness would 
assist with, is that vhost_alias uses a dynamic file source system, using 
subdomains to map subdirectories to requests and issue unique files, collecting 
roughly 175 domains into a single vhost rule with a format of "*.*.tld".  
Pagespeed does not seem to be able to match the dynamic domain to an original 
file so far, with both explicit ModPagespeedDomain definitions and/or 
ModPagespeedMapRewriteDomain settings.  The problem appears to stem from what 
appears to be the necessity to declare individual rules for each of the 
contained subdomains for the content to be mapped correctly as none of these 
subdomains share content or path structures normally.  In fact, if that page is 
correct, it would completely negate the whole benefit offered by this 
configuration using vhost_alias.

Perhaps you could suggest an option for the following configuration, examples 
that would all be hosted from the same vhost configuration:

These would all be served through a single vhost declaration.  When I only take 
the last one for example, when requesting, so 
far I've tried:

ModPagespeedDomain *.*
ModPagespeedDomain *
ModPagespeedDomain *
ModPagespeedMapRewriteDomain *
ModPagespeedMapRewriteDomain *.*
ModPagespeedMapRewriteDomain *

Obviously, the latter wouldn't necessarily work for "" 
as you could have a different folder structure and none of the same content to 
host, and almost certainly wouldn't work for "".  Any 
various combination of each as well as all at the same time and each one 
individually at a time all report the same results.  Unfortunately all I seem 
to be getting is:

resource_fetches_cached: 0
resource_fetch_construct_successes: 0
resource_fetch_construct_failures: 0
total_page_load_ms: 18417
page_load_count: 32
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 0
css_filter_minified_bytes_saved: 0
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
image_ongoing_rewrites: 0
javascript_blocks_minified: 0
javascript_bytes_saved: 0
javascript_minification_failures: 0
javascript_total_blocks: 0
resource_url_domain_rejections: 5398
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 0
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0
serf_fetch_outstanding_count: 0

Notice the only real couter in use is "resource_url_domain_rejections".  I have 
turned every apache log to "info" and tried modifying the domain reported in 
"Invalid url relative to" messages, but so far nothing appears to match in this 
configuration.  All this has been very confusing, as well, thanks to my use of 
mod_rewrite and mod_pagespeed's continuous referencing to rewriting (but not 
mod_rewrite style) in a separate context.  I appreciate any assistance and 
sorry if I hijacked the wrong thread.

Original comment by on 6 Dec 2010 at 10:16

Copy link

P.S. I could also mention this is not a production system, it is configured in 
such a dynamic way because it's used for testing and staging sites prior to 
packaging for production deployment and therefore would be helpful to have 
pagespeed available to point out possible optimizations, I don't think I would 
consider running such an interesting configuration in real-world, production 

Original comment by on 6 Dec 2010 at 10:26

Copy link

I believe this is addressed now by the trim_urls feature, which is was released 
on March in

If I'm not understanding the particulars of this issue relative to vhost etc, 
please re-open.

Original comment by on 6 May 2011 at 2:36

  • Changed state: Fixed

Copy link

Has this been fixed? I still get relative urls in, for example, 
background:url(bob.jpg) expanded to when over 
https, instead of

Original comment by on 25 May 2011 at 9:49

Copy link

This is effectively fixed for many situations because of trim_urls filter.

Could you tell us a little more about your server setup? Is it similar to one 
of the above configurations?

Original comment by on 25 May 2011 at 9:55

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

1 participant