W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

WGLC p1: Persistence & 1.1 proxies

From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Mon, 29 Apr 2013 20:25:13 +0100
Message-Id: <2A3A6799-CC6A-4214-B317-C9F3A150D0E9@niven-jenkins.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>

Section 6.3 of p1 states:

   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, the
      connection will persist after the current response; otherwise,

and then later on in the same section states:

   A proxy server MUST NOT maintain a persistent connection with an
   HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
   discussion of the problems with the Keep-Alive header field
   implemented by many HTTP/1.0 clients).

It is not clear that the solution proposed actually solves the issue at hand.

AIUI Section 19.7.1 of RFC2068 describes a case where persistent connections can break between HTTP/1.0 clients & servers if there is a HTTP/1.0 proxy in the middle that does not support persistent connections.

The solution in p1 (according to the text quoted above) is for a HTTP/1.1 proxy not to maintain persistent connections with HTTP/1.0 clients but I don't see how that solves the issue referred to by reference to 2068 (HTTP/1.0 proxy that doesn't support persistence between two HTTP/1.0 implementations that do breaks persistence) or why proxies are called out for special attention as the same issue appears to affect HTTP/1.1 servers talking to HTTP/1.0 client, no?

It would appear that either:
- The advice for proxies not to maintain persistent connections with HTTP/1.0 clients is correct but the justification for it (19.7.1 of RFC2068) is wrong/not relevant.
- The problem trying to be solved is that described in 19.7.1 of RFC2068 but the advice for alleviating the issue doesn't in fact alleviate it.

Received on Monday, 29 April 2013 19:25:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC