Getting querystring params to load when apache's ErrorDocument 404 is triggered

[adrianbj]

Short description of the issue

There may not be too many scenarios where this is important, but if you visit a URL which is blocked by this rule (https://github.com/processwire/processwire/blob/51629cdd5f381d3881133baf83e1bd2d9306f867/htaccess.txt#L367), apache redirects directly to index.php without any querystring parameters due to this rule (https://github.com/processwire/processwire/blob/51629cdd5f381d3881133baf83e1bd2d9306f867/htaccess.txt#L73)

The problem with Tracy is that it loads its js file via querystring params, eg:
http://pwtest.test/bla'h/?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1

Note the apostrophe inside bla'h - this means that when apache redirects to index.php the querystring params are removed and Tracy doesn't load.

Optional: Suggestion for a possible fix

I wonder if it might be possible to make use of $_SERVER['REDIRECT_QUERY_STRING'] to add those back in so that Tracy can load?

Steps to reproduce the issue

1. Make sure Tracy is running
2. Load a page on the site with a character which isn't allowed by the htaccess regex restrictions, eg an apostrophe
3. Note that the Tracy bar doesn't load and you get these errors:

http://pwtest.test/blah (no apostrophe)

http://pwtest.test/bla'h (with apostrophe)

[adrianbj]

I don't have anymore time today to investigate much further, but:

ErrorDocument 404 /index.php?%{QUERY_STRING}

seems like it is close. It lets you load the Tracy script file directly via:
http://pwtest.test/bla'h?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1

But it still 404's when try to load the actual page: http://pwtest.test/bla'h

Maybe it's a good starting point at least?

[ryancramerdesign]

I think it's okay as long as isolated to the .htaccess file, which ensures it never hits php. What would not be okay is if PW accepted an unknown query string input and then stuffs it back into output (which a redirect 'location' http header would be). That's only okay if it knows what input to expect and type, so that it can sanitize/validate before including in any output.

[adrianbj]

I think it's okay
Sorry, you lost me - what is OK exactly :)

I am trying to figure out a way to get Tracy to load if a page is 404'd because of apache rules, rather than PHP ones. This is due to the way the Tracy core package loads its js file. I was hoping you might be able to include the query string in the 404 call to index.php so it might work.

It's not a huge deal, but every now and then it does prevent Tracy from loading.

[ryancramerdesign]

Basically, in order to pass along a query string into an http header (or really any output), you need to be able to validate it. For instance, in PW page editor, I know I can expect an "id" in the query string to be an integer representing a page ID. So that's something I can validate and pass along in a redirect. But a query string can contain literally anything. From what I understand though, if it's Apache passing along the query string (like it would do in a [QSA] directive on a RewriteRule) then it's lower level and okay at that point. A good example of that is item #14 in PW's htaccess (commented) which handles 404s when request contains path containing characters not supported by PW page names:

RewriteCond %{REQUEST_URI} "[^-_.a-zA-Z0-9/~]"
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?it=/http404/ [L,QSA]

[adrianbj]

Ok, so where does this leave us?

Would it be possible to adjust Rule 16A to be:

  # PW-PAGENAME
  # -----------------------------------------------------------------------------------------------
  # 16A. Ensure that the URL follows the name-format specification required by PW
  # See also directive 16b below, you should choose and use either 16a or 16b.
  # -----------------------------------------------------------------------------------------------

  RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$"
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?it=/http404/ [L,QSA]

This actually fixes the issue that was preventing Tracy from loading.

Obviously 16B would need adjusting as well.

[ryancramerdesign]

@adrianbj That's what section 14 is for, but it is commented because it makes the assumption that PW is the only software running that can handle URLs there. The defaults in PW are "good neighbor" behavior so that if it receives an invalid URL (to PW's style) then it goes back to Apache (which may likely end up a 404, but not PW's call at that point). But if PW doesn't need to be a good neighbor, then it's also common to uncomment things like that, or even better, add add a rule to direct 404s to your own static HTML file, so that the invalid request doesn't consume any PHP or DB resources.

[adrianbj]

Thanks for the explanation.

But, because Rule 14 actually loads the 404 page URL in the browser, it actually gives a different result to my suggested change to 16A which still results in the URL of the originally loaded page being maintained, just this time with the query string parameters sent along with the request.

I honestly don't think this is important enough to waste anymore of our time discussing though - I was just trying to solve an edge case scenario which prevented Tracy from loading because @Toutouwai noticed it and asked me why it was happening. I investigated and found this to be the reason.