Skip to content
This repository was archived by the owner on Apr 10, 2025. It is now read-only.

PageSpeed URL control wildcards don't work properly #1294

Closed
crowell opened this issue Apr 26, 2016 · 9 comments
Closed

PageSpeed URL control wildcards don't work properly #1294

crowell opened this issue Apr 26, 2016 · 9 comments

Comments

@crowell
Copy link
Contributor

crowell commented Apr 26, 2016

In one level of .htaccess specify ModPagespeedDisallow * and in a higher level specify ModPagespeedAllow *example.com*, example.com will still be shown as disallowed.

@crowell crowell changed the title PageSpeed URL control interactions are broken PageSpeed URL control interactions don't merge properly Apr 26, 2016
@jmarantz
Copy link
Contributor

jmarantz commented Apr 26, 2016

If I understand your description, this is working as intended.

E.g.
htdocs/foo/.htaccess : ModPagespeedAllow *example.com*
htdocs/foo/bar/.htaccess : ModPagespeedDisallow *

Any time a file in foo/bar/ is referenced, the Disallow * will override the .htaccess in foo/

@crowell
Copy link
Contributor Author

crowell commented Apr 26, 2016

@jmarantz no, the opposite, the disallow in the root, and then the allow in
/foo/.htaccess
On Apr 26, 2016 11:44 AM, "Joshua Marantz" [email protected] wrote:

If I understand your description, this is working as intended.

E.g.
htdocs/foo/.htaccess : ModPagespeedAllow example.com
http://example.com

htdocs/foo/bar/.htaccess : ModPagespeedDisallow *

Any time a file in foo/bar/ is referenced, the Disallow * will override
the .htaccess in foo/


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1294 (comment)

jmarantz added a commit that referenced this issue Apr 27, 2016
#1294

The unit test works properly, so there is no code change in this commit.
The bug remains outstanding.
@jeffkaufman
Copy link
Contributor

@jmarantz I'm having trouble understanding 07c1fcc: is it that you thought this might have been a bug in MergeOptions, and you created a unit test to elicit the bug, but the unit test passed?

@jeffkaufman
Copy link
Contributor

jeffkaufman commented Jun 28, 2016

Reproduced:

mod_pagespeed_test/
  issue1294/
    .htaccess: ModPagespeedDisallow *
    subdir/
      .htaccess: ModPagespeedAllow *foo*
      foo.js: document.write("hello ");
      bar.js: document.write("world");
      index.html: <script src=foo.js></script><script src=bar.js></script>

$ curl localhost:8080/mod_pagespeed_test/issue1294/subdir/
<script src="foo.js"></script>
<script src="bar.js"></script>

@jeffkaufman
Copy link
Contributor

When reversing the two .htaccess files we still don't see foo.js get rewritten, so it's not just handling them backwards or something.

@hillsp
Copy link
Contributor

hillsp commented Jun 30, 2016

I cannot reproduce this using what Josh checked in above; ModPagespeedAllow *purple* still works just fine. If I comment out the entire Allow in the override dir, the test fails.

@jeffkaufman
Copy link
Contributor

The test @hillsp was referring to as "what Josh checked in above" was 4d3acd9 plus 6b0cd0c

@jeffkaufman
Copy link
Contributor

Hypothesis is that .htaccess merging works correctly in the ipro flow but not the html flow.

@hillsp hillsp changed the title PageSpeed URL control interactions don't merge properly PageSpeed URL control wildcards don't work properly Jul 7, 2016
@hillsp
Copy link
Contributor

hillsp commented Jul 7, 2016

Turns out that this is a problem with FastWildcardGroup and isn't related to the merging at all. @jmaessen has a fix.

jmaessen added a commit that referenced this issue Jul 8, 2016
…e* order,

and should match them forwards as a result.  Add a couple of tests beyond
Steve's initial repro.

#1294
@jmaessen jmaessen closed this as completed Jul 8, 2016
crowell pushed a commit that referenced this issue Jul 21, 2016
…e* order,

and should match them forwards as a result.  Add a couple of tests beyond
Steve's initial repro.

#1294
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants