Question

I have a large .NET 2 web application that has been updated to target the .NET 4.0 framework. Since the update, I am seeing the following error recurring regularly in my logs:

This is an invalid webresource
request.

The resource requested is “~/WebResource.axd”
As far as I can tell, the request looks fine in that there’s a long querystring with keys (keys are d, t) and values for those keys.

Has the mechanism for generating requests to WebResource.axd changed between framework versions? Does anyone have any advice about how to go about debugging this issue?

Edit:
I found a way to decrypt the web resource request querystring (code follows). The requested resource is pCSSFriendly|CSSFriendly.CSS.Menu.css which looks like an issue with addressing the CSSFriendly.MenuAdapter resource which is used by the application. That leading “p” looks like it could be the problem.

private string DecryptWebResource(string urlEncodedData)
{
    byte[] encryptedData = HttpServerUtility.UrlTokenDecode(urlEncodedData);
    Type machineKeySection = typeof(MachineKeySection);
    Type[] paramTypes = new Type[] { typeof(bool), typeof(byte[]), typeof(byte[]), typeof(int), typeof(int) };
    System.Reflection.MethodInfo encryptOrDecryptData = machineKeySection.GetMethod("EncryptOrDecryptData", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic, null, paramTypes, null);

    try
    {
        byte[] decryptedData = (byte[])encryptOrDecryptData.Invoke(null, new object[] { false, encryptedData, null, 0, encryptedData.Length });
        string decrypted = Encoding.UTF8.GetString(decryptedData);
        return decrypted;
    }
    catch (System.Reflection.TargetInvocationException)
    {
    }

    return String.Empty;
}   

Answer 1

Has the mechanism for generating requests to WebResource.axd changed between framework versions?

Apparently applying security updates (and certainly changing framework major versions) can alter the client-server interaction involving WebResource.axd in such a way as to cause this error. We saw this error after applying patches and the cause seems to be client side caching http://forums.asp.net/t/1609380.aspx – the errors went away after 30 days or so.