Corrigez-moi si je me trompe, et je sais que c'est un vieux post - mais je voudrais commenter pour les nouveaux passants. Je crois qu'un cache de proxy inverse n'aide pas autant que vous le souhaitez lorsque vous utilisez ETags.
Les mécanismes de mise en cache de validation utilisent le serveur d'origine pour valider si l'ETag (ou la date de dernière modification) dans la demande est toujours valide (correspond ou ne correspond pas à l'étag des ressources, selon l'en-tête utilisé, ou n'a / n'a pas été modifié) depuis la date indiquée dans la demande).
Cela signifie qu'un cache de proxy inverse tel que Varnish transmettra toujours cette demande au serveur d'origine. Il peut répondre avec la demande plutôt que de le gérer, mais vous n'avez pas enregistré l'aller-retour sur le serveur d'origine.
Les navigateurs peuvent mettre en cache les réponses et gérer une réponse 304 dans tous les cas, donc le cache privé de l'utilisateur peut être mieux adapté pour gérer cela que d'utiliser un proxy inverse (YMMV, en particulier à grande échelle, et en fonction de votre cas d'utilisation, bien sûr. Je ne le fais pas voulez faire des hypothèses sur vos applications).
De la spécification 13.3 :
Lorsqu'un cache a une entrée périmée qu'il souhaite utiliser comme réponse à la demande d'un client, il doit d'abord vérifier avec le serveur d'origine (ou éventuellement un cache intermédiaire avec une nouvelle réponse) pour voir si son entrée en cache est toujours utilisable . Nous appelons cela "valider" l'entrée du cache. Puisque nous ne voulons pas avoir à payer les frais généraux de retransmission de la réponse complète si l'entrée mise en cache est bonne, et nous ne voulons pas payer les frais généraux d'un aller-retour supplémentaire si l'entrée mise en cache n'est pas valide, le protocole HTTP / 1.1 prend en charge l'utilisation de méthodes conditionnelles.
puis notez 13.3.4 :
Un proxy de mise en cache HTTP / 1.1, lors de la réception d'une demande conditionnelle qui inclut à la fois une date de dernière modification et une ou plusieurs balises d'entité en tant que valideurs de cache, NE DOIT PAS retourner de réponse localement mise en cache au client, sauf si cette réponse mise en cache est cohérente avec tous les champs d'en-tête conditionnels dans la demande.
Ainsi, Varnish peut retourner une réponse pour vous, mais vous avez toujours un aller-retour vers le serveur. Si vous pouvez utiliser un cache d'application tel que APC ou memcache, cela pourrait valoir la peine pour vous. Cependant, la mise en cache de validation est généralement meilleure pour les économies de bande passante que pour les ressources du serveur.
Il est préférable de laisser le cache de validation au client (navigateur ou code API).
L'utilisation du modèle d'expiration pour la mise en cache est l'endroit où un cache de proxy inverse brille vraiment. Cela vous permet de sauter complètement sur le serveur d'origine. En utilisant Expires, Cache-Control, Date, etc, est le meilleur (encore une fois, l' OMI) pour un mécanisme cache proxy inverse que le cache peut retourner la réponse, en supposant la non rassis, sans jamais frapper le serveur d'origine.