Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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
add comment

2 Answers 2

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.

share|improve this answer
add comment

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

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.