*.cache.html blocked by firewall - GWT team opinions please?
Joe Cole
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?
<meta name="gwt:onLoadErrorFn" content="loaderror"></meta>
<meta name="gwt:onPropertyErrorFn" content="unsupported"></meta>
<script type="text/javascript">
<!--
// Called when GWT is not supported
function unsupported() {
document.getElementById('loading').className = "loadError
message-center-screen";
document.getElementById('loading-content').innerHTML = "Your
browser is not supported. Please reload with a modern browser such as
<a href=\"http://www.getfirefox.com\">Firefox</a> or Internet Explorer
Version 6 or Above.";
}
function loaderror(){
document.getElementById('loading').className = "loadError message-
center-screen";
document.getElementById('loading-content').innerHTML = "Error:
There was a problem loading the application.";
}
-->
</script>
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
Joe Cole
*.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
Joe Cole
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".
Thomas Matthijs
>
> 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.
Jeff Chimene
>
> 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.
Joe Cole
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.
Joe Cole
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 <jchim...@gmail.com> wrote:
Jeff Chimene
>
> 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.
Joe Cole
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.
Joe Cole
moving your *.cache.html file.
Your application will just sit there with it's loading spinner going,
oblivious.
Jeff Chimene
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 <meta> tag will work for you.
Also maybe try the cross-site linker using the
<add-linker name="xs" />
tag in your module.xml file
I'm out of ideas.
Jeff Chimene
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.
Joe Cole
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 <jchim...@gmail.com> wrote:
> One more point. The IFrame XmlHTTPRequest loader is found inhttp://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/c...
Juraj Vitko
accesses the page through HTTP.
But the GWT loading check should be implemented nonetheless.
Joe Cole
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 <juraj.vi...@gmail.com> 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 <profilercorporat...@gmail.com> 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
> > 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
Jeff Chimene
>
> 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?
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.
Joe Cole
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.
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.
(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.
> 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.
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!
Joe Cole
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?
Jeff Chimene
>
> 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.
Joe Cole
> 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.
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.
> 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.
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.
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?
but I can try and find out.
Jeff Chimene
>
>
>> 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.
Jason Essington
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
Sumit Chandel
Hmm. The gwt code to load the cache.html seems to be ignoring error
states:
line 315:
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?
Joe Cole
http://code.google.com/p/google-web-toolkit/issues/detail?id=3959
Thanks,
Joe
> Hi Joe,
> Please see reply inlined below.
>
> Hmm. The gwt code to load the cache.html seems to be ignoring error
>
> > states:
>
> > line 315:
>