ons 2006-09-20 klockan 09:52 -0700 skrev Mark Nottingham: > 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 which doesn't define persistent proxy connections at all, other than a "MUST NOT" which doesn't make anyone much happier.. (and which nobody follows anyway). > 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. Not really. From that same section: An HTTP/1.0 server would then respond with the Keep-Alive connection token and the client may proceed with an HTTP/1.0 (or Keep-Alive) persistent connection. But it's true that we probably could assume a HTTP/1.1 message is persistent unless it has a connection: close tag as the close tag is required by HTTP/1.1. But at the same time RFC 2616 8.1.2.1 says: Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See section 19.6.2 for more information on backward compatibility with HTTP/1.0 clients. 8.1.3 says A proxy server MUST NOT establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 [33] for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients). and 19.6.2 says: response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies. The only document I know of which defines persistent HTTP/1.0 proxy connections is the original Netscape document, defining the Proxy-Connection header and why it is needed.. The validity of the reasoning behind Proxy-Connection can be debated as the solution isn't safe at all (fails in hierarchies), but at least it solved the client migration path while there existed dumb HTTP/1.0 proxies without persistent connections. > However, since this is a spec interpretation issue, I might take it > up with the folks over at HTTP-WG. You are welcome. But I don't really see much value to stir up discussions around HTTP/1.0 persistent connections, they work the ways they do and can not be changed, only documented (was a dead end). For proxy connections it's signaled using Proxy-Connection: keep-alive, for origin server connections using Connection: keep-alive, the difference is there to sort of work around old HTTP/1.0 proxies not knowing about keep-alive. A HTTP server/proxy can not assume a HTTP/1.0 client knows about HTTP/1.1 so keep-alive must be signaled in the same manner in the response as well, and similarly it cannot be blindly assumed a HTTP/1.1 client knows about HTTP/1.0 persistent connections. The only specifications available actually defining persistent proxy connections (the Netscape specifications) defines the Proxy-Connection header for the purpose. This was not taken up in the official specifications as it can not be guaranteed the negotiation works in all configurations. The most significant blank spot is how HTTP/1.0 proxies knowing about persistent connections should react to HTTP/1.1 clients not explicitly signaling persistent connections. Here we choose take the safe path and assumes the client doesn't know about HTTP/1.0 persistent connections and close the connection. Unfortunately I have no idea where to find that Netscape document today after all their restructuring. Maybe in the Internet Archive? Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
