web server not including query string when performing a .htaccess URI rewrite

Question

I have published some webpage code on GitHub and it is used by quite a few people without issue. But, just recently, a person contacted me to let me know that they are having an issue with an image not displaying properly. The image is generated by a php file and I am using an .htaccess rewrite to refer to the file as .png in URLs but process internally on the web server as .php.

It is my understanding that an apache server should include the original query string in the URI rewrite by default, but this person's web server is not doing such. This is the first person who has reported the issue and I have not been able to duplicate the issue on the web servers I have tested. I am not sure of this person's web server environment.

This is the incorrect image output which the user is reporting:
https://freiezocker-clan.de/bf4stats/common/server-banner/image-banner.png?sid=1

The result returned in the image above says that a server id is required. The sid is in the query string but is being ignored. On other web servers, it has worked fine.

This is what the image output should look like (when avoiding the .htaccess rewrite):
https://freiezocker-clan.de/bf4stats/common/server-banner/image-banner.php?sid=1

This was my .htaccess implementation before the user reported the issue:
RewriteEngine on
RewriteRule ^(.*)\.png $1.php [NC]

This was my attempt to fix (without success) the reported issue:
RewriteEngine on
RewriteRule ^(.*)\.png $1.php?%{QUERY_STRING} [QSA,NC,L]

Could you please explain to me why that user's web server is not including the query string and/or could you please help me implement a change which will correct the issue for that user?

Thank you!

Answer 1

The server host has determined that their web server is chopping off the query string because the extension is PNG and it is abnormal for a PNG image to have a query string. I agree that it is abnormal for a PNG image to have a query string, but it was necessary for the extension to be PNG and it was necessary for the URL to include additional information (and thus I chose to use a query string). The odd thing is that it has worked fine for so many people on so many different web servers until now.

That being said, I will have to rethink my webpage code to include the additional information into the file name in the URL and extract it from there.

https://forum.myrcon.com/showthread.php?6854&p=139120&viewfull=1#post139120

Answer 2

The user's web host stated:

https://forum.myrcon.com/showthread.php?6854-BF4-Stats-webpage-for-XpKiller-s-Stats-Logger-Plugin-1-0-0-2-(Updated-2-18-2017)&p=139086&viewfull=1#post139086

My reply:

I really wish they could explain what is "outdated" about the following .htaccess code. Like, specifically, what? Because I don't see any "old" rewrite commands below. All of the below "old" commands are listed as perfectly valid in the "new" 2.4 documentation.

RewriteEngine on
RewriteRule ^(.*)\.png $1.php [NC,L]

Your web server is rewriting the URI as expected; so it is working. The part that isn't working is that your web server is chopping the query string off the end. Can they explain?

http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule

By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.

So, please ask them why their server is not behaving as it says it is supposed to "by default".

Is it because I am not including this stuff?

DocumentRoot "/var/www/example.com"
<Directory "/common/server-banner">
</Directory>

I sure hope not. My hope is that per-directory .htaccess files do not require that information and can understand their location and scope without problem. I cannot include that missing information because it is impossible for me to guess users' web server directory structures to determine the DocumentRoot and it is impossible for me to guess which sub-directory a user may place my webpage code.

The "old" and "new" Apache documentation has the same requirements in this regard and it works perfectly fine on the "old" servers; so it should work perfectly fine on the "new" servers as well. In fact, it IS working perfectly fine on your web server (it is rewriting the file name as expected); it is just that your web server is chopping off the query string for some reason.

In fact, the server version I tested on was Apache version 2.4.23; so it was "new" Apache. Please have them explain.