Comprendre la réponse 304 Not Modified dans le caching HTTP

Lors du développement d’applications web, la gestion efficace des ressources est cruciale pour les performances, notamment en ce qui concerne l’accès aux fichiers et le caching des navigateurs. Une des façons d’optimiser ce processus est d’utiliser correctement la réponse HTTP 304 Not Modified. Cette réponse informe le navigateur que la ressource qu’il a demandée n’a pas changé depuis sa dernière récupération, permettant ainsi au navigateur de continuer à utiliser sa version en cache plutôt que de la télécharger à nouveau. Mais comment savoir quand envoyer cette réponse ? Décomposons cela étape par étape.

En-têtes HTTP Clés à Vérifier

Pour déterminer s’il faut envoyer une réponse 304 Not Modified, vous devez vérifier des en-têtes HTTP spécifiques envoyés par le navigateur du client. Les deux principaux en-têtes sur lesquels se concentrer sont :

1. Etag : Cet en-tête sert d’identifiant unique pour une ressource à une version spécifique. Le navigateur compare son Etag en cache avec l’Etag du serveur pour voir s’ils correspondent.
2. If-None-Match : Cet en-tête est envoyé par le navigateur et contient la valeur Etag en cache. Si la ressource n’a pas changé, le serveur peut répondre avec 304.

Ce qu’il Faut Rechercher

• Si l’Etag du navigateur existe : Si le navigateur inclut soit les en-têtes Etag ou If-None-Match dans la requête, cela indique qu’il a une version précédemment mise en cache de la ressource.
• Considérations de citations : Les navigateurs citent parfois la valeur de l’Etag. Assurez-vous de supprimer ces guillemets avant la comparaison.

En-têtes Nécessaires pour la Réponse Initiale

Lors de l’envoi initial de la ressource (généralement avec une réponse 200 OK), il est essentiel d’inclure des en-têtes pertinents qui informent le navigateur sur l’état de la ressource :

• Last-Modified : Indique la dernière fois que la ressource a été modifiée. Cela peut être une vérification alternative pour la validation du cache aux côtés de l’Etag.
• Etag (comme mentionné précédemment) : Cela devrait être généré pour la ressource et inclus dans les en-têtes de réponse pour faciliter la validation future du cache.

Mise en Œuvre de la Logique

Voici un exemple simplifié en pseudocode qui démontre comment mettre en œuvre la logique pour envoyer une réponse 304 Not Modified :

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

Extrait de Logique Serveur d’Exemple

Voici comment vous pourriez implémenter cela dans la logique de votre serveur :

/* le client doit définir soit Etag soit If-None-Match */
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] == '"') {
    /* Supprimer les guillemets s'ils sont présents */
    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) {
    /* Si l'etag correspond, retourner un statut 304 */
    rc = HTTP_NOT_MODIFIED;
}

Pensées Finales

En sachant comment et quand envoyer une réponse 304 Not Modified, vous pouvez réduire efficacement la charge du serveur et améliorer l’expérience utilisateur. N’oubliez pas l’importance d’inclure les en-têtes Etag et Last-Modified lors de la réponse initiale pour permettre au client de faire des requêtes précises de validation de cache par la suite. Si vous avez des questions sur la génération de l’Etag ou si vous avez besoin d’aide supplémentaire pour l’implémentation, n’hésitez pas à demander des exemples plus détaillés. Bon codage !