For example, in the current design of HTTP the decision as to whether to use encryption is completely up to the server; the only thing the user can do is observe whether a URL is “HTTP” or “HTTPS” (or maybe watch a lock icon) and decide whether they can continue surfing.
This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insists on something the other finds unacceptable (e.g. a 404 response to "GET /your-secret-plans HTTP/1.1") then the transaction doesn't take place. Perhaps this could be made more explicit via a header, but what would that really gain?
I think he's saying that clients could decide beforehand whether they want to go into HTTPS-only mode, for example.
But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.
But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.
Yes - and my understanding is that the browser developers are going to require all HTTP2 connections to be over TLS anyway.
This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insists on something the other finds unacceptable (e.g. a 404 response to "GET /your-secret-plans HTTP/1.1") then the transaction doesn't take place. Perhaps this could be made more explicit via a header, but what would that really gain?