This problem has defeated my attempts at Google, so here goes. We were having an issue getting data from a WCF service (just lookup data, so we enabled it for HTTP GET requests). Every once in while it will return a 404. The stack trace does NOT appear to have WCF in the mix - the StaticFileHandler appears to be attempting to serve it.
I created a a sample WCF service on ASP.NET 3.5 SP1 and am able to reproduce the problem. This is my sample service - the only differences from stock WCF at this point are the AspNetCompatibilityRequirements and the enabling of WebScript and HTTP GET:
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class Service1 : IService1
{
public string DoWork(string param1)
{
System.Threading.Thread.Sleep(150);
return "bar";
}
}
[ServiceContract]
public interface IService1
{
[OperationContract]
[WebGet]
string DoWork(string param1);
}
Service config:
<service name="namespace.Service1">
<endpoint
behaviorConfiguration="WebScriptEnabled"
address="http://localhost:2961/svc/Service1.svc"
binding="webHttpBinding"
contract="namespace.IService1">
</endpoint>
</service>
Behavior config:
<behaviors>
<endpointBehaviors>
<behavior name="WebScriptEnabled">
<enableWebScript />
</behavior>
</endpointBehaviors>
</behaviors>
My node has aspNetCompatibilityEnabled="true">, but otherwise everything is pretty much OOB. I have no customizations on webHttpBinding at all.
If I F5 on VS 2008 using the built in web server and hit the URL, the very first request will result in a 404. If I continue to hit it with even a light load (7-10 simultaneous requests), I'll get a handful of 404 errors.
If I then let the load drop down to nothing and rerun my test, I can go to 50 simultaneous requests easily WITHOUT any errors.
My real service is much more complicated than this, but the fact that I can get a (nearly) stock sample to show this behavior is concerning, as though there might be a framework related issue. I've enabled WCF diagnostics and tracing but nothing shows in the logs (not unexpected since WCF is not in the stack trace when the 404 occurs).
I hope I'm doing something wrong and have not discovered a framework bug. My production environment is IIS6 and appears to exhibit the same behavior as my development server.