Re: Optimizations vs Functionality vs Architecture

In message <>, Yoav Nir writ

>> 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