3

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.

Harrison
  • 31
  • 1
  • 3
  • 1
    You seriously need to provide your configuration file, error logs and such to get any help. People here aren't psychic. – Martin Fjordvald Dec 17 '10 at 22:32
  • Yeah for sure; I didn't have a chance to as I didn't have access to it and I was running out the door. Should have waited to post... Fortunately I found the problem and solution, explained above. – Harrison Dec 21 '10 at 22:10
  • I had the exact same issue 2 days ago, and url params ending with js/css were throwing 404 (like abcdxjs). I found out that after I played with the value, like changing it to some other characters. – Rvy Pandey Dec 30 '20 at 04:14

2 Answers2

6

From OP:

It was a problem with the config file; I was conditionally setting expiration headers and disabling logging for images, js, css, ico files, etc. I had:

  location ~* ^.+(jpeg|jpg|gif|css|png|js|ico)${

and changed it to:

  location ~* \.(jpeg|jpg|gif|css|png|js|ico)${

Now when I request a url that ends in one of those strings, it parses it as a url, and not as a file, so no more 404 errors.

mgorven
  • 30,036
  • 7
  • 76
  • 121
  • I was trying for hours to find a solution for 404 urls, until I saw your response. Now I see that all my 404 urls are ending in "ico" or other words. Tnx! – Alexandru Pătraşcu May 25 '21 at 05:42
0

Maybe your url regexp doesn't include the uppercase characters in proper way. Can you post it here?

  • It was a problem with the config file; I was conditionally setting expiration headers and disabling logging for images, js, css, ico files, etc. I had: location ~* ^.+(jpeg|jpg|gif|css|png|js|ico)${ and changed it to: location ~* \.(jpeg|jpg|gif|css|png|js|ico)${ Now when I request a url that ends in one of those strings, it parses it as a url, and not as a file, so no more 404 errors. – Harrison Dec 21 '10 at 22:01