RFC2616 refers to RFC2068 for HTTP/1.0-style persistent connections,
which is the most normative source we have for this.
http://rfc.net/rfc2068.html#s19.7.1
The way that that's written leads me to believe that a HTTP/1.1
client can send a request to a HTTP/1.0 server and expect the
resulting connection to be persistent, as long as it has a Content-
Length.
However, since this is a spec interpretation issue, I might take it
up with the folks over at HTTP-WG.
Cheers,
On 2006/09/20, at 5:55 AM, Henrik Nordstrom wrote:
Except that HTTP/1.1 doesn't define "Connection: keep-alive", only
"Connection: close". The keep-alive of an HTTP/1.1 connection is
implicit by the protocol being HTTP/1.1.
"Connection: keep-alive" is keep-alive of a HTTP/1.0+ style persistent
web server connection. HTTP/1.0+ defines different signaling for web
servers and proxies due to Connection not being an HTTP/1.0 header
making it likely proxies does not understand Connection: keep-
alive.. A
client accepting "Connection: keep-alive" as keep-alive of a proxied
connection is broken not respecting the Netscape specifications for
keep-alive for HTTP/1.0.
Regards
Henrik
--
Mark Nottingham
[EMAIL PROTECTED]
