HTTP-заголовки Cneonction и nnCoection - PullRequest
18 голосов
/ 25 января 2011

У нас часто возникают некоторые проблемы с точки зрения взаимодействия в сети.Одной из таких проблем для поставщиков браузеров является неправильно записанный HTTP-заголовок Connection.Наиболее распространенные ошибки даются этими двумя формами.

nnCoection:
Cneonction:

Об этом было несколько статей, в том числе Fun с заголовками HTTP .Часто это происходит по периодам, а затем исчезают.Кажется, что некоторые из них создаются балансировщиками нагрузки, такими как этот пример : NetScaler Appliance.

Знаете ли вы какие-либо другие аппаратные или программные средства, которые создают эти проблемы?

Обновление Ниже приведен пример сайта, который не отправляет хороший заголовок Connection HTTP.

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

обновление 2011-01-26

На форуме Amazon о AWS существует тема о nnCoection.Комментарий гласит:

К вашему сведению, причина, по которой он неправильно вводит слово «соединение», состоит в том, что контрольная сумма в Интернете (простая сумма) все еще складывается, таким образом, изменение может происходить на уровне пакета.Если бы он полностью удалил заголовок, ему пришлось бы задержать пересылку ответа до тех пор, пока заголовок не был полностью прочитан, поэтому он мог бы перезаписать заголовки, пересчитать контрольную сумму и затем отправить ее вместе.

с

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

и

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

оба дают 1040

1 Ответ

9 голосов
/ 25 января 2011

Вы уверены, что это актуальная проблема ?Связанная статья предполагает, что эти типы заголовков «специально написаны с ошибками», так что балансировщик нагрузки, обратный прокси-сервер или другое промежуточное окно могут опровергнуть пожелания сервера о том, что соединение должно оставаться в живых, без необходимости отслеживания разницы в положении потока TCP наджизнь связи.Нечто подобное может фактически понадобиться для того, чтобы вернуть неисправный и восстановленный сервер в активное состояние, принудительно перенастраивая соединения с другими серверами для перехода на подключенный.

Если у вас есть протокол, который зависит отHTTP Connection: keep-alive для работы ( кашель ), вы, вероятно, делаете это неправильно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...