New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep relative URLs relative after rewrite. #97

Closed
GoogleCodeExporter opened this Issue Apr 6, 2015 · 9 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Apr 6, 2015

What steps will reproduce the problem?
http://foo.com/ is the front end which makes sub-requests to http://bar.com/ 
(the backend which should only be accessed from foo.com).

What happens?

mod_instaweb is installed on bar.com and so mod_pagespeed absolutifies URLs to 
http://bar.com/... which is not accessible from the user.

What we want to happen?

All sub-requests should go to foo.com . 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 bar.com to foo.com .

Original issue reported on code.google.com by sligocki@google.com on 17 Nov 2010 at 8:12

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 17 Nov 2010 at 8:17

  • Changed state: Duplicate
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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

Original comment by sligocki@google.com on 17 Nov 2010 at 8:32

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

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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 ja...@comfreeze.net on 6 Dec 2010 at 7:11

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

FYI, take a look at 
http://code.google.com/speed/page-speed/docs/using_mod.html#Mapping%20Rewrite%20
Domains which solves many of these issues.

Original comment by sligocki@google.com on 6 Dec 2010 at 4:26

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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:

https://purple.knives.testing.dev
 /imgs
 /css
 /js
https://sharp.tools.testing.dev
 /images/png
 /images/gif
 /styles/css
 /javascript
https://jazz.bands.testing.dev
 /i
 /c
 /j
https://my.staging.testing.dev
 /images
 /styles
 /scripts

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

ModPagespeedDomain my.staging.testing.dev
ModPagespeedDomain *.*.testing.dev
ModPagespeedDomain *.staging.testing.dev
ModPagespeedDomain *.testing.dev
ModPagespeedMapRewriteDomain my.staging.testing.dev *.staging.testing.dev
ModPagespeedMapRewriteDomain my.staging.testing.dev *.*.testing.dev
ModPagespeedMapRewriteDomain my.staging.testing.dev *.testing.dev

Obviously, the latter wouldn't necessarily work for "your.staging.testing.dev" 
as you could have a different folder structure and none of the same content to 
host, and almost certainly wouldn't work for "jazz.bands.testing.dev".  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 ja...@comfreeze.net on 6 Dec 2010 at 10:16

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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 
environments.

Original comment by ja...@comfreeze.net on 6 Dec 2010 at 10:26

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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

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

Original comment by jmara...@google.com on 6 May 2011 at 2:36

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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

Original comment by kevint...@gmail.com on 25 May 2011 at 9:49

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

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 sligocki@google.com on 25 May 2011 at 9:55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment