Verstehen der 304 Not Modified
Antwort im HTTP-Caching
Bei der Entwicklung von Webanwendungen ist eine effiziente Handhabung von Ressourcen entscheidend für die Leistung, insbesondere wenn es um den Dateizugriff und das Browser-Caching geht. Eine Möglichkeit, diesen Prozess zu optimieren, besteht darin, die 304 Not Modified
HTTP-Antwort korrekt zu nutzen. Diese Antwort informiert den Browser, dass die angeforderte Ressource seit dem letzten Abruf nicht geändert wurde, sodass der Browser die zwischengespeicherte Version weiterhin verwenden kann, anstatt sie erneut herunterzuladen. Aber wie wissen Sie, wann Sie diese Antwort senden sollten? Lassen Sie es uns Schritt für Schritt aufschlüsseln.
Wichtige HTTP-Header zur Überprüfung
Um zu bestimmen, ob eine 304 Not Modified
Antwort gesendet werden soll, müssen Sie bestimmte HTTP-Header überprüfen, die vom Browser des Clients gesendet werden. Die beiden wichtigsten Header, auf die Sie sich konzentrieren sollten, sind:
- Etag: Dieser Header dient als eindeutiger Identifikator für eine Ressource in einer bestimmten Version. Der Browser vergleicht sein zwischengespeichertes Etag mit dem Etag des Servers, um festzustellen, ob sie übereinstimmen.
- If-None-Match: Dieser Header wird vom Browser gesendet und enthält den zwischengespeicherten Etag-Wert. Wenn sich die Ressource nicht geändert hat, kann der Server mit
304
antworten.
Worauf man achten sollte
- Wenn das Etag vom Browser existiert: Wenn der Browser entweder die
Etag
oderIf-None-Match
Header in der Anfrage einschließt, bedeutet dies, dass er eine zuvor zwischengespeicherte Version der Ressource hat. - Zitationsüberlegungen: Browser setzen manchmal den Etag-Wert in Anführungszeichen. Stellen Sie sicher, dass Sie diese Anführungszeichen vor dem Vergleich entfernen.
Notwendige Header für die ursprüngliche Antwort
Beim anfänglichen Senden der Ressource (typischerweise mit einer 200 OK
Antwort) ist es wichtig, relevante Header einzufügen, die den Browser über den Zustand der Ressource informieren:
- Last-Modified: Gibt an, wann die Ressource zuletzt geändert wurde. Dies kann eine alternative Überprüfung zur Cache-Validierung neben Etag sein.
- Etag (wie zuvor erwähnt): Dieses sollte für die Ressource generiert und in den Antwortheadern enthalten sein, um zukünftige Cache-Validierungsanfragen zu erleichtern.
Implementierung der Logik
Hier ist ein vereinfachtes Pseudocode-Beispiel, das zeigt, wie die Logik zum Senden einer 304 Not Modified
Antwort implementiert werden kann:
server_etag = gen_etag_for_this_file(myfile)
etag_from_browser = get_header("Etag")
if etag_from_browser does not exist:
etag_from_browser = get_header("If-None-Match")
if the browser has quoted the etag:
strip the quotes (e.g. "foo" --> foo)
set server_etag into http header
if etag_from_browser matches server_etag
send 304 return code to browser
Beispiel für einen Serverlogik-Schnipsel
So könnten Sie dies in Ihrer Serverlogik implementieren:
/* der Client sollte entweder Etag oder If-None-Match setzen */
mketag(etag, &sb);
etagin = apr_table_get(r->headers_in, "Etag");
if (etagin == NULL)
etagin = apr_table_get(r->headers_in, "If-None-Match");
if (etag != NULL && etag[0] == '"') {
/* Anführungszeichen entfernen, falls vorhanden */
int sl;
sl = strlen(etag);
memmove(etag, etag+1, sl+1);
etag[sl-2] = 0;
}
apr_table_add(r->headers_out, "ETag", etag);
if (etagin != NULL && strcmp(etagin, etag) == 0) {
/* Wenn das etag übereinstimmt, geben Sie den Status 304 zurück */
rc = HTTP_NOT_MODIFIED;
}
Abschließende Gedanken
Indem Sie wissen, wie und wann Sie eine 304 Not Modified
Antwort senden, können Sie die Serverlast effektiv reduzieren und die Benutzererfahrung verbessern. Vergessen Sie nicht, die Bedeutung der Header Etag
und Last-Modified
während der ursprünglichen Antwort zu berücksichtigen, um dem Client zu ermöglichen, später genaue Cache-Validierungsanfragen zu stellen. Wenn Sie Fragen zur Etag-Generierung haben oder weitere Implementierungshilfe benötigen, zögern Sie nicht, sich für detailliertere Beispiele zu melden. Viel Spaß beim Programmieren!