Hi Joe, Please see reply inlined below. 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?
You make a good point here. I think it would make sense to have a hook that developers could implement here for such failure cases. Would you mind filing an issue for this in the Issue Tracker? That way, you'll automatically be notified of updates to the issue, and I can assigning to someone on the team for further consideration. Issue Tracker: http://code.google.com/p/google-web-toolkit/issues/list Cheers, -Sumit Chandel > > > 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 -~----------~----~----~----~------~----~------~--~---
