Hmm. The gwt code to load the cache.html seems to be ignoring error states:
line 315: http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js?r=5513 xhr.onreadystatechange = function() { // 4 == DONE if (xhr.readyState == 4) { Shouldn't we add another check like: if( xhr.status != 200 || xhr.status != 304 ) throwDocumentError(); This is probably a good thing to add in do you think? On Aug 14, 3:30 am, Joe Cole <profilercorporat...@gmail.com> wrote: > > Is it malformed, or missing? > > If I remove the file (cause a 404 response) gwt doesn't throw an error > that I can catch. I used this to reproduce the error for testing > purposes. > In production, the file is there, and the user has a firewall that > blocks it and if it returns an error page, gwt doesn't throw an error > that I can catch. I was using the missing file to replicate it > locally. > > > The MD5 value is the STRONGNAME. Whether > > you can reproduce that hash is another matter; which algorithm means > > another trip through the source. If you can recalculate the hash, > > you'd simply compare that value to STRONGNAME. But you'd never get a > > chance to calculate the hash since the file's only partially received. > > I was hoping that the generated nocache.js would have this (or > something) to check that the document returned by the server (or > firewall) it loaded via xhttp was valid. > I understand we can't regenerate it - I was trying to propose a > solution. > Another solution would be for the gwt script to check the response for > an error code - is that possible? > > > I'm under the impression that the file's missing. In which case I'd > > implement a watchdog timer in that routine. I'm guessing that Google > > doesn't implement a such a timer because there's no single > > implementation that would fit all circumstances. > > The file isn't missing - if I load up the cache.html file manually > (e.g.www.mycompany.com/STRONGNAME.cache.html) at sites with a strict > firewall we get an error document explaining that it's been blocked by > the firewall and rationale (e.g. a high "score"). > > > After reviewing the source, the onerror function doesn't get called > > when you need it for this particular issue. > > Agreed. > > > Please try the cross-site linker. > > I've never used it before - how will this help? > > > I'm guessing others haven't seen this since it's specific to these > > firewall settings? Or are these separate customers with different > > firewalls? I have seen on this list a very difficult to reproduce > > issue regarding RPC cargo getting truncated on the trip to the server. > > But, obviously, that's after loading the script. > > These are two separate customers (one university installation, one > corporate on separate continents). > I have seen the truncation issue before with a personal firewall > (Norton) as well. > > Thanks for your help. Apologies if you are confused! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
