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

trim_urls breaks Ajax requests for HTML with a different path from the base document #393

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

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Apr 6, 2015

What steps will reproduce the problem?
1.Enable Mod Page Speed
2.Load landing page
3.Attempt to load 2nd page via jquery mobile ajax request

What is the expected output? What do you see instead?
Expected behavior is that the page is loaded dynamicaly into the DOM.

Instead, the landing page loads fine, but loading any sub pages loads the 
following way on a forum.

http://basepath.com <-- Works OKAY
http://basepath.com/forum-1 <-- Works OKAY
http://basepath.com/forum-1/topic1 <-- Loads incorrectly

Appears the path is not loading correct with the ajax. 

An example looks like the following with the jquery mobile ajax request

http://basepath.com/forum-1/forum-1/topic-1 <-- That is a sample of the path 
that is requested when Mod Pagespeed is active.

What version of the product are you using (please check X-Mod-Pagespeed
header)?

On what operating system? CentOS 6 32 bit via CPanel 11

Which version of Apache? 2.2.21

Which MPM? Latest build from 2/25/12

Please provide any additional information below, especially a URL or an
HTML file that exhibits the problem.

I have it currently turned off on my production site. If you would like to see 
this happen, please email me and I will enable it shortly on the forum.

As far as troubleshooting goes, I disabled all filters and just enabled page 
speed. Still, after clearing cache, the paths are not being loaded correctly.



Original issue reported on code.google.com by jluken...@gmail.com on 26 Feb 2012 at 11:52

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by morlov...@google.com on 1 Mar 2012 at 1:24

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 10 May 2012 at 8:13

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

We don't have a great solution to fix for this.  However we should document the 
limitation and describe workarounds. 

Original comment by jmara...@google.com on 17 May 2012 at 7:46

  • Added labels: Milestone-v22, release-note
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Issue 447 has been merged into this issue.

Original comment by jmara...@google.com on 23 May 2012 at 8:12

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

The only workaround that I have, is to disable all ajax request. So every load, 
is a full page load. 

Original comment by jluken...@gmail.com on 23 May 2012 at 8:21

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Just to be clear on the scope of the issue:

mod_pagespeed, to operate correctly, generally needs to know the path that the 
browser will use to evaluate relative paths in HTML. 

The issue here is that when mod_pagespeed process HTML text that's going to be 
used as an Ajax response, it has the wrong idea of the URL the browser will use 
as a base for relative URL lookups.

If all the URLs in the Ajax HTML are absolute, then I think there should be no 
functional problems if you turn trim_urls off.  This suggests that perhaps we 
should remove trim_urls from the core-filters list.  But if there are relative 
paths to resources in the Ajax HTML response, then mod_pagespeed can still 
misinterpret them and turn them into the wrong absolute URLs, with potentially 
incorrect content.  So turning off trim_urls is not sufficient to guarantee 
correctness.

It would be nice if we could tell in mod_pagespeed that the HTML request was 
going to be used as an Ajax response for a different path.  That would help us 
continue to provide optimal behavior.


But it would be useful to know, from people that actually write web page for a 
living: when you create HTML Ajax responses, do you generally provide absolute 
resource URLs?  Or do you sometimes write relative URLs based on the page that 
is making the Ajax request?

Original comment by jmara...@google.com on 23 May 2012 at 8:32

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

We generally provide absolute resource URLs

Original comment by tar...@gmail.com on 23 May 2012 at 8:40

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

OK we are convinced that the right thing to do is remove trim_urls from the 
core-set.

Original comment by jmara...@google.com on 23 May 2012 at 10:08

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 23 May 2012 at 10:09

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Original comment by jmara...@google.com on 24 May 2012 at 7:55

  • Changed state: Accepted
  • Added labels: Priority-High
  • Removed labels: Priority-Medium
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Summary was: Mod Pagespeed breaks JqueryMobile ajax request

Original comment by jmara...@google.com on 25 May 2012 at 2:55

  • Changed title: trim_urls breaks Ajax requests for HTML with a different path from the base document
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

trim_urls is now removed from the core set (trunk)

Original comment by jmara...@google.com on 25 May 2012 at 3:00

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Apr 6, 2015

Issue 379 has been merged into this issue.

Original comment by jmara...@google.com on 30 May 2012 at 2:21

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