Hi,
We are logging all error on the webserver, and for some of our customers (they are hosting their own web-server), there are thousands of errors each day like the following:
System.Web.HttpException (0x80004005): This is an invalid webresource request.
We have managed to locate the resource to a background image for the telerik tooltip.
A client that has this issue, can reset the browser cache and the error will go away for that client, but this is impossible to tell thousands of users to do so we would like to prevent this on the server!
I don't know for sure, but I think this is caused by for some reason the Machine Key has changed for our web application.
I guess this could change for several reasons, a "simple" one is a re-install of the web-server (new hardware) and then give the new server the same name.
I could easily reproduce this error by changing the Machine Key manually.
The following will happen when changing the Machine Key:
All links to WebResource.axd will be changed, BUT if using combined css with telerik, the combined css link will NOT change, it still looks like:
Telerik.Web.UI.WebResource.axd?compress=1&_TSM_CombinedScripts_=%3b%3bTelerik.Web.UI%2c+Version%3d2013.3.1029.45%2c+Culture%3dneutral%2c+PublicKeyToken%3d121fae78165ba3d4%3aen-US%3ac2b8033d-3a83-4465-9875-b583e310bb14%3aed2942d4
And inside that css are links to background images that leads to an invalid WebResource.axd!!!
To solve this, the combined link should also in some way be different if a different Machine Key!
Regards
Andreas
We are logging all error on the webserver, and for some of our customers (they are hosting their own web-server), there are thousands of errors each day like the following:
System.Web.HttpException (0x80004005): This is an invalid webresource request.
We have managed to locate the resource to a background image for the telerik tooltip.
A client that has this issue, can reset the browser cache and the error will go away for that client, but this is impossible to tell thousands of users to do so we would like to prevent this on the server!
I don't know for sure, but I think this is caused by for some reason the Machine Key has changed for our web application.
I guess this could change for several reasons, a "simple" one is a re-install of the web-server (new hardware) and then give the new server the same name.
I could easily reproduce this error by changing the Machine Key manually.
The following will happen when changing the Machine Key:
All links to WebResource.axd will be changed, BUT if using combined css with telerik, the combined css link will NOT change, it still looks like:
Telerik.Web.UI.WebResource.axd?compress=1&_TSM_CombinedScripts_=%3b%3bTelerik.Web.UI%2c+Version%3d2013.3.1029.45%2c+Culture%3dneutral%2c+PublicKeyToken%3d121fae78165ba3d4%3aen-US%3ac2b8033d-3a83-4465-9875-b583e310bb14%3aed2942d4
And inside that css are links to background images that leads to an invalid WebResource.axd!!!
To solve this, the combined link should also in some way be different if a different Machine Key!
Regards
Andreas
6 Answers, 1 is accepted
0
Hello ,
Thank you for contacting Telerik Support.
I have generated different machine keys in the IIS and everything is loaded correctly. Could you please send me a sample video how you configure your environment and reproduce the described behavior. Also please send me your sample to investigate it locally.
I will be glad to assist you further.
Regards,
Peter Filipov
Telerik
Thank you for contacting Telerik Support.
I have generated different machine keys in the IIS and everything is loaded correctly. Could you please send me a sample video how you configure your environment and reproduce the described behavior. Also please send me your sample to investigate it locally.
I will be glad to assist you further.
Regards,
Peter Filipov
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Andreas
Top achievements
Rank 1
Rank 1
answered on 28 May 2014, 04:22 AM
Hi,
This is what I think happens:
1. The browser downloads both the css and the background-image. And as you can see in the browser cache, both of these have an expire date of a year from now. What also might happen here is that the background-image isn't visible for some reason, and in that case the image doesn't download at all here...
2. For some reason the Machine Key changes.
3. At some point, the browser decides to download new background-images, even if the expire date hasn't happen yet (for example when IE is set to Automatically in cache settings that might happen), but it doesn't download a new css.
4. Since the browser didn't download a new css after the machine key was altered, all links to background-images in the css are invalid!!!
As you can see, this is not very likely to happen, but with thousands of users it will happen at some time for quite a lot users. These users will generate lots of calls since it is background-images that will try to download lots of times each day.
To simulate the above you can try the following sample:
This is what I think happens:
1. The browser downloads both the css and the background-image. And as you can see in the browser cache, both of these have an expire date of a year from now. What also might happen here is that the background-image isn't visible for some reason, and in that case the image doesn't download at all here...
2. For some reason the Machine Key changes.
3. At some point, the browser decides to download new background-images, even if the expire date hasn't happen yet (for example when IE is set to Automatically in cache settings that might happen), but it doesn't download a new css.
4. Since the browser didn't download a new css after the machine key was altered, all links to background-images in the css are invalid!!!
As you can see, this is not very likely to happen, but with thousands of users it will happen at some time for quite a lot users. These users will generate lots of calls since it is background-images that will try to download lots of times each day.
To simulate the above you can try the following sample:
<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="tooltip.aspx.vb" Inherits="TestaTredjepartWeb.tooltip" %><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head runat="server"> <title></title></head><body> <form id="form1" runat="server"> <asp:ScriptManager ID="s" runat="server"> </asp:ScriptManager> <telerik:RadStyleSheetManager ID="ssm" runat="server" EnableStyleSheetCombine="true"></telerik:RadStyleSheetManager> <telerik:RadToolTip ID="tt" runat="server" TargetControlID="pnl" Text="Testing"></telerik:RadToolTip> <div> <asp:HyperLink ID="hl" runat="server" NavigateUrl="~/tooltip.aspx">Reload</asp:HyperLink> <asp:Panel ID="pnl" runat="server" Width="100" Height="100" BackColor="Red" style="margin-top: 50px"> </asp:Panel> </div> </form></body></html>Do the following (important to NOT hover over the red area before step 4!!!):
1. Navigate to the page and DO NOT hover with the mouse over the red area (now the browser has downloaded the css, but not the background-image for the tooltip)
2. Generate a new machine key
3. Hit the reload button
4. Hover with the mouse over the red area, now the tooltip will display but without any background-images
5. Press F5 to refresh the page, now the tooltip will display correctly since the refresh did download a new css.
Regards
Andreas
0
Hello Andreas,
Thank you for the detailed steps. I was able to reproduce the described behavior. As a temporary solution you could remove the style sheet manager or use the same machine key after the PC change. I tried to stop the browser caching with the following approach but unfortunately it is not possible. We will need more time to debug the issue and find a permanent solution. As soon as we have results, I will contact you.
Regards,
Peter Filipov
Telerik
Thank you for the detailed steps. I was able to reproduce the described behavior. As a temporary solution you could remove the style sheet manager or use the same machine key after the PC change. I tried to stop the browser caching with the following approach but unfortunately it is not possible. We will need more time to debug the issue and find a permanent solution. As soon as we have results, I will contact you.
Regards,
Peter Filipov
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Andreas
Top achievements
Rank 1
Rank 1
answered on 30 May 2014, 02:19 PM
Hi,
The solution from your side should be to simply make the stylesheet url, that the stylesheet manager generates, dependent on the machine key!
Regards
Andreas
The solution from your side should be to simply make the stylesheet url, that the stylesheet manager generates, dependent on the machine key!
Regards
Andreas
0
Hi Andreas,
Thank you for your suggestion, we will try to implement it. As soon as we resolve the problem I will let you know. In way of gratitude I have updated your Telerik Points
Regards,
Peter Filipov
Telerik
Thank you for your suggestion, we will try to implement it. As soon as we resolve the problem I will let you know. In way of gratitude I have updated your Telerik Points
Regards,
Peter Filipov
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Hi Andreas,
I am glad to inform you that this issue is resolved and the fix will be available in the first Internal build after Q2 SP1 2014 release.
Regards,
Aneliya Petkova
Telerik
I am glad to inform you that this issue is resolved and the fix will be available in the first Internal build after Q2 SP1 2014 release.
Regards,
Aneliya Petkova
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.