On 8/1/2014 6:06 PM, James H. H. Lampert wrote:
Why would you want to do that? Other than a few extra server CPU
cycles,
what's the harm in allowing SSL anywhere at the client's discretion?
I'm with Chuck on that one.
From the docs:
Also, while the SSL protocol was designed to be as efficient as securely
possible, encryption/decryption is a computationally expensive process
from
a performance standpoint.
Well, I'll say that I find it rather irritating, when on my dial-up
(YES, DIAL-UP) at home, that Google unilaterally insists on HTTPS unless
you're signed on, and explicitly opt out of it.
But then again, there are a LOT of web sites that are immensely
bandwidth-intensive, and actively hostile to older browsers (that may
nonetheless be the newest browsers available for a given combination of
hardware and OS), all for no good reason (other than adware and
spyware), and SSL is only a small part of that unnecessary waste of
bandwidth.
But that said, I think that when there's no overriding security reason
to require SSL, and no overriding bandwidth limitation reason to
prohibit it, it should be the user's call on whether to use HTTP or HTTPS.
I don't think the problem is so much bandwidth as it is server CPU.
Encryption and decryption are very cpu-intensive tasks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
