On 08/13/2009 08:40 AM, Joe Cole wrote: > > 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?
Yes. I'd give that a shot. I am wondering why you're not going for the watchdog timer. I'd throw such logic at this problem too. > > 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. Which is demonstrated by the above patch. >> 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. Comment below. >>> 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 think that it doesn't have this logic because there's no single error handler that would satisfy all users. >> I understand we can't regenerate it - I was trying to propose a >> solution. I think you *might* be able to regenerate it. You'd have to see how the compiler creates that hash to know for sure. >> Another solution would be for the gwt script to check the response for >> an error code - is that possible? Which you've demonstrated above. >>> 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"). Now I see that the bootstrap logic in trunk HEAD is somewhat different than your original example (posted on 4-Aug). Please take a moment to look at trunk HEAD's bootstrap to see if there's something you can use. Perhaps the diff between your current GWT version and HEAD will be illuminating. >>> 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 not sure it will. The XS linker implements another way of getting the *.cache.html file to the client. It's cheap to try (simply add a line to your module.xml file) and may be a win in that the firewall responds differently. Although if it's a size-based rule, the firewall will probably restrict this technique too. I admit that I'm grasping at straws with this suggestion. On this topic, you might also try upgrading to the GWT trunk and experimenting with the code splitting logic. There is a cost to this besides time: you will have to analyze and modify the code to see what parts of it can load later than others[*]. So, following this suggesting will produce a branch of your current trunk. The SOYC linker produces a report that will aid in this implementation. Remember that you can have several GWT versions installed on a single machine; if there's a problem you simply revert to the older GWT version. [*] And if you're on GWT 1.5 or earlier, you will see a lot of deprecated code warnings. >>> 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. Just to be clear: these installations use the same firewall with the same (probably default) settings? >> Thanks for your help. Apologies if you are confused! No prob. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
