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

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

Keep relative URLs relative after rewrite. #97

GoogleCodeExporter opened this issue Apr 6, 2015 · 9 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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

  • Changed state: Duplicate

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant