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'ooh. 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
-~--~~~~--~~--~--~---
