Original: Negotiation: Discovered File(s) Matching Request: None Could Be Negotiated.

Posted June 24, 2011 at 9:30 AM by Ben Nadel

Yesterday, I lost at least two hours trying to figure out why my local copy of a website was throwing 404 (File Not Found) errors. We had just implemented some URL rewriting on the production site and things appeared to be working fine. On my local computer, however, the URL rewriting would only work for some URLs. After a lot of Googling, a little bit of a meltdown, and walk around the block to clear my head, I finally figured out what was going wrong: MultiViews.

For this particular website, we were using Apache to create a more resource-oriented URL scheme. So, where we used to have URLs that looked like this:

/users.cfm?action=view&id=15

… we were going to be moving to a URL scheme that looked more like this:

/users/15/view/

For the majority of URLs in the application, this was working fine. But for a few URLs, this came back as a 404 File Not Found error. When I looked in the Apache error logs, I kept seeing log items like this:

[Thu Jun 23 16:55:06 2011] [error] [client 127.0.0.1] Negotiation: discovered file(s) matching request: /Sites/something.com/users (None could be negotiated).

My experience with the Apache HTTP server is somewhat limited; as such, this error didn’t really mean anything coherent to me at the time. And, much of my Googling wasn’t really yielding anything too valuable. Finally, however, I did come across a threaded discussion that mentioned “MultiViews”. On the Apache website, the effect of Multiviews, as listed under Content Negotiation, is as follows:

If the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements.

This is exactly what was happening! When the user requested the non-existent URL:

/users/15/view/

… Apache was finding this physical file on a per-directory basis:

/users.cfm

… and then using Content Negotiation to try and figure out which file it should served up based on the request headers. And, since I didn’t have any file types configured for content negotiation, Apache didn’t know how to respond and just returned a 404.

When I checked in my Virtual Host configuration, sure enough, MultiViews was enabled:

 Launch code in new window » Download code as text file »

The moment I removed the MultiViews option:

 Launch code in new window » Download code as text file »

… everything started working fine.

This goes to show you how bad it is to simply enable settings when you are not sure what they do. I’ve grown to love my Apache server; but, clearly, there is so much more that I need to learn about it. When it works, it works; but, when it doesn’t, I have no idea what’s going on.