We have a site that runs PHP-FPM and NGINX. The application sends invitations to site members that are keyed with 40 character random strings (alphanumerics only -- example below). Today for the first time we ran into an issue with this approach. The following url:
http://oursite.com/notices/response/approve/1960/OzH0pedV3rJhefFlMezDuoOQSomlUVdhJUliAhjS
is returning a 404 error. This url format has been working for 6 months now without an issue, and other urls following this exact format continue to resolve properly. We have a very basic config with a simple redirect to a front controller, and everything else has been running fine for a while now.
Also, if we change the last character from an "S" to anything other than a lower-case "s", no 404 error and the site handles the request properly, so I'm wondering if there's some security module that might see something wrong with this specific string... Not sure if that makes any sense.
We are not sure where to look to find out what specifically is causing the issue, so any direction would be greatly appreciated.
Thanks!
Update: Adding a slash to the end of the url allowed it to be handled properly... Would still like to get to the bottom of the issue though.
Solved: The problem was caused by part of my configuration... Realized I should have posted, but was headed out of town and didn't have a chance.
Any url that ended in say "css" or "js" and not necessarily preceded by a dot (so, for example, http://site.com/response/somerandomestringcss ) was interpreted as a request for a file and the request was not routed through the front controller. The problem was my regex for disabling logging and setting expiration headers on jpgs, gifs, icos, etc.
I replaced this:
location ~* ^.+(jpg|jpeg|gif|css|png|js|ico)$ {
with this:
location ~* \.(jpg|jpeg|gif|css|png|js|ico)$ {
And now urls ending in css, js, png, etc, are properly routed through the front controller. Hopefully that helps someone else out.
