[TazeTSchnitzel]

HTTP/1.1 and HTTP/2.0 will coexist forever. HTTP/2 is mostly just a higher-performance, binary version of HTTP/1.1.

HTTP/1.0 is basically dead and has been for years, because it lacks Host: and so cannot be used for vhosts.

[bodyfour]

That's not completely accurate about HTTP/1.0. It's true that HTTP/1.1 requires "Host:" (a compliant server MUST reject any request from a 1.1 client that lacks that header). However, HTTP/1.0 clients had been sending "Host:" headers for years before the 1.1 standard came out.

It's still possible to use a 1.0 client today if you don't want to handle other client-side requirements of 1.1 like chunked transfer-encoding. Likewise, embedded devices can speak 1.0 only without any problem.

[TazeTSchnitzel]

Host: isn't part of HTTP/1.0, though, and if you try to send it, some servers will respond to you with HTTP/1.1!

[bodyfour]

It's perfectly normal (and allowed) for servers to send back a version string of "HTTP/1.1" even if the client sent the request as "HTTP/1.0". As long as they don't do anything in their response that assumes that the client has 1.1 features, all is fine. This basically just means: * Don't use chunked encoding in the response. (Technically a 1.0 client could specifically indicate support for that by sending a "TE: chunked" header, but since chunked encoding arrived at the same time as 1.1 I think most servers just assume that HTTP/1.0 clients never support it) * Don't assume that the client supports keep-alive connections. However, prior to HTTP/1.0 clients often did indicate that they could do keep-alive by sending "Connection: keep-alive". The only real difference in 1.1 is that now the client must support it unless they specifically indicate that they don't by sending "Connection: close". In the absence of a "Connection:" header, a 1.1 client supports keep-alive and a 1.0 does not.

[cbr]

Have you ever tried to browse the web without chunked transfer encoding? It's everywhere now.

[bodyfour]

Most well-behaved servers will only send chunked-encoding if the client claimed to be HTTP/1.1. If the client is HTTP/1.0 it will fall back to doing "Connection: close"

The only big thing chunked-encoding gives you is the ability to do a keep-alive connection when the server doesn't know the Content-Length in advance. (Technically it also added "trailers" for sending headers after the reply body, but that's little-used)

[charonn0]

> HTTP/1.0 is basically dead and has been for years

There are probably a lot more active HTTP/1.0 clients than you think. Just slap a `Host: foo.com` and `Connection: close` header onto the request and your HTTP/1.0 client can talk to just about any HTTP/1.1 server.

[calibwam]

So basically, while HTTP/2.0 could force TLS, the world could still be like it is today, with some pages running web servers with HTTP/1.1 without TLS?