Le 01/04/12 12:55, Petr Bena wrote:
I see no point in doing that. Https doesn't
support caching well and
is generally slower. There is no use for readers for that.
HTTPS has nothing to do with caching, it just transports informations
between the client and the server so they can actually handle caching.
HTTPS supports caching as well as HTTP since they are exactly the same
protocol, the first just being encrypted.
You are right though, in the sense of most web browsers will BY DEFAULT
not save a copy of the received content whenever it is received through
HTTPS. The reason behind is that HTTPS page is/was usually used to
serve private content. Caching can be explicitly set to caching by
marking it as public, send "Cache-Control: public" and that should work.
I do agree there is probably no use for readers to have HTTPS enabled.
If the purposes is to bypass countries firewall such as in China (or I
think Thailand), they will just intercept the HTTPS connection form the
server on their hardware, decypher it for analysis and resign the
content with their own certificate before sending it back to clients.
That is exactly what you do in a big company when you want to make sure
(as an example) that your employee do not use the chat function in Facebook.
The only thing HTTPS is going to prevent, is being still its password
when logging in or getting the session cookie hijacked by sniffing the
local network. The WMF has already moved its private wikis to HTTPS
just for that :-]
cheers,
--
Antoine "hashar" Musso