Re: *.cache.html blocked by firewall - GWT team opinions please?
Hi Sumit,
http://code.google.com/p/google-web-toolkit/issues/detail?id=3959
Thanks,
Joe
On Aug 18, 11:26 am, Sumit Chandel wrote:
> 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/c...
> > 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 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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
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 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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
It sounds like the firewall doesn't like the html file that is composed entirely of javascript. If you have access to the IT departments that run those firewalls, perhaps you could request that they disregard that rule for your particular sites. If that isn't possible you could maybe try using the XS linker to generate cache.js files (usually used for cross site loading) and perhaps the firewall would allow those to pass unmolested. -jason On Aug 12, 2009, at 8:24 PM, Joe Cole wrote: > > I know it's a firewall because if we type the *.cache.html url into > the browser it comes back with a document with a message from their > firewall claiming it's been blocked. The file scored very highly on > some metrics which their firewall uses. I am guessing it's because of > the large js because it was the same in pretty mode. > > We have seen this at two separate sites (different countries too), but > with different builds of the software (we have different servers > depending on the country). > > Regardless, if there is a problem I'd love to be able to check (e.g. > if the html downloaded by the nocache.js doesnt contain our script). I > think this is something gwt should do out of the box really - because > there are no errors thrown. Unfortunately the sites are private so I > can't share the links. > > On Aug 13, 4:42 am, Jeff Chimene wrote: >> On 08/12/2009 08:14 AM, Joe Cole wrote: >> >> >> >>> We have encountered this on another network now. >>> Does no one else have this problem? >> >> How do you know it's a firewall? >> >> Are you saying there are two different firewalls (with potentially >> different settings) blocking the same document? >> >> Is this a private site? Perhaps posting a link might help debug this >> problem. > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
On 08/13/2009 09:54 AM, Joe Cole wrote: > > >> 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. > > Yes, this would be a good solution in general. You are meaning > something similar to the way gmail loads, and if it takes longer than > usual it tells you? > We have users on networks that sometimes can take many minutes to load > the site (they are used to this on all sites) so this may cause issues > there though. That's a problem with watchdog timers. I'm not happy it takes minutes to load the site; but that's an issue for another time. >> I think that it doesn't have this logic because there's no single error >> handler that would satisfy all users. > > Ok, makes sense. That being said, there is some exception handling in the trunk version of the IFrame linker's JavaScript template that you should review. >> 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. > > Ahh. I just checked and the current linker we are using is the old > IFrame linker from 1.5.3 as you suspected. > Am I going to have to upgrade (we are currently on 1.5) to try this > linker? Yes, if you want to go whole-hog. I'd suggest a diff first to see if you can simply patch your local copy. > 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. > > I'd love to upgrade asap, but can't really before things stabilize as > we release daily at the moment to production sites. > Any idea when things are going to stabilize for an RC? No. That being said, if you're on 1.5 you should /very seriously/ evaluate the upgrade of your code base to 1.7. I know: there's never time to upgrade. I don't know what the delta is in the linker between TRUNK and 1.7. You should be able to comprehend the differences in the IFrame linker's JavaScript template between your version and the version in HEAD. I cannot see a reason why some of the differences between HEAD and 1.5 cannot be backported. At least you'll see a path to get some of the exception trapping and reporting you want. >> [*] >> 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? > > Two separate firewalls. I am not sure if they use the same one or not, > but I can try and find out. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
> 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. Yes, this would be a good solution in general. You are meaning something similar to the way gmail loads, and if it takes longer than usual it tells you? We have users on networks that sometimes can take many minutes to load the site (they are used to this on all sites) so this may cause issues there though. > I think that it doesn't have this logic because there's no single error > handler that would satisfy all users. Ok, makes sense. > 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. Ahh. I just checked and the current linker we are using is the old IFrame linker from 1.5.3 as you suspected. Am I going to have to upgrade (we are currently on 1.5) to try this linker? > >>> 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. I'd love to upgrade asap, but can't really before things stabilize as we release daily at the moment to production sites. Any idea when things are going to stabilize for an RC? > [*] > 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? Two separate firewalls. I am not sure if they use the same one or not, but I can try and find out. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
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 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 re
Re: *.cache.html blocked by firewall - GWT team opinions please?
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 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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
> 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
On Thu, Aug 13, 2009 at 3:20 AM, Joe Cole wrote:
>
> Hi Jeff,
>
> We already use the meta tags for errors and don't get any when the
> file is not what we expect.
> Looking at line 338:
>
> doc.open();
> doc.write(xhr.responseText);
>
> It would make sense to do a sanity check here for the content of the
> response. If GWT put it's MD5 somewhere in the response we could do
> something like:
>
> if( ! xhr.responseText.startsWith(STRONGNAME) ) {
> // call the meta error function noting malformed cache.html
> }
>
> Thoughts?
Is it malformed, or missing? 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'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.
After reviewing the source, the onerror function doesn't get called
when you need it for this particular issue.
Please try the cross-site linker.
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.
>
> On Aug 13, 8:32 pm, Jeff Chimene wrote:
>> One more point. The IFrame XmlHTTPRequest loader is found
>> inhttp://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/c...
>>
>> around line 312. It should be a SMOP to add a watchdog timer to this
>> activity.
>>
>>
>>
>> On Wed, Aug 12, 2009 at 7:43 PM, Joe Cole
>> wrote:
>>
>> > Yes, we already have gzip enabled.
>>
>> > But the point isn't that the firewall blocks it - that's easy to solve
>> > - it's that we can't intercept the error and let the user know what to
>> > do.
>> > The simple way is we can tell them to login via https (which the
>> > firewall can't block). But we can't do that if we don't know there's a
>> > problem.
>>
>> > On Aug 13, 2:28 pm, Jeff Chimene wrote:
>> >> On 08/12/2009 07:24 PM, Joe Cole wrote:
>>
>> >> > I know it's a firewall because if we type the *.cache.html url into
>> >> > the browser it comes back with a document with a message from their
>> >> > firewall claiming it's been blocked. The file scored very highly on
>> >> > some metrics which their firewall uses. I am guessing it's because of
>> >> > the large js because it was the same in pretty mode.
>>
>> >> > We have seen this at two separate sites (different countries too), but
>> >> > with different builds of the software (we have different servers
>> >> > depending on the country).
>>
>> >> > Regardless, if there is a problem I'd love to be able to check (e.g.
>> >> > if the html downloaded by the nocache.js doesnt contain our script). I
>> >> > think this is something gwt should do out of the box really - because
>> >> > there are no errors thrown. Unfortunately the sites are private so I
>> >> > can't share the links.
>>
>> >> I don't have the links at hand, but have you tried enabling compression
>> >> on the server side?
>>
>> >> I think there may be some Apache incantations on this list to enable
>> >> that feature.
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
Yes, we have considered making it https only, but as it's ~600k gzipped and some browsers don't cache SSL content we decided not to. I'm very surprised no one else has run into this error as it's happen quite a few times to us now. If this were a "public" app many people behind university or corporate firewalls would not be able to access it. On Aug 13, 11:57 pm, Juraj Vitko wrote: > "worked fine on ssl as it bypassed the firewall" > > Then one possiblity is to redirect to HTTPS imediatelly when someone > accesses the page through HTTP. > > But the GWT loading check should be implemented nonetheless. > > On Aug 4, 3:33 pm, Joe Cole wrote: > > > When debugging a customer who couldn't load our site with an http > > connection (worked fine on ssl as it bypassed the firewall) we came > > across an issue where if we tried to load the *.cache.htmlfile gwt > > was trying to load manually the companies firewall had displayed an > > error message. There was no error on the gwt side, so we were unable > > to provide feedback to the user. > > > Is it possible to write something in the nocache.js that checks that > > the *.cache.htmlthat is loaded is actually what we expect, and if > > not, we can get an error message back to the user in some way? > > > Currently we use the following method for detecting load errors, but > > they aren't being called. Could it be tied into this in some way? > > > > > > > > > > > > > > > E.g. a new meta property could be added that tells us the cache file > > is not able to be loaded, with the name of the cache file so we can > > show them the error by opening it in a new window so they can see the > > error message. > > > Joe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
"worked fine on ssl as it bypassed the firewall" Then one possiblity is to redirect to HTTPS imediatelly when someone accesses the page through HTTP. But the GWT loading check should be implemented nonetheless. On Aug 4, 3:33 pm, Joe Cole wrote: > When debugging a customer who couldn't load our site with an http > connection (worked fine on ssl as it bypassed the firewall) we came > across an issue where if we tried to load the *.cache.html file gwt > was trying to load manually the companies firewall had displayed an > error message. There was no error on the gwt side, so we were unable > to provide feedback to the user. > > Is it possible to write something in the nocache.js that checks that > the *.cache.html that is loaded is actually what we expect, and if > not, we can get an error message back to the user in some way? > > Currently we use the following method for detecting load errors, but > they aren't being called. Could it be tied into this in some way? > > > > > > > > > E.g. a new meta property could be added that tells us the cache file > is not able to be loaded, with the name of the cache file so we can > show them the error by opening it in a new window so they can see the > error message. > > Joe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
Hi Jeff,
We already use the meta tags for errors and don't get any when the
file is not what we expect.
Looking at line 338:
doc.open();
doc.write(xhr.responseText);
It would make sense to do a sanity check here for the content of the
response. If GWT put it's MD5 somewhere in the response we could do
something like:
if( ! xhr.responseText.startsWith(STRONGNAME) ) {
// call the meta error function noting malformed cache.html
}
Thoughts?
On Aug 13, 8:32 pm, Jeff Chimene wrote:
> One more point. The IFrame XmlHTTPRequest loader is found
> inhttp://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/c...
>
> around line 312. It should be a SMOP to add a watchdog timer to this activity.
>
>
>
> On Wed, Aug 12, 2009 at 7:43 PM, Joe Cole
> wrote:
>
> > Yes, we already have gzip enabled.
>
> > But the point isn't that the firewall blocks it - that's easy to solve
> > - it's that we can't intercept the error and let the user know what to
> > do.
> > The simple way is we can tell them to login via https (which the
> > firewall can't block). But we can't do that if we don't know there's a
> > problem.
>
> > On Aug 13, 2:28 pm, Jeff Chimene wrote:
> >> On 08/12/2009 07:24 PM, Joe Cole wrote:
>
> >> > I know it's a firewall because if we type the *.cache.html url into
> >> > the browser it comes back with a document with a message from their
> >> > firewall claiming it's been blocked. The file scored very highly on
> >> > some metrics which their firewall uses. I am guessing it's because of
> >> > the large js because it was the same in pretty mode.
>
> >> > We have seen this at two separate sites (different countries too), but
> >> > with different builds of the software (we have different servers
> >> > depending on the country).
>
> >> > Regardless, if there is a problem I'd love to be able to check (e.g.
> >> > if the html downloaded by the nocache.js doesnt contain our script). I
> >> > think this is something gwt should do out of the box really - because
> >> > there are no errors thrown. Unfortunately the sites are private so I
> >> > can't share the links.
>
> >> I don't have the links at hand, but have you tried enabling compression
> >> on the server side?
>
> >> I think there may be some Apache incantations on this list to enable
> >> that feature.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
One more point. The IFrame XmlHTTPRequest loader is found in http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js?r=5513 around line 312. It should be a SMOP to add a watchdog timer to this activity. On Wed, Aug 12, 2009 at 7:43 PM, Joe Cole wrote: > > Yes, we already have gzip enabled. > > But the point isn't that the firewall blocks it - that's easy to solve > - it's that we can't intercept the error and let the user know what to > do. > The simple way is we can tell them to login via https (which the > firewall can't block). But we can't do that if we don't know there's a > problem. > > On Aug 13, 2:28 pm, Jeff Chimene wrote: >> On 08/12/2009 07:24 PM, Joe Cole wrote: >> >> >> >> >> >> > I know it's a firewall because if we type the *.cache.html url into >> > the browser it comes back with a document with a message from their >> > firewall claiming it's been blocked. The file scored very highly on >> > some metrics which their firewall uses. I am guessing it's because of >> > the large js because it was the same in pretty mode. >> >> > We have seen this at two separate sites (different countries too), but >> > with different builds of the software (we have different servers >> > depending on the country). >> >> > Regardless, if there is a problem I'd love to be able to check (e.g. >> > if the html downloaded by the nocache.js doesnt contain our script). I >> > think this is something gwt should do out of the box really - because >> > there are no errors thrown. Unfortunately the sites are private so I >> > can't share the links. >> >> I don't have the links at hand, but have you tried enabling compression >> on the server side? >> >> I think there may be some Apache incantations on this list to enable >> that feature. > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
It does look like there's a hook for an error function. See http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js?r=5513 around line 186. Perhaps the "gwt:onLoadErrorFn" defined in a tag will work for you. Also maybe try the cross-site linker using the tag in your module.xml file I'm out of ideas. On Wed, Aug 12, 2009 at 7:43 PM, Joe Cole wrote: > > Yes, we already have gzip enabled. > > But the point isn't that the firewall blocks it - that's easy to solve > - it's that we can't intercept the error and let the user know what to > do. > The simple way is we can tell them to login via https (which the > firewall can't block). But we can't do that if we don't know there's a > problem. > > On Aug 13, 2:28 pm, Jeff Chimene wrote: >> On 08/12/2009 07:24 PM, Joe Cole wrote: >> >> >> >> >> >> > I know it's a firewall because if we type the *.cache.html url into >> > the browser it comes back with a document with a message from their >> > firewall claiming it's been blocked. The file scored very highly on >> > some metrics which their firewall uses. I am guessing it's because of >> > the large js because it was the same in pretty mode. >> >> > We have seen this at two separate sites (different countries too), but >> > with different builds of the software (we have different servers >> > depending on the country). >> >> > Regardless, if there is a problem I'd love to be able to check (e.g. >> > if the html downloaded by the nocache.js doesnt contain our script). I >> > think this is something gwt should do out of the box really - because >> > there are no errors thrown. Unfortunately the sites are private so I >> > can't share the links. >> >> I don't have the links at hand, but have you tried enabling compression >> on the server side? >> >> I think there may be some Apache incantations on this list to enable >> that feature. > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
Also - if it wasn't clear before you can simulate this problem by just moving your *.cache.html file. Your application will just sit there with it's loading spinner going, oblivious. On Aug 13, 2:43 pm, Joe Cole wrote: > Yes, we already have gzip enabled. > > But the point isn't that the firewall blocks it - that's easy to solve > - it's that we can't intercept the error and let the user know what to > do. > The simple way is we can tell them to login via https (which the > firewall can't block). But we can't do that if we don't know there's a > problem. > > On Aug 13, 2:28 pm, Jeff Chimene wrote: > > > On 08/12/2009 07:24 PM, Joe Cole wrote: > > > > I know it's a firewall because if we type the *.cache.html url into > > > the browser it comes back with a document with a message from their > > > firewall claiming it's been blocked. The file scored very highly on > > > some metrics which their firewall uses. I am guessing it's because of > > > the large js because it was the same in pretty mode. > > > > We have seen this at two separate sites (different countries too), but > > > with different builds of the software (we have different servers > > > depending on the country). > > > > Regardless, if there is a problem I'd love to be able to check (e.g. > > > if the html downloaded by the nocache.js doesnt contain our script). I > > > think this is something gwt should do out of the box really - because > > > there are no errors thrown. Unfortunately the sites are private so I > > > can't share the links. > > > I don't have the links at hand, but have you tried enabling compression > > on the server side? > > > I think there may be some Apache incantations on this list to enable > > that feature. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
Yes, we already have gzip enabled. But the point isn't that the firewall blocks it - that's easy to solve - it's that we can't intercept the error and let the user know what to do. The simple way is we can tell them to login via https (which the firewall can't block). But we can't do that if we don't know there's a problem. On Aug 13, 2:28 pm, Jeff Chimene wrote: > On 08/12/2009 07:24 PM, Joe Cole wrote: > > > > > > > I know it's a firewall because if we type the *.cache.html url into > > the browser it comes back with a document with a message from their > > firewall claiming it's been blocked. The file scored very highly on > > some metrics which their firewall uses. I am guessing it's because of > > the large js because it was the same in pretty mode. > > > We have seen this at two separate sites (different countries too), but > > with different builds of the software (we have different servers > > depending on the country). > > > Regardless, if there is a problem I'd love to be able to check (e.g. > > if the html downloaded by the nocache.js doesnt contain our script). I > > think this is something gwt should do out of the box really - because > > there are no errors thrown. Unfortunately the sites are private so I > > can't share the links. > > I don't have the links at hand, but have you tried enabling compression > on the server side? > > I think there may be some Apache incantations on this list to enable > that feature. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
On 08/12/2009 07:24 PM, Joe Cole wrote: > > I know it's a firewall because if we type the *.cache.html url into > the browser it comes back with a document with a message from their > firewall claiming it's been blocked. The file scored very highly on > some metrics which their firewall uses. I am guessing it's because of > the large js because it was the same in pretty mode. > > We have seen this at two separate sites (different countries too), but > with different builds of the software (we have different servers > depending on the country). > > Regardless, if there is a problem I'd love to be able to check (e.g. > if the html downloaded by the nocache.js doesnt contain our script). I > think this is something gwt should do out of the box really - because > there are no errors thrown. Unfortunately the sites are private so I > can't share the links. I don't have the links at hand, but have you tried enabling compression on the server side? I think there may be some Apache incantations on this list to enable that feature. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
I know it's a firewall because if we type the *.cache.html url into the browser it comes back with a document with a message from their firewall claiming it's been blocked. The file scored very highly on some metrics which their firewall uses. I am guessing it's because of the large js because it was the same in pretty mode. We have seen this at two separate sites (different countries too), but with different builds of the software (we have different servers depending on the country). Regardless, if there is a problem I'd love to be able to check (e.g. if the html downloaded by the nocache.js doesnt contain our script). I think this is something gwt should do out of the box really - because there are no errors thrown. Unfortunately the sites are private so I can't share the links. On Aug 13, 4:42 am, Jeff Chimene wrote: > On 08/12/2009 08:14 AM, Joe Cole wrote: > > > > > We have encountered this on another network now. > > Does no one else have this problem? > > How do you know it's a firewall? > > Are you saying there are two different firewalls (with potentially > different settings) blocking the same document? > > Is this a private site? Perhaps posting a link might help debug this > problem. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
I know it's a firewall because if we type the *.cache.html url into the browser it comes back with a document with a message from their firewall claiming it's been blocked. The file scored very highly on some metrics which their firewall uses. I am guessing it's because of the large js because it was the same in pretty mode. We have seen this at two separate sites (different countries too), but with different builds of the software (we have different servers depending on the country). Regardless, if there is a problem I'd love to be able to check (e.g. if the html downloaded by the nocache.js doesnt contain our script). I think this is something gwt should do out of the box really - because there are no errors thrown. Unfortunately the sites are private so I can't share the links. On Aug 13, 4:42 am, Jeff Chimene wrote: > On 08/12/2009 08:14 AM, Joe Cole wrote: > > > > > We have encountered this on another network now. > > Does no one else have this problem? > > How do you know it's a firewall? > > Are you saying there are two different firewalls (with potentially > different settings) blocking the same document? > > Is this a private site? Perhaps posting a link might help debug this > problem. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
On 08/12/2009 08:14 AM, Joe Cole wrote: > > We have encountered this on another network now. > Does no one else have this problem? How do you know it's a firewall? Are you saying there are two different firewalls (with potentially different settings) blocking the same document? Is this a private site? Perhaps posting a link might help debug this problem. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
On Wed, Aug 12, 2009 at 17:14, Joe Cole wrote: > > We have encountered this on another network now. > Does no one else have this problem? Why would anyone block *.cache.html on a proxy? > Once again: a firewall is blocking the .cache.html file. GWT just sits > there doing nothing, no error messages or anything. > Is there any way we can check to see if the cache.html file is loaded > correctly? It would be great to tell our users "you need to ask your > network administrators to remove our site from the banned list". You can probably change the default (iframe) linker to rename files pritty easily, or create your own see code in dev/core/src/com/google/gwt/core/linker/* However i have no experience with this. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
We have encountered this on another network now.
Does no one else have this problem?
Once again: a firewall is blocking the .cache.html file. GWT just sits
there doing nothing, no error messages or anything.
Is there any way we can check to see if the cache.html file is loaded
correctly? It would be great to tell our users "you need to ask your
network administrators to remove our site from the banned list".
On Aug 5, 11:14 am, Joe Cole wrote:
> I have been able to simulate the problem by causing a 404 when the
> *.cache.html is requested.
>
> Stepping through firebug, this is the relevant code in
> the .nocache.js:
>
> 22 function maybeStartModule(){
> 23 if (scriptsDone && loadDone) {
>
> scriptsDone is never true because the script is no longer available,
> which is happening when the cache.html gets blocked by a firewall.
> Therefore our application stays in a perpetual "loading application"
> page which isn't a good look.
>
> Is there a way to test whether the cache.html file has the correct
> content, assuming there is a way to wait for it to load completely?
>
> Joe
>
> On Aug 5, 1:33 am, Joe Cole wrote:
>
> > When debugging a customer who couldn't load our site with an http
> > connection (worked fine on ssl as it bypassed the firewall) we came
> > across an issue where if we tried to load the *.cache.html file gwt
> > was trying to load manually the companies firewall had displayed an
> > error message. There was no error on the gwt side, so we were unable
> > to provide feedback to the user.
>
> > Is it possible to write something in the nocache.js that checks that
> > the *.cache.html that is loaded is actually what we expect, and if
> > not, we can get an error message back to the user in some way?
>
> > Currently we use the following method for detecting load errors, but
> > they aren't being called. Could it be tied into this in some way?
>
> >
> >
>
> >
> >
> >
>
> > E.g. a new meta property could be added that tells us the cache file
> > is not able to be loaded, with the name of the cache file so we can
> > show them the error by opening it in a new window so they can see the
> > error message.
>
> > Joe
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: *.cache.html blocked by firewall - GWT team opinions please?
I have been able to simulate the problem by causing a 404 when the
*.cache.html is requested.
Stepping through firebug, this is the relevant code in
the .nocache.js:
22 function maybeStartModule(){
23 if (scriptsDone && loadDone) {
scriptsDone is never true because the script is no longer available,
which is happening when the cache.html gets blocked by a firewall.
Therefore our application stays in a perpetual "loading application"
page which isn't a good look.
Is there a way to test whether the cache.html file has the correct
content, assuming there is a way to wait for it to load completely?
Joe
On Aug 5, 1:33 am, Joe Cole wrote:
> When debugging a customer who couldn't load our site with an http
> connection (worked fine on ssl as it bypassed the firewall) we came
> across an issue where if we tried to load the *.cache.html file gwt
> was trying to load manually the companies firewall had displayed an
> error message. There was no error on the gwt side, so we were unable
> to provide feedback to the user.
>
> Is it possible to write something in the nocache.js that checks that
> the *.cache.html that is loaded is actually what we expect, and if
> not, we can get an error message back to the user in some way?
>
> Currently we use the following method for detecting load errors, but
> they aren't being called. Could it be tied into this in some way?
>
>
>
>
>
>
>
>
> E.g. a new meta property could be added that tells us the cache file
> is not able to be loaded, with the name of the cache file so we can
> show them the error by opening it in a new window so they can see the
> error message.
>
> Joe
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
