Viele Bibliotheken enthalten standardmäßig Expect: 100-continue für alle HTTP 1.1 POST- und PUT-Anfragen.
Ich beabsichtige, die wahrgenommene Latenz zu verringern, indem ich den Mechanismus 100-continue auf der Client-Seite bei Anfragen entferne, für die ich weiß, dass die Kosten für das Senden von Daten geringer sind als ein Roundtrip für 100-continue, nämlich bei kurzen Anfragen / p>
Natürlich möchte ich immer noch all die anderen großartigen Funktionen von HTTP 1.1, also will ich nur Expect: 100-continue header beenden. Ich habe zwei Möglichkeiten:
Expect:\r\n
Gibt es jemals einen Unterschied zwischen den beiden?
Irgendwelche Software, die für die eine oder andere brechen könnte?
Nichts sollte brechen, wenn Sie den Header Expect entfernen, aber ich weiß, dass Microsoft IIS in der Vergangenheit Probleme mit 100 Continue hatte. Beispiel: IIS5 sendet immer 100 fortlaufende Antworten . Also, ich frage mich, ob zumindest ein Teil davon in Bibliotheken verwendet werden könnte, um ähnlich gebrochenes Verhalten auf Servern zu umgehen.
Viele Bibliotheken scheinen diesen Header zu setzen und behandeln dann 100 Continue nicht richtig - z. Sie beginnen, den Anfragetext sofort zu senden, ohne auf 100 Continue zu warten, und behandeln dann nicht die Tatsache, dass der Server einen HTTP-Fehlercode zurücksendet, bevor er den Anfragetext gesendet hat (der erste Teil ist OK, es ist der zweiter Teil, der gebrochen ist - siehe später in meiner Antwort). Das führt mich zu der Annahme, dass einige Autoren es von anderen Stellen kopiert haben, ohne die
Ich kann keinen Grund sehen, eine leere Expect -Header einzufügen - wenn Sie 100-continue (oder eine andere Expect -Klausel) nicht einschließen, dann lassen Sie die Überschrift vollständig weg. Der einzige Grund, dies zu tun, wäre die Arbeit mit kaputten Webservern, aber mir sind keine bekannt, die sich so verhalten.
Schließlich, wenn Sie nur Roundtrip-Latenzen reduzieren möchten, scheint es mir, dass es nicht inkonsistent mit dem RFC sein würde, um einfach zu beginnen, den Anfragetext sofort zu übertragen. Sie sollten nicht unbegrenzt warten, um den Anfragetext zu senden (gemäß dem RFC ), so verhalten Sie sich entsprechend der Spezifikation - es ist nur Ihre Zeitüberschreitung, bevor das Senden überhaupt null ist.
Sie müssen sich darüber im Klaren sein, dass es Servern freisteht, die 100 Continue -Antwort nicht zu senden, wenn sie bereits einen Teil des Anfragetextes erhalten haben. Sie müssen also Server bedienen, die 100 Continue senden, die nichts senden und warten für die vollständige Anfrage und solche, die sofort einen HTTP-Fehlercode senden (der 417 sein kann, aber eher ein generischer 4xx-Code). Auf diese Weise sollten Ihre kurzen Anfragen keinen Overhead haben (abgesehen von der Kopfzeile Expect ), aber Sie müssen nicht auf 100 Continue warten. Damit dieser Ansatz funktioniert, müssen Sie natürlich so vorgehen, dass Sie die Anforderung unterbrechen können, sobald der Server einen Fehlercode zurückgibt (z. B. nicht blockierende E / A mit poll() oder select() ).
Wenn Sie auf diese Weise vorgehen, kann der Code zwischen kleinen und großen Anfragen konsistenter sein, während die Latenz reduziert wird. Der Nachteil ist, dass es vielleicht nicht das ist, was die RFC-Autoren im Sinn hatten, auch wenn es nicht explizit gegen eine der Anforderungen verstößt. Außerdem könnte es Ihren späteren Code komplizierter machen, wenn Sie nicht bereits nicht blockierende IO oder ähnliches machen.
Tags und Links ajax web httpserver http-1.1 http-status-code-100