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

Preserve URL relativeness #503

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

Comments

Projects
None yet
1 participant
@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Apr 6, 2015

The issue I'm reporting if with regard to this discussion 
'https://groups.google.com/forum/?fromgroups=#!topic/mod-pagespeed-discuss/lnRN5
ySzSIk'

What steps will reproduce the problem?
1. Reverse Proxy HTTPS Site
2. Relative path content in the HTML
3. Render the page in HTPS

What is the expected output? What do you see instead?
The expected output is that with Trim URLs disabled, that ModPagespeed would 
not make the assumption to absolutify the URLs to HTTP without fully knowing 
the context.

Ideally, it would be good to leave the relative paths in the content as is.

What version of the product are you using (please check X-Mod-Pagespeed
header)?
We're on revision: 1734

On what operating system?
Ubuntu 10.04

Which version of Apache?
2.2

Which MPM?
Event

URL of broken page:


Original issue reported on code.google.com by hayes...@gmail.com on 21 Sep 2012 at 10:17

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

This seems to be related to what other people have experience with Trim URLs.
We had it enabled but that impact Ajax requests because they were relative 
pathed.

We disabled Trim URLs but then that caused absolutified resources to HTTP 
rendered under HTTPS which causes the browser to get sad.


Original comment by hayes...@gmail.com on 21 Sep 2012 at 11:34

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Is it the case for such configurations that they will always be served from 
HTTPS?   If so, this could perhaps be resolved with
    ModPagespeedMapRewriteDomain https://yoursite http://yoursite

Or is this used for configurations where the same pages might be served from 
HTTPS or HTTP depending on the user?

Original comment by jmara...@google.com on 24 Sep 2012 at 6:45

  • Changed state: RequestClarification
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

The rewrite domains is an option but unfortunately if you can't rewrite every 
URL, the issue remains.

Generally, this is specific to resources served from HTTPS or HTTP per your 
second comment.
It would be nice to have an option to disable Trim URLs and avoid having the 
paths absolutified.

Original comment by hayes...@gmail.com on 26 Sep 2012 at 5:39

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

We are also having the same problem. We're running Apache with mod_pagespeed in 
Amazon EC2 instance, which is behind Amazon Elastic Load Balancer, which takes 
care also of https connections - so that all connections to the Apache server 
come as http. Because mod_pagespeed rewrites urls so that they contain absolute 
urls containing also protocol and domain parts, pages served with https get 
broken as all links to css and js get rewritten pointing to the server with 
http as protocol. This can be fixed with trim_urls, but this breaks some ajax 
pages.

Solution would be very simple: to have an option to leave url paths as they are 
- that is, without adding the protocol and domain-part (as without trim_url) 
and without making urls relative (as trim_url does). 

Original comment by lari.loh...@gmail.com on 13 Oct 2012 at 1:59

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 24 Oct 2012 at 11:47

  • Now blocking: #546
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Subject was: ModPagespeed Base URL assumptions with regard to relative paths

Currently, when trim_urls is off, urls are absolutified based on the perceived 
base tag.  This perceived base tag is often incorrect when HTML is loaded via 
ajax.  mod_pagespeed should leave the paths unmodified when not trimming them, 
rather than absolutifying them.

Original comment by jmara...@google.com on 24 Oct 2012 at 11:54

  • Changed state: Accepted
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

See this workaround I posted to bug 546:

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:56

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 18 Apr 2013 at 7:29

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 18 Apr 2013 at 9:42

  • Added labels: Priority-High
  • Removed labels: Priority-Medium
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Original comment by sligocki@google.com on 21 Aug 2013 at 4:59

@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

Goal is to preserve URL relativeness: Keep relative URLs relative and absolute 
ones absolute, etc.

Original comment by sligocki@google.com on 27 Aug 2013 at 7:49

  • Changed title: Preserve URL relativeness
  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

Copy link

GoogleCodeExporter commented Apr 6, 2015

This feature was implemented in r3509 in which we add a new option: 
PreserveUrlReletivity.

This will be available in the next mod_pagespeed release.

Original comment by sligocki@google.com on 30 Sep 2013 at 9:41

  • Changed state: Fixed
  • Added labels: Milestone-v30, release-note
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment