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.