2017-12-30 7 views
0

Ich weiß, dass Browser RST_STREAM-frames senden können, um serverpush abzubrechen.Prüft der Browser bedingte Header in PUSH_PROMISE-Frames?

Macht es Sinn, oder Etag Header innerhalb der PUSH_PROMISE zu senden? Oder ist die Validierung der to-be-pushed Ressourcen nur auf ihre URI (wie Simone Bordet auf die folgende Frage vor zwei Jahren beantwortet)?

Does the browser cancel server push when a resource is in cache?

konnte ich keine genaue Antwort auf diese Frage finden.

Antwort

0

Wenn ein HTTP/2-Server eine Ressource schiebt, generiert er den PUSH_PROMISE Frame, der an den Client gesendet wird, und erstellt gleichzeitig eine synthetische Anfrage, die so verarbeitet wird, als ob der Remote-Client sie gesendet hätte.

Denken Sie daran, dass der PUSH_PROMISE Rahmen die Anfrage darstellt, die der Client für diese Ressource erstellen würde, nicht die Antwort.

Der Inhalt der Frame-Header PUSH_PROMISE und die Header der synthetischen Anfrage sind normalerweise gleich, aber - je nach Implementierung - kann dies nicht der Fall sein.

Header oder ETag nur in Antworten sinnvoll, so dass es nicht sinnvoll wäre, sie zu einem PUSH_PROMISE Frame hinzuzufügen.

Ob es sinnvoll ist hinzuzufügen andere Anfrage Header wie If-Modified-Since zum PUSH_PROMISE davon ab, ob die gleichen Header für die synthetische Anforderung verwendet werden. Wenn die gleichen Header verwendet werden, wie dies normalerweise der Fall ist, hat das Hinzufügen von Headern wie If-Modified-Since nur Auswirkungen auf die serverseitige Verarbeitung: Der Server kann beim Verarbeiten der synthetischen Anfrage einen 304 Not Modified generieren.

Es wäre jedoch seltsam für einen Server, eine PUSH_PROMISE für eine Ressource zu senden, gefolgt von einer 304. Wenn der Server weiß, dass der Client die Ressource bereits zwischengespeichert hat, kann er auch das Senden der PUSH_PROMISE überspringen.

Hinzufügen Antwort Header wie Last-Modified zu einem PUSH_PROMISE Rahmen macht keinen Sinn, weil ein PUSH_PROMISE eine Anforderung darstellt.

Hinzufügen bedingte Anfrage Header wie If-Modified-Since erfordert normalerweise den Server einige Kenntnisse über welche Ressourcen für die Kunden vorher bedient wurden haben: es, ob eine Ressource bereits serviert wurde wissen hat, so dass ein 304 an den Client gesendet Bei einer gedrückten Ressource wird der Client die bereits in seinem Cache vorhandene Ressource verwenden.

+0

Ok, es gibt also nichts innerhalb des 'PUSH_PROMISE' (außer dem URI der Datei), das dem Browser helfen kann, zu entscheiden, ob er einen Push akzeptieren oder abbrechen will? –

0

Nach tiefer Suche Ich glaube, ich die Antwort gefunden:

Die pushBuilder's Api sagt .lastModified():

das Datum der letzten Änderung für die bedingte Schübe verwendet werden Set.

und .etag():

ETAG Set für bedingte Schübe verwendet werden.

ich diese Erklärungen falsch verstanden und dachte, sind die angegebenen Werte innerhalb der PUSH_PROMISE an den Browser gesendet, es zu helfen, zu entscheiden, ob die Datei gedrückt akzeptieren oder den Strom zu stornieren (durch RST_STREAM Senden).

In der Tat scheinen diese Werte den Server zu sagen, wenn es etw. oder nicht. Indem ich die Datei last-modified-date als .lastModified() gesetzt habe, habe ich das Verhalten Simone Bordet in seinem Kommentar oben beschrieben: Ein 304 wurde gesendet, auch wenn die Datei nicht in meinem Cache vorhanden war.

Jetzt ist es völlig klar, dass es keinen Sinn macht, diese Werte festzulegen, ohne genau zu wissen, was im Cache eines Clients ist.

So etwas wie bedingte Header in einem PUSH_PROMISE scheinen jetzt nicht zu existieren: ich nicht in Chrome Ausgabe-tracker, dass etwas über in den HTTP2-Spezifikationen und beim Lesen, fand ich Tom Bergan kommentieren diese auf einer offenen fanden (2017.01.02) Ausgabe (https://bugs.chromium.org/p/chromium/issues/detail?id=232040#c62):

... ich glaube, ein besserer Weg, um diesen Fall zu behandeln ist, die gedrückte Antwort auf ein 304 umzuwandeln, wenn die gedrückte Antwort die zwischengespeicherte Ressource entspricht. Es gibt zwei mögliche Implementierungen:

  1. nicht abbrechen die Push erst nach der gedrückten Response-Header empfangen (da die Response-Header enthalten ETag und/oder Last-Modified). Wenn die gedrückte Ressource bereits zwischengespeichert ist, würde der Browser die gedrückte Antwort in eine 304 umwandeln und den Push abbrechen. Allerdings wartet IMO zu lange, um den Push abzubrechen.

  2. Fügen Sie bedingte Header wie If-Match zum PUSH_PROMISE hinzu, damit der Browser genau weiß, welche Ressource übertragen wird. Dies ist eine gute Idee, aber es müsste erst spezifiziert werden, bevor wir es implementieren können. https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0522.html ...

Also, was ich möglich zu erwarten (der Browser helfen, in der PUSH_PROMISE gesendet einer zwischengespeicherten Ressource Gültigkeit zu überprüfen, indem Sie einige Kopf Auslesen von Informationen) ist jetzt nicht möglich, aber wird es sein. Außerdem scheint es, dass cache-digest in Browsern in der Zukunft implementiert wird, was noch effektiver sein wird, weil unnötige Pushs auf dem Server vermieden werden können. Chrome arbeitet bereits daran, wie hier zu sehen ist: https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit#

Bitte korrigieren Sie mich, wenn ich etwas falsches gesagt habe.