Wann Pipelining Sinn ergibt, ist, wenn man viel statischen Content auf einer Seite hat und damit die Verbindungslatenz zwischen Anfrage im Browser und erstem möglichem Zeitpunkt wesentlich länger sein würde als es für den Server braucht, die Daten bereitzustellen. Extrembeispiel ist hier ein Caching Server, der nur statischen Content driekt aus dem Arbeitsspeicher fischt und sofort zurücksendet. Latenz wäre hier die reine Netzwerk-Latenz in Größenordnung eines Pings auf diesen Rechner. Wenn man hier bereits mehrere Anfragen in einer Verbindung sendet (ohne neuen Verbindungsaufbau), ergibt sich eine mögliche Antwortzeit nur knapp oberhalb der Netzwerk-Latenz (für meinen Server also etwa ~50ms).
Anders sieht der Fall aber mit Seiten aus, die durch Scripte im Hintergrund erzeugt werden (Beispielsweise die Seite des DF). Hier kann es vorkommen, dass die Netzwerk-Latenz gegenüber der Zeit zum Erzeugen und Ausliefern der Seite vernachlässigbar ist (PHP ist nicht das Schnellste). Hier bringt Pipelining zwar auch Vorteile, da die Latenzen für den Verbindungsauf- und -abbau nicht anfallen, die Einsparung ist aber prozentual geringer.
Problem ist nun, dass einige ältere Proxy-Software, die immer noch zum Einsatz kommt, manchmal nicht korrekt mit den hinter dem Pipelining stehenden RFCs zurande kommt und daher zu Fehlverhalten in Browsern oder anderer Clientsoftware führt. Und wenn etwas nicht geht, dann bringt es auch nichts, wenn es schneller nicht geht
P.S.: Dass die Mozilla-Leute manchmal einen an der Klatsche haben, steht aber auf einem anderen Blatt. Da werden auch gerne einmal Änderungen zum Erhöhen der Browsersicherheit abgelehnt, weil es den Normalnutzer verwirren könnte (oder andere haarsträubende Begründungen).
Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
.
