Request format is unrecognized for URL unexpectedly ending in /SomeWebServiceMethod
At Pageflakes, our webservers; event logs are being flooded with this error. In ASP.NET AJAX 1.0 version, Microsoft added a check for all web service calls to have Content-Type: application/json in the request headers. Unless this request header is present, ASMX handler fires an exception. This exception is raised directly from the ScriptHandler which handles all web service calls made via ASP.NET AJAX.
This is done for security reason. This prevents anyone from feeding off from your webservices. For example, you might have a webservice that returns some useful information that others might be interested to consume. So, any one could just add a <script> tag pointing to that web service URL and get the json. If that webservice is a very expensive webservice in terms of I/O and/or CPU, then other websites feeding off from your webservice could easily bog down your server.
Now, this back fires when you have HTTP GET supported webservice calls that produce response headers to cache the response. For example, you might have a webmethod that returns Stock Quotes. You have used response caching so that browser caches the response of that webmethod and repeated visit do not produce repeated calls to that I/O costly webservice. What will happen is proxy gateways or proxy servers will see that their client users are making this request frequently and it can be cached. So, they will make periodic calls to that webservice and try to precache them on behalf of their client users. However, during precache, they won't send the Content-Type: application/json header. That's what I have seen for several proxy servers. As a result, it produces exception and you get your event log flooded with this exception.
The reason why MS might have not seen this or anyone else is because there's no way to make HTTP GET response cacheable on browser from webservice calls unless you do the hack I mentioned in earlier blog post.
However, one thing that puzzles me is we get this error so frequently and the request headers look so legitimate that I am not 100% sure whether it's the proxies not producing the content-type header properly all the time. Somehow the error patterns look like an registered user is trying to use the site and failing. It is possible that some firewall might see this content-type as invalid content type and filter out the header.