Cneonction and nnCoection HTTP headers

Question

We have often some issues in terms of interoperability on the Web. One of these issues for browsers vendors is the wrongly spelled Connection HTTP header. The most common errors are given by these two forms.

nnCoection:
Cneonction:

There are has been a few articles about this, including Fun with HTTP headers. Often it is happening by period, then disappear. It seems that some of them are created by load balancers such as this example: NetScaler Appliance.

Do you know any other instances of hardware or software that create these issues?

Update Here an example among others of a site which doesn't send back a good Connection HTTP header.

curl -sI ehg-nokiafin.hitbox.com
HTTP/1.1 200 OK
Date: Tue, 25 Jan 2011 20:35:45 GMT
Server: Hitbox Gateway 9.3.6-rc1
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP LAW NID PSA ADM OUR IND NAV COM"
Cneonction: close
Pragma: no-cache
Cache-Control: max-age=0, private, proxy-revalidate
Expires: Tue, 25 Jan 2011 20:35:46 GMT
Content-Type: text/plain
Content-Length: 23

update 2011-01-26

On Amazon forum about AWS, there is a thread about nnCoection. A comment says:

FYI, the reason it misspells the word connection is so that the internet check-sum (a simple sum) still adds up, this way the change can occur at the packet level. If it completely removed the header, it would have to stall forwarding the response until the header was entirely read, so it could rewrite the headers, recompute the checksum and then send it along.

with

sum(ord(c) for c in "Connection")

and

sum(ord(c) for c in "nnCoection")

both gives 1040

Answer 1

Are you sure it's an actual issue? The linked article suggests that these sorts of headers are "misspelled on purpose" so that a load balancer, reverse proxy or other middlebox can defeat the server's wishes that the connection be kept alive, without having to track a delta in TCP stream position over the life of the connection. Something like this may actually be necessary to bring a downed and recovered server back into active duty, by forcing kept-alive connections to other servers to migrate to the one brought online.

If you have a protocol that's dependent on HTTP Connection: keep-alive to function (cough), you're probably doing it wrong.