On Thu, Aug 13, 2009 at 3:20 AM, Joe Cole<profilercorporat...@gmail.com> 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 <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...
>>
>> 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<profilercorporat...@gmail.com>
>> 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 <jchim...@gmail.com> 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
-~----------~----~----~----~------~----~------~--~---
