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,