I posted this over on StackOverflow but have not yet received a response. Perhaps someone here knows the answer.

http://stackoverflow.com/...orming-an-htaccess-uri

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....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....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!

ty_ger07

This was my attempt to fix (without success) the reported issue:

RewriteEngine on
RewriteRule ^(.*)\.png $1.php?%{QUERY_STRING} [QSA,NC,L]

(Seems that I needed to look further into this before I had come up with the following which may have corrected it...)
First it is my understanding that if you decide to use the {QUERY_STRING} variable you need to set conditions as to what you are matching in your .htaccess for redirects. The query string is not part of the match in the rewrite rule. I would expect that it is meant for a particular set of conditionals, such as:
 

 
RewriteCond %{QUERY_STRING} ^who=a$ 
 
RewriteRule ^people.php$ /people/?t=leadership [R=301,L]
 

 
Notice it checks for a conditional prior to the rewrite rule being implemented in the above example. I think your original (working) rewrite rule would be better suited as you're passing a variable to it and you aren't looking to redirect based on particular conditions, just a particular SID which would be contained elsewhere that the php script would evaluate after being passed.
 
[edit]
Looks like you may be adding additional flags which may need to be taken into consideration.
 
While your original statement should be perfectly fine in sending the variables to your query process, there might be a better way to do it though it may need some tweaks. The revised rewrite rule would be most likely better suited not using the QSA flag as it's going to append the entire query string to the end of the request. It would be (probably) better suited to using the following line instead.
 

RewriteEngine on
RewriteRule ^(.*)\.png $1.php?%{QUERY_STRING}

 
This way it can pass the query string being sent to the variable without needing to use the QSA which would combine the original string along with the query string as a URL. This is most likely not what you are looking to have done. The NC flag is fine if you don't care about case for the query and will allow for any type to be send into your query. The L flag is ok for termination though, since you don't have conditionals, it doesn't necessarily need to be there as there aren't any conditional statements to avoid.
[/edit]
 

Thanks a lot for the help! I will give it a try! If nothing else, it's an improvement and sanity check.

To bring this strange tale (almost no one cares about) to a close:
 
http://stackoverflow.com/a/43527857/7859358

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

It isn't my host.  It is someone else who came to me for help.  I agree that it is that person's server host who has added a restriction (probably a global URI rewrite of their own) which drops the query string from all URLs which don't end in specific extensions.  Probably something they decided to do in the name of some false sense of security.
 
This is my solution to the above problem:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)(pid)(.*\d)(fav)(.*\d)(.*) $1.php?$2=$3&$4=$5 [QSA,NC,L]
RewriteRule ^(.*)\.png $1.php [NC]

 
The result is this:
 
Example 1 (same as before):
Input (URI) file name: signature.png?pid=7&fav=0
Output (server parsed) file name: signature.php?pid=7&fav=0
 
Example 2 (updated option for this user):
Input (URI) file name: signaturepid7fav0.png
Output (server parsed) file name: signature.php?pid=7&fav=0
 
It keeps the old method working and allows the new method -- for this person with a weird host -- to work.