Ok, never mind, trouvé les informations pertinentes dans le cadre du Cache Revalidation and Reload Controls section du HTTP Spec
Fondamentalement, vous pouvez servir tous les validateurs différents que vous voulez, mais vous devez savoir que, dans ces proxies cas avoir un ensemble de différents validateurs provenant de leur propre cache et de divers agents utilisateurs communiquant avec le proxy. Ils peuvent choisir de vous en envoyer un, ce qui peut ne pas être le bon ou le meilleur pour les utilisateurs finaux. Cependant, une "meilleure approche" a été suggérée dans la spécification.
Je suppose que cela devrait couvrir Expires en-têtes ainsi que ETags, Cache-Control et autres joyeusetés.
Voici l'extrait pertinent, au cas où quelqu'un est intéressé:
Lorsqu'un cache intermédiaire est forcé, au moyen d'un max-age = 0 directive, à revalider sa propre entrée de cache, et le client a fourni son propre validateur dans la requête, le validateur fourni peut différer du validateur actuellement stocké avec l'entrée de cache . Dans ce cas, le cache PEUT utiliser l'un ou l'autre des validateurs pour effectuer sa propre demande sans affecter la transparence sémantique . Toutefois, le choix du validateur peut affecter les performances. La meilleure approche consiste à ce que le cache intermédiaire utilise son propre validateur lors de sa demande. Si le serveur répond avec 304 (pas modifié), le cache peut renvoyer sa copie maintenant validée au client avec une réponse 200 (OK). Si le serveur répond avec une nouvelle entité et validateur cache, cependant, le cache intermédiaire peut comparer le validateur retourné avec celui prévu dans la demande du client, en utilisant la fonction de comparaison forte. Si le validateur du client est égal à le serveur d'origine, le cache intermédiaire renvoie simplement 304 (non modifié). Sinon, il renvoie la nouvelle entité avec une réponse 200 (OK) . Si une demande inclut la directive no-cache, elle ne doit PAS inclure min-fresh, max-stale ou max-age.