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

From: Zhong Yu <[email-masked]>
Date: Thu, 23 Feb 2012 10:32:39 -0600

When an HTTP/1.1 server accepts an HTTP/1.0 request, should the server
always close the connection after sending the response? That seems to
be the safest way. While the server could try to keep the connection
by checking for Connection: keep-alive, the spec suggests that it is
problematic. What's your recommended best practice for this issue?
Thanks.

Zhong

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Feb 2012 17:56:51 +0100

> problematic. What's your recommended best practice for this issue?

In haproxy we check for "Connection: keep-alive" in 1.0 and
"Connection: close" in 1.1 and I've never had any report of
unexpected behaviour by doing so. Also, I don't think there
is any need for recommending currently working implementations
to stop doing something that has been working fine for them,
because they will simply ignore the recommendation and tend
to consider the other ones with less care.

Regards,
Willy

---

From: Zhong Yu <[email-masked]>
Date: Thu, 23 Feb 2012 12:19:07 -0600

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.

On Thu, Feb 23, 2012 at 11:56 AM, Alvaro Lopez Ortega <[email-masked]> wrote:
> On 02/23/2012 05:56 PM, Willy Tarreau wrote:
>>
>> unexpected behaviour by doing so.
>
>
> Same thing for the Cherokee Web Server. I believe it's the behavior that
> most of the servers and proxies implement.
>
> All the best,
> Alvaro

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Feb 2012 18:27:42 +0000

>   not be used by clients at all when a proxy is being used.

Aren't these two different things that you're confusing?

Your original question was about how a HTTP/1.1 server should handle the presence of "Connection:" in a HTTP/1.0 request.

The text above is warning HTTP/1.0 clients that HTTP/1.0 proxies may not handle the presence of "Connection:" properly.

Ben

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Feb 2012 19:30:49 +0100

>    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.

Willy

---

From: Zhong Yu <[email-masked]>
Date: Thu, 23 Feb 2012 14:23:36 -0600

> want to implement it have to understand what it means. I think this is fine

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.

Zhong

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Feb 2012 21:33:15 +0100

> "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.

Regards,
Willy

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 21:36:09 +0100

>    that header to the next inbound server, which would result in a hung

This part is indeed obsolete today. The number of currently deployed
HTTP/1.0 proxies not knowing about Connection is very limited.

>    not be used by clients at all when a proxy is being used.

I would think this is obsolete as well for the same reason as above.

I have not heard of any reports indicating any problems in these areas
for many many years (10+ I think). It may have been a problem at the
time RFC2616 was written, but at least I have no evidence at all that
these are seen as problems today.

It's also worth noting that the use of HTTP/1.0 is declining a lot,
making this pretty much a non-issue. And most of the remainign HTTP/1.0
agents which is likely to stick around for some significant time do not
send keep-alive.

Regards
Henrik