Analizi HTTP Connection-kapojn kiel komo-disigitajn ĵetonojn
Analizu ĉiun uskleman Connection-opcion kiam antaŭa prokurilo renkontas keep-alive kaj Upgrade en la sama HTTP/1.1-kampo.
Ĉi tiuj valoroj ne estas konkurantaj literumoj de unu sola reĝimo:
Connection: Upgrade
Connection: keep-alive, UpgradeLa dua listigas du konektajn opciojn. HTTP difinas Connection kiel komo-disigitan liston, kun opci-nomoj ne distingantaj usklecon. Kodo, kiu komparas la tutan valoron kun la ĝusta signoĉeno Upgrade, maltrafas validan liston enhavantan tiun opcion.
Por ordinara plusendado, HTTP-peranto analizas la envenantan kampon, forigas kampojn nomitajn de ĝiaj opcioj, poste forigas Connection mem aŭ anstataŭigas ĝin per la propraj regaj opcioj de la peranto por la plua konekto.
Forigi nur firme koditan kampon Keep-Alive ne sufiĉas. Mesaĝo povas nomi alian konekto-specifan kampon en la listo, kaj tiu kampo ne rajtas liki en ordinaran plusendadon.
Subteni protokolan ĝisdatigon postulas konscian traktadon de la du konektoj kaj la nova protokolo. Blinde kopii la envenantajn Upgrade-kapojn ne estas efektivigo de tiu transdono.
Kiam unu retumilo funkcias kaj alia malsukcesas, komparu la efektivajn kampovalorojn ambaŭflanke de la peranto. Diferenco inter unu ĵetono kaj listo de du ĵetonoj povas malkaŝi analizan eraron sen postuli, ke la retumilo imitu la precizan aranĝon de alia retumilo.
Ĉi tio koncernas la HTTP-mesaĝojn, kiujn la prokurilo analizas. Ordinara HTTPS CONNECT-tunelo ne elmontras la Connection-kampon de la ĉifrita retejo al tiu prokurilo.