W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: HTTP/1.0 request - should the server close the connection after response?

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 23 Feb 2012 21:33:15 +0100
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: Alvaro Lopez Ortega <alvaro@alobbs.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20120223203315.GR29928@1wt.eu>
On Thu, Feb 23, 2012 at 02:23:36PM -0600, Zhong Yu wrote:
> On Thu, Feb 23, 2012 at 12:30 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Thu, Feb 23, 2012 at 12:19:07PM -0600, Zhong Yu wrote:
> >> Thank you both. So, "Connection:keep-alive" in 1.0 is very dependable
> >> in practice, server should keep the connection alive.
> >>
> >> If that's the case, shouldn't we remove the alarming languages in
> >> [part 1, A.1.2.]? They might be legitimate concerns in 1999, but no
> >> longer relevant today.
> >>
> >>    However, some experimental implementations of HTTP/1.0
> >>    persistent connections are faulty; for example, if a HTTP/1.0 proxy
> >>    server doesn't understand Connection, it will erroneously forward
> >>    that header to the next inbound server, which would result in a hung
> >>    connection.
> >>
> >>    ...
> >>
> >>    Clients are also encouraged to consider the use of Connection: keep-
> >>    alive in requests carefully; while they can enable persistent
> >>    connections with HTTP/1.0 servers, clients using them need will need
> >>    to monitor the connection for "hung" requests (which indicate that
> >>    the client ought stop sending the header), and this mechanism ought
> >>    not be used by clients at all when a proxy is being used.
> >
> > Indeed I remember about those painful days. However, the paragraph above
> > simply encourages to use the feature with care. This means that those who
> > want to implement it have to understand what it means. I think this is fine
> > as is.
> If the spec specifically mentions a type of flaw in intermediaries, it
> wouldn't be "just saying"; it means the flaw is realistic, having
> significant impact in real world, and implementer should reckon with
> it.
> Therefore I cannot, by reading the spec alone, come to the conclusion
> that a server should honor "Connection:keep-alive" from a 1.0 request.
> If servers do honor the header, it means the flaw doesn't matter to
> servers anyway, therefore there's no point mentioning the flaw in the
> spec.
> The added (not in rfc2616) last paragraph about clients seems to be a
> logical deduction from the significance of the flaw; however if the
> flaw is not really significant (servers ignore it), this paragraph is
> not justified. The real judges would be respectful client
> implementers; if they never see any problem sending
> "Connection:keep-alive", the paragraph can be removed.

The last one was added in an attempt to stop user-agents from emitting
Proxy-Connection headers and to only use the Connection header. What is
said here is that some 1.0 proxies were known to be broken when dealing
with 1.0 + connection: keep-alive so it encourages 1.0 clients no to do
so. However, a number of 1.0 clients do not pass through proxies (eg:
server monitoring, automatic download of updates, etc...) and are not
really subject to the issue and/or are not interested in keep-alive.
The end result is that if a server receives a 1.0 + keep-alive, it's
probably good as long as we incite clients to avoid doing that when they
don't know if it can work or if they don't find a real value in doing it.

Received on Thursday, 23 February 2012 20:33:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:27 UTC