Verbindungsabbrüche bei heise online durch Cookies – eine Spurensuche
Die Webentwicklung von heise online berichtet von einer interessanten Suche nach einem Bug, dessen Ursache am Ende ganz simpel war.
(Bild: Zakharchuk/Shutterstock.com)
In der Webentwicklung schreiben wir nicht nur neue Software, sondern es erreichen uns natürlich auch Fehlermeldungen. Meistens können wir schnell helfen oder den Bugfix auf jeden Fall für einen der nächsten Sprints einplanen. Aber manche Fehler sind hartnäckiger und haben am Ende eine ganz simple Ursache. Um solch einen Fehler geht es heute.
Eine Zeit lang erreichten uns immer mal wieder Berichte, dass bei Usern die Verbindung zu www.heise.de mit der Meldung ERR_HTTP2_PROTOCOL_ERROR nicht zustande kam. Schnell kristallisierte sich heraus, dass die betroffenen User noch ein paar Gemeinsamkeiten hatten: Alle nutzten Chrome als Browser und waren regelmäßige Besucher unseres Angebots. Damit war der Fehler zwar schon etwas eingegrenzt, aber unser größtes Problem war: Wir selbst konnten den Fehler lange Zeit nicht nachstellen.
Videos by heise
Viele Kekse
Die Überlegungen gingen dennoch weiter. Was sammeln User (leider heutzutage) zuhauf, wenn sie auf einem weitgehend werbefinanzierten Angebot wie heise online unterwegs sind? – Cookies. Ein Test mit betroffenen Usern sorgte dann immerhin für einen Workaround: Cookies löschen half.
Zunächst hatten wir die Cookie-Größe im Verdacht und testeten mit besonders großen Cookies, aber auch damit ließ sich das Problem für uns nicht reproduzieren. Doch dann meldete sich ein Kollege aus der Redaktion mit demselben Fehler – er bekam ihn sogar regelmäßig. Wir baten ihn um Hilfe bei der Lösung, und er gab Bescheid, sobald der Bug erneut auftrat. Endlich konnten wir das Problem direkt beobachten.
Mit tcpdump schnitten wir den Netzwerkverkehr zwischen uns und dem Browser auf dem Load-Balancer (BigIP) mit, der TLS und HTTP2 termininiert. Dabei stellte sich heraus, dass BigIP selbst die HTTP2-Verbindung wegen eines „Protokollfehlers“ beendete. Da heise online nicht einfach eine direkte Verbindung vom Browser des Users zu unserem Webserver hat, sondern noch diverse (Netzwerk-)Infrastruktur dazwischen liegt, war es für uns schon mal sehr hilfreich, den Punkt ausfindig zu machen, an dem die Verbindung bricht und welcher Teil in der Kette diesen Abbruch auslöst.
Blick in die Bug-Reports
Mit den gewonnenen Erkenntnissen durchforsteten wir die Chrome-Bug-Reports. Bei einem Report war ein HTTP2-Protokoll-Mitschnitt angefügt, bei dem wir sehen konnten, dass Chrome jeden Cookie im HTTP2-Request mit einem separaten Set-Cookie-Header sendete. Das brachte uns auf die Idee, statt der Cookie-Größe einfach mit der schieren Anzahl zu experimentieren, und siehe da: Mit sehr vielen, kleinen Cookies ließ sich das Problem reproduzieren.
Ab hier wurde es dann einfach. Mithilfe unserer Admins fanden wir eine Einstellung in der BigIP, die die maximal zulässige Anzahl der Header setzte. Dieses Limit verschoben wir nun deutlich nach oben und schon war das Problem gelöst. Jedenfalls fürs Erste, denn natürlich ist das neue höhere Limit mit noch mehr Cookie-Headern ebenfalls wieder erreichbar, und der Fehler käme zurück.
Am Fehler sind aber noch ein paar Dinge interessant. In HTTP/1.x waren mehrere Cookie-Header noch unzulässig (siehe RFC 6265), in HTTP/2 hingegen kann der User Agent jedes Cookie als einzelnen Header senden (siehe RFC 7540) und genau das hat Chrome hier getan. Dieses Verhalten ist offensichtlich eine Optimierung, denn das Übertragen sich wiederholender Header lässt sich in HTTP/2 mit der HPACK-Header-Komprimierung (siehe RFC 7541) enorm optimieren. Das funktioniert aber nur für Header, die sich nicht ständig ändern. Ein großer Cookie-Header für alle Cookies müsste also immer wieder komplett neu übertragen werden, sobald sich auch nur ein einzelnes Cookie ändert.
Chrome zeigte leider in den Developer-Tools nichts davon an. Dort wird immer nur ein Cookie-Header gelistet, was die Fehlersuche nicht unbedingt erleichtert hat.
Ob das nun eine Problemlösung oder lediglich ein großes Pflaster ist, wird die Zeit zeigen. Die Ursachenforschung war aber definitiv mal wieder eine der interessanteren Recherchen im Developer-Alltag.
(rme)