Thanks, I'll go for the cache-control public solution that you suggest such that the users can be confident about the confidentiality. I've tested with FF3 and IE7. These browsers seem to persistently cache the js when cache-control public is set on the reply headers. I don't know about Chrome. Speedtracer shows "From cache :false" but I do find the components in the cache. I don't know how the mobile browser handle it, but the js files are probably too big anyway to be cached.
Danny On 14 jul, 22:30, lineman78 <linema...@gmail.com> wrote: > Agreed, I had not thought of the caching issue, although this could > also be fixed by having your server set the cache-control header to > public when serving static content(doesn't work in FF2). An example > of how to do this can be seen here: > > http://onjava.com/pub/a/onjava/2004/03/03/filters.html > > While I agree that the icon may be a little scary to uninformed users, > I think it is probably better that way for the reasons I specified > before. At the same time, I wish both IE and Chrome would specify > which parts of the page are not secure so that advanced users can know > if there is something fishy going on. Just last night I had 2 of my > friends who are very non-technical ask me about security when it comes > to using free wifi. They have no clue what SSL is and it is much > easier for me to tell them to not put in any sensitive information > unless there is a lock icon on their screen. In your purposes you are > only loading javascript that has not data through an unencrypted > connection, but what is to keep you from doing jsonp and sending > unencrypted data, which from the browsers perspective looks exactly > the same, loading a javascript file. But from the users perspective > one is sending personal information over an unencrypted connection and > they should be notified because it is fairly serious. > > On Jul 14, 1:51 pm, Danny Goovaerts <danny.goovae...@gmail.com> wrote: > > > > > I'm not worried about the overhead for the encryption. I want to load > > the js over http because browsers do not cache content that is loaded > > over https. As my application is fairly large (800k, split into > > several deferred pieces, some of which are 200k) I want to have it > > cached as much as possible. This is not such an issue when using the > > application over Wifi, but it can be an issue when using it on mobile > > devices, provided they that they do caching of decent sized components > > (seehttp://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/ > > ). > > > I'd just whish that Google had picked another icon than the red skull > > and bones. > > > On 14 jul, 20:30, lineman78 <linema...@gmail.com> wrote: > > > > I believe this is expected behavior, even gmail does this if you have > > > https turned on. What is keeping you from using https for loading the > > > js? The browser doesn't know that the request you are sending doesn't > > > contain any sensitive data, therefore this is a desired behavior as > > > usually there is not real reason not to make a request once an SSL > > > session has been established because at that point a symmetric block > > > cipher is used which has very little overhead. > > > > On Jul 14, 10:17 am, Danny Goovaerts <danny.goovae...@gmail.com> > > > wrote: > > > > > I've deployed my GWT application over https. To allow caching of the > > > > javascript files, I load the bootstrap script over http : > > > > > <script language="javascript" src="http://www.cellamea.eu/cellamea/ > > > > cellamea.nocache.js"></script> > > > > > As expected, this gives a"mixed content warning" on Internet Explorer. > > > > On Firefox and Safari, the site loads normally. > > > > On Chrome (version 6.0.458.1 dev) however, I get a red "skull and > > > > bones" icon in the URL address bar instead of the green padlock icon. > > > > I think that this is even more scary for the users than the mixed > > > > content warning on IE. > > > > > Is this the expected behaviour on Chrome or do should I do something > > > > different? > > > > > Thanks in advance, > > > > > Danny -- 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-tool...@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.
