Ich habe einen Webdienst, der eine ETag auf jede Antwort setzt, so dass zukünftige Anrufe den Status HTTP 304 (Not Modified) verwenden können. Den ETag erzeuge ich eigentlich nur eine Base64-Codierung des Abfragetyps zusammen mit dem Zeitstempel.ETag mit Accept-Language
Das Problem, das ich habe, ist, wenn der Browser die gleiche Ressource mit einem Unterschied Accept-Language anfordert. Der Browser sendet derzeit den gleichen If-None-Match-Header, also ist die Antwort ein 304, selbst wenn die tatsächliche Ressource in einer anderen Sprache zurückgekommen wäre. Also dachte ich, der Weg wäre, einen Vary-Header hinzuzufügen, um dem Client mitzuteilen, dass die Antwort mit Accept & Accept-Language, wie unten gezeigt, variiert.
Vary: Accept, Accept-Language
aber mein Browser (Chrome) unabhängig den gleichen ETag verwendet die accept-Sprache. Was ist die richtige Konvention hier zu verwenden?
Dank
Dies scheint ein bisschen schwach zu mir, ich kann in den ETag den tatsächlichen Inhalt kodieren, aber wenn der Client versucht, den gleichen ETag für die gleiche Ressource in einer anderen Sprache (fr) zu verwenden, muss ich einfach einen zuweisen neues ETag für fr. Wenn der Client nun denselben Inhalt erneut in der Originalsprache abfragt, wird sein fr ETag ignoriert und ein neuer ETag übergeben, so dass er 304 nicht verwendet. Diese Caching-Lösung scheint schwach zu sein, da sie in einem existiert spezifischer Header, um diesen Anwendungsfall (VARY) zu lösen, der den Client darüber informiert, welche http-Header den Ausgabeinhalt beeinflussen werden. – Agent96