

The reason behind the "nnCoection" HTTP header - there
https://forums.aws.amazon.com/message.jspa?messageID=81954

======
jgrahamc
There has to be more processing done than the simple 'it adds up' explanation
because of a number of problems.

1\. The TCP checksum is a 16-bit checksum so you can't simply permute the
characters in Connection and always expect to get the same answer.

2\. The position at which Connection starts may not be on a 16 bit boundary
and thus the permutation would have to take into account this positioning.

3\. The header could be split across packets making this much harder.

In the example given nnCoection makes sense because the 16-bit words nn and Co
have been swapped which will not alter the checksum as long as Connection was
starting on a 16-bit boundary.

~~~
mcosta
1) False, CRC does not detect byte shuffling

2) TCP is a byte oriented protocol, so there is no endian or word boundary
problems.

3) Nothing is going to split a IP package between the backend servers and and
the frontend balancer, where the later sees the "Connection". If something
between the balancer and the client splits, it is its problem to recompute the
new CRC

~~~
jgrahamc
TCP doesn't use a CRC, it uses the algorithm described in RFC 1071
(<http://www.ietf.org/rfc/rfc1071.txt>) which relies on ones-complement
summing of 16-bit word values. Thus the position at which Connection appears
does matter, as does the swapping of characters.

------
piotrSikora
Those "misspelled" Connection headers (nnCoection, Cneonction, X-Cnection,
etc) are used by load balancers (Citrix NetScaler, F5 BIG-IP, etc).

IMHO better explanation is available here: [http://support.f5.com/kb/en-
us/solutions/public/6000/900/sol...](http://support.f5.com/kb/en-
us/solutions/public/6000/900/sol6997.html)

~~~
akshat
I work for Citrix Netscaler, and can confirm this. It is the most efficient of
invalidating one of the standard headers.

------
jrockway
I really love these abuses of TCP. Over the weekend I setup my router to do
TCP proxying, and I noticed that a lot of sites do not emit valid TCP streams
(making them inaccessible to machines behind the router). Metafilter, in
particular, emits a valid stream if the page is not cached (like submitting an
article), but it's hit or miss if the page is cached.

Presumably this is because the load balancer hijacks the raw TCP connection,
but is not smart enough to use valid sequence numbers:

<http://readlist.com/lists/openbsd.org/misc/9/45511.html>

The side effect of the Internet violating the TCP standard is that TCP becomes
a lot less resistant to man-in-the-middle attacks. And, my firewall has to
deal with various strange things, like packets in the middle of a TCP stream
that have a TTL such that they don't get routed, but do affect the firewall's
state table. But hey, at least your load balancer doesn't have to establish
_two_ TCP connections! Imagine the latency that would introduce!

~~~
calloc
This is actually really annoying. The same thing happens with isohunt.com, at
least, if I disable the scrub feature of my PF firewall I can get to
isohunt.com, if I enable the scrub feature I can no longer get to isohunt.

Now, like you mentioned there seem to be quite a few sites that are doing
this. It irks me that this abuse of TCP/IP happens which makes it harder to
write proper firewalling software and rules.

~~~
jrockway
Yeah. I wish people would use UDP instead of misusing TCP.

Yes, the three-way-handshake involves an extra round-trip. Yes, ACKs introduce
latency. So don't use TCP. :)

