3 ms·
This is wrong. HTTP/1.0 had a keep-alive header field as mentioned in the HTTP/1.1 RFC: https://tools.ietf.org/html/rfc7230#appendix-A.1.2 https://tools.ietf.or
by brabel 6y ago
This is wrong. HTTP/1.0 had a keep-alive header field as mentioned in the HTTP/1.1 RFC: https://tools.ietf.org/html/rfc7230#appendix-A.1.2 https://tools.ietf.org/html/rfc7230#appendix-A.1.2
But in HTTP/1.1 that's the default: https://tools.ietf.org/html/rfc7230#section-6.3 https://tools.ietf.org/html/rfc7230#section-6.3
o If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,
o If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, the recipient is not a proxy, and the recipient
wishes to honor the HTTP/1.0 "keep-alive" mechanism
- psturgeon 6y agoDid you read the link you shared? 19.7.1 Compatibility with HTTP/1.0 Persistent Connections Some clients and servers may wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 clients and servers. Persistent connections in HTTP/1.0 must be explicitly negotiated as they are not the default behavior. HTTP/1.0 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies.