yes, there are differences. Testing: Use -noserver. Google for it on this newsgroup for more info on how that works.
SSL has three notable differences. These aren't the only ones, but probably the biggest surprises: CACHING: Web browsers were designed to cope with idiot web server maintainers. This was a phenomenally stupid move, as you should never underestimate the ingenuity of idiots, but, alas, we're stuck with this bass ackwards principle, and it screws you over when you use SSL. The first culprit is caching. In SSL mode, you can push 'please cache me' all you want, but in general web browsers will ignore you. You should still try, but, take it with a grain of salt, and make sure you're set up to handle quite a bit of bandwidth. I've got an item on my todo list I should really get to, and that's to create a table to list which HTTP headers, if any, will make a browser cache stuff in SSL mode. REFERRAL: Web browsers will not send a referrer header if you link from https to http. The thinking here is that in the olden days, not everyone had cookies enabled, so you faked it by storing the session ID in the url itself, and you inspected the URL instead of the cookie to figure out a user's session id. This was not just a flagrant abuse of the whole concept of HTTP, but also a gaping security hole, because browsers tend to litter URLs all over the place. In caches, history data, and, yes, referral links. Instead of recognizing that this behaviour is simply security broken and spreading the word to stop doing it, the SSL standard edicts that HTTPS pages should not be sent as referrer to non-http pages, evidently in some sort of screwed up belief that sites running on https are more trustworthy in case an https page did use the session id in the URL trick to get around disabled cookies. D'ooooooh. You can fix it by bouncing all links through plain http on your own server, letting it redirect. But that's an ugly hack, and I won't get into how to set that up in this post. MIXED MODE WARNING: IE is especially sucky at this. You're free to swap the document domain between http and https all day long,but load one non-https piece of content in an https loaded page and the user gets an awkwardly huge warning dialog that no one understands and make them run for the hills. In practice there's rather little security leakage in e.g. loading user avatar images off of non-https, but, again, the SSL standard thinks it knows better than you and stubbornly gets in your way. Not to mention the rather stark difference between proctecting yourself against eavedroppers and the harder task of keeping out man-in-the-middle attacks. SSL acts as if the first (just protect against eavesdroppers) is somehow beneath it. Argh. No solution to this one as far as I know. Load it all over SSL. Yet another reason why so many people use SSL only for login and then move out, to avoid these issues, not because it costs a little more CPU. FORK OUT SOME DOUGH: https sans a signed certificate is like a party without booze. What's the point? Unfortunately, in order to be considered signed on all major browsers, you need to shell out some cash, about 100 dollars for a single domain, 500 for all subdomains to one domain. This step isn't optional - the security dialog that pops up when your SSL cert isn't signed properly is a lot scarier for a user than no https at all, and for once for good reason, as there's no way to verify that you're really talking to whatever's in your location bar without it. Just don't give your money to those bastards at verisign. They'll kill the internet if it were up to those freedom haters. That means, avoid verisign, thawte, and GeoTrust. Consider Comodo, or Entrust. I strongly urge you to heed this warning; verisign's control of the universally accepted root cert market is around 80% nowadays. If they control all of it, expect your yearly costs (oh, yeah, that 100 bucks is a yearly payment, sorry) to go sky high. It's in all of our best interests if that does not come to pass. Good luck, Hez. On Sep 17, 6:20 pm, hezjing <[EMAIL PROTECTED]> wrote: > Hi > I have a GWT application, and it is running without HTTPS. > > What need to be done if I want this GWT application to run with HTTPS? > Is there any changes in the code and configuration? > > Can I test HTTPS in hosted mode? > > Is there any difference when designing a GWT application for HTTP and HTTPS? > > -- > > Hez --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---