的机制来生成请求WebResource.axd的框架版本之间改变了吗？

  

显然应用安全更新（当然改变框架主版本）可改变涉及的WebResource.axd以这样一种方式，以使该误差在客户端 - 服务器交互。我们应用补丁后看到这个错误，原因似乎是客户端缓存 HTTP：//forums.asp .NET / T / 1609380.aspx - 错误走了30天左右。

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;
}   

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.