- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 21 Aug 2012 19:14:51 +0000
- To: Yoav Nir <ynir@checkpoint.com>
- cc: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
In message <4278A78A-6ADF-4114-AE62-8F07DEFB5EFF@checkpoint.com>, Yoav Nir writ es: >> A closer analysis shows that it would be even better if secured >> and unsecured requests could share a connection (think intermediary >> to server for instance.) > >I'm not in the TLS-all-the-time camp, but why would you want to mix secure = >and insecure content? How would the user know what parts of the screen that= > he sees are secure and what parts are not? It would (not need to) be different from today. The point is that the client could open a TCP connection to the server, and when the user decides to login, those requests/responses can be secured, without opening another TCP connection as we do today. If the site expects the user to login, it can start the negotiation of security even before the user has hit login, shaving the X RTT's it takes to exchange certificates and keys of the response time. >We should if it's possible. Suppose HTTP/2.0 looks much like the SPDY draft. >How can you ever get a current HTTP/1 server to reply to this? That's why I've been saying from the start that SPDY was an interesting prototype, and now we should throw it away, and start from scratch, being better informed by what SPDY taught us. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 21 August 2012 19:15:22 UTC