2011-01-25 13 views
18

Abbiamo spesso alcuni problemi in termini di interoperabilità sul Web. Uno di questi problemi per i venditori di browser è l'intestazione HTTP Connection errata. Gli errori più comuni sono dati da queste due forme.Cneonction and nnCoection Intestazioni HTTP

nnCoection: 
Cneonction: 

ci sono stato un paio di articoli su questo, tra Fun with HTTP headers. Spesso sta accadendo per periodo, poi scompare. Sembra che alcuni di essi siano creati da load balancer come this example: NetScaler Appliance.

Conosci altre istanze di hardware o software che creano questi problemi?

Aggiornamento Ecco un esempio tra gli altri di un sito che non restituisce una buona intestazione HTTP Connection.

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 

aggiornamento 2011-01-26

Su Amazon forum su AWS, c'è un thread su nnCoection. Un commento dice:

Cordiali saluti, la ragione per cui sbaglia la parola connessione è così che internet check-sum (una semplice somma) aggiunge ancora up, in questo modo il cambiamento può verificarsi a livello di pacchetto . Se completamente rimosse l'intestazione, sarebbe lo stallo che inoltra la risposta fino a l'intestazione è stata interamente letta, quindi è possibile che riscriva le intestazioni, ricalcolo il checksum e quindi inviarlo insieme.

con

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

e

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

entrambi dà 1040

risposta

9

Sei sicuro che sia un vero e proprio problema ? L'articolo collegato suggerisce che questi tipi di intestazioni sono "errati di proposito" in modo che un bilanciamento del carico, un proxy inverso o un altro middlebox possano sconfiggere i desideri del server che la connessione venga mantenuta attiva, senza dover tenere traccia di un delta nella posizione del flusso TCP sul vita della connessione. Qualcosa di simile potrebbe essere effettivamente necessario per riportare in servizio attivo un server abbattuto e ripristinato, forzando le connessioni mantenute-vive ad altri server per migrare a quello portato online.

Se si dispone di un protocollo che dipende da HTTP Connection: keep-alive per funzionare (cough), probabilmente si sta facendo male.

+0

nel caso del bilanciatore del carico, esiste una seconda intestazione di connessione. ma ci sono molti casi in cui non viene inviato nient'altro. Modificherò il post per dare un esempio. – karlcow

+0

Sembra buono. Penso che questi siano errati dai load balancer TCP in modo che a) i client li ignorino eb) Non devono ricalcolare il checksum. Questo è un modo deliberato, anche se piuttosto hackish di farlo. L'ho visto prima in altri casi. – MarkR

+0

@ Markr Un buon punto sul checksum.Entrambi gli errori ortografici derivano dallo scambio di parole adiacenti a 16 bit e quale viene utilizzato dipende probabilmente dal fatto che C iniziale cada su un limite di parola; poiché TCP utilizza un checksum del complemento a un pezzo di parole a 16 bit, lo scambio di due parole a 16 bit non invaliderà il checksum. D'altra parte, probabilmente non vedrai simili imbrogli giocare con HTTPS. –

Problemi correlati