|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Hi, Recently (maybe since upgrading to latest EO version ?), we started to occasionnally receive the following error message: How can we avoid this ? ========================= Computer : HB1638 Log : Application Source : ASP.NET 2.0.50727.0 Level : Warning Category : Web Event Id : 1309 Time : 9/12/2007 10:59:13 AM User : Event code: 3005 Event message: An unhandled exception has occurred. Event time: 9/12/2007 10:59:13 AM Event time (UTC): 9/12/2007 8:59:13 AM Event ID: 74e4e7dbd41c40589913d8acd3f2e037 Event sequence: 24730 Event occurrence: 18 Event detail code: 0 Application information: Application domain: /LM/W3SVC/657964845/Root-1-128339960136781250 Trust level: Full Application Virtual Path: / Application Path: D:\Sites\Dolcevita\ Machine name: HB1638 Process information: Process ID: 44176 Process name: w3wp.exe Account name: HB1638\apDolcevita Exception information: Exception type: HttpException Exception message: Virtual Url 072e8c79-aaae-4a12-9358-6b7da4a2d005 not registered. Request information: Request URL: http://www.dolcevita.be/eo_web.ashx?id=072e8c79-aaae-4a12-9358-6b7da4a2d005 Request path: /eo_web.ashx User host address: 66.249.65.133 User: Is authenticated: False Authentication Type: Thread account name: HB1638\apDolcevita Thread information: Thread ID: 11 Thread account name: HB1638\apDolcevita Is impersonating: False Stack trace: at EO.Web.Internal.ak.a(ct A_0) at EO.Web.Internal.ak.a(HttpApplication A_0) at EO.Web.Internal.ei.a(HttpContext A_0) at EO.Web.Runtime.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) =======================
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
That's normal. What happens is we change the GUIDs for our JavaScript files every build and many users still have a cached old version of your page; When they open up their browser the browser will request with the old IDs, which no longer exists, and you will get this error. As long as they refresh their page, the error should go away.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Do the users see the error in their browser ? If so, is a javascript error (small yellow triangle in IE, and some features no the page not working), or an http error (like xxx not found). Is there a way to avoid this, like forcing their browser to always get the latest version and ignore locally cached versions ?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
They may see a script error. Unfortunately there is no way to avoid that when the error is result of a cached version --- at which point they have not even connected to the server yet. The very reason that their issue occur is because the server has changed, so they must refresh their page accordingly, otherwise even if it renders fine, it opens the door to a whole lot of unknown problems because they would them be acting on top of a page that does not match your server.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Hi again,
This error seems to happen more frequently then I would expect if it's just when users go to the website while having an old version in their browser cache. Is there really nothing that can be done about it ? Knowing how impatient user are, I think it is not admittable that when for instance they click the datepicker, nothing happens ... and neither can I put a message on the site, indicating that if the popup doesn't shows up, they should do a refresh .. please help ... Thanks _
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
For instance, could I use one or more of the following code lines ?
Response.Buffer=true
Response.ExpiresAbsolute=DateTime.Now.AddDays(-1d);
Response.Expires =-1500;
Response.CacheControl = "no-cache";
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Or are these better ? (working for both IE and FireFox but not for Opera ?)
System.Web.HttpContext.Current.Response.Expires =-1500;
System.Web.HttpContext.Current.Response.Cache.SetNoStore();
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Or maybe in IIS, for eo_web.ashx I can set the HTTP Header, so that the contents expires after 1 hour ?
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Or Maybe = if this is no already the case, you should add something like the following code in the handler for eo_web.ashx ?
context.Response.Cache.SetExpires(DateTime.Now.AddSeconds(600));
context.Response.Cache.SetCacheability(HttpCacheability.Public);
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Absolutely not. I do not think it makes any sense to make any effort to make old cached page to work with newly updated server. Here we told you under this scenario there could be this problem, then you could spend days to patch around this scenario; Tomorrow you yourself modified one of your page you get another scenario to deal with. In reality its not possible to prevent such situations. Not to mention the potential security issues related to it. You can completely turn off the cache to avoid such problems, but it just defeats the purpose of the cache completely.
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Sorry, but my goal is not to make the old cached page work with the newly updated server, I understand this is not possible ...
But I'd like to avoid problems when your javascript guids will be updated again in the next release ... so my goal is to limit the caching in time (for exemple to 20 minutes, default duration of a session), and this only for the concerned ressources (requested trough eo_web.ashx ?).
Alexis
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi Alexis,
The exact reason that we change the Javascript GUID is to avoid the "old cached page with newly updated server" problem. In a way JavaScript file is a "page", it's just a page that other page relies on --- whether its the page itself has been changed or a piece that the page is relying on has changed really does not make any difference. So even if they look very different on the surface, it's actually the same inside.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Sorry to insist. I really think I understand why your are changing the Javascript GUID, and I think it's good practice.
But how can we avoid that users keep cached references to an outdated scripts on their pc, making the datepicker (for example) not working ? As I said, we cannot put a message saying ("if the datepicker does not work, please hit refresh"), and we cannot expect the average website visitor to do a refresh when a datepicker is not working ... he might just go away to a competitor's site ... so why not make the pages (which might contain references to older scripts) expire after about let's say 1 hour ?
PS: I am really not trying to be smarter than you are ... just trying to avoid having non-working datepicker ;-)
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi Alexis,
Of course you can make the page expires after an hour or even not caching at all and there are various ways to do it, a few of which you have already mentioned. But then you are risking significantly bringing down your sites performance and your site will appear slower than your competitors, which could drive more users away. I personally do not believe it's a better trade off but of course, ultimately it's your decision.
Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
Sorry to re-open this discussion, but this error keeps showing up ...even several weeks after the update (I would expect these error messages to extinct), while the previous version was just live for a few days ... couldn't a configuration or other problem cause this error message ? (you can access the live pages generating the errors at http://www.dolcevita.be, and on most other pages on this website.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi, We have verified that the ID you posted (072e8c79-aaae-4a12-9358-6b7da4a2d005) is not from the current version. The only thing that I can think of rather than user having an older version is some search engine has an older site map. This error message is like a 404. If it was a configuration issue, the ID would at least appear in our current code base. Or where would that ID come out? I am not sure what you mean by "you can access the live pages generating the errors at http://www.dolcevita.be". Do you mean it generates the error every time you visit the page? It would be a totally different story if that is the case. Thanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 8/27/2007
Posts: 44
|
I checked the IIS logs, and indeed, it is Google the bot that keeps requesting these outdated URL's (about 5) ... several times a day ...
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
AlexisVZ wrote:I checked the IIS logs, and indeed, it is Google the bot that keeps requesting these outdated URL's (about 5) ... several times a day ...
Here you go. Thanks for the update.
|
|