Apache est de ne pas envoyer de réponse 304 (si mod_deflate et AddOutputFilterByType est activé)

J'ai ajouté la ligne suivante dans mon Apache httpd.conf: -

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/x-javascript application/json

J'ai un fichier html (test.html) avec une inclusion de script: -

<script type="text/javascript" src="/test.js"></script>

Le problème est, à chaque fois que je charge test.html, test.js est également chargé avec l'état HTTP: 200.

La question est: Pourquoi le conditionnel est pas satisfait?

Si je commente la "AddOutputFilterByType" ligne dans httpd.conf Apache envoie 304.

Si j'active AddOutputFilterByType dans httpd.conf, l'en-tête de demande est: -

De l'hôte: optimiser 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 GTB5 (.NET CLR 3.5.30729) FirePHP/0.2.4 
Accept: */* 
Accept-Language: en-us,en;q=0.5 
Accept-Encoding: gzip, deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 300 
Connection: keep-alive 
Referer: http://optimize/
Cookie: PHPSESSID=nbq6h0eeahkshkcbc6ctu2j2b4 
Si-Modified-since: mardi 19 Mai 2009 à 07:06:46 GMT 
Si-None-Match: "2000000000717f-2c25a-46a3e8dcc2ad8"-gzip 
Cache-Control: max-age=0

Et l'entête de la réponse est: -

Date: Fri, 22 Mai 2009 à 07:03:40 GMT 
Serveur: Apache/2.2.9 (Win32) PHP/5.2.6 
Dernière modification: mardi 19 Mai 2009 à 07:06:46 GMT 
Etag: "2000000000717f-2c25a-46a3e8dcc2ad8"-gzip 
Accept-Ranges: bytes 
Vary: Accept-Encoding 
Content-Encoding: gzip 
Content-Length: 52583 
Keep-Alive: timeout=5, max=98 
Connection: Keep-Alive 
Content-Type: application/javascript

Mise à JOUR: j'ai remarqué, si je suis la désactivation de l'ETag, il fonctionne correctement. Je veux dire qu'il envoie 304.

FileETag None

Mais je tiens vraiment à garder ETag que c'est (je sais qu'il y a un inode question d'information).

  • Avez-vous jamais trouver une solution de contournement? Apache 2.4 semble être en train de faire la même chose, toujours de l'envoi de 200 réponse pour gzip serais content
  • Une raison quelconque vous souhaitez conserver les ETags? Il n'y a pas de réel intérêt à disposer d'eux si vous êtes juste de servir du contenu statique qui a déjà une Last-Modified date de revalidation. Certes, axing eux serait la solution la plus conforme à la RFC solution de contournement pour l'instant.
  • ETags sont nécessaires. Si jamais vous voulez remplacer le contenu avec une version plus ancienne (par exemple fichier javascript qui doit être reversée à une ancienne version sans bug qui a été introduit) et quand revenir le fichier de date plus ancienne, à l'époque, une simple comparaison de dates ne suffira pas.
  • Fascinant que cette question est toujours valable, presque une décennie après le post initial - d'achoppement dans apache 2.4.35 en 2019. sur la dernière version Stable de Debian pour le moment.
InformationsquelleAutor Sabya | 2009-05-22
  1. 25

    C'est un bug connu de Apache. Voir Apache bug #45023, et résumé de Apache 304 etags et mod_deflate.

    La reconstruction à partir de svn résoudre le problème. La résolution a été pour annuler la modification qui est annexé "-gzip" à l'etag. Cependant, il y sont associés HTTP problèmes de conformité.

    Si vous ne pouvez pas reconstruire Apache, il est suggéré de configuration à l'exécution solution de contournement dans le rapport de bug:

     RequestHeader  edit "If-None-Match" "^\"(.*)-gzip\"$" "\"$1\""
 Header  edit "ETag" "^\"(.*[^g][^z][^i][^p])\"$" "\"$1-gzip\""
    • Sur Apache 2.4, mais rien de "200 OK" réponses -- est-ce que cette solution fonctionne réellement?
    • C'est TOUJOURS un problème et je ne pouvais pas obtenir au-dessus de, en travaillant (dans Apache 2.4.7). Cependant, après plus de creuser, j'ai aussi décidé que les ETags ne sont pas utiles dans Apache, de toute façon. Un ETag serait plus utile si elle était un hachage du contenu, de sorte que même si le timestamp a changé, il peut toujours être utilisé pour décider si le contenu n'en est rien. Pour Apache l'ETag est une combinaison de l'inode, de la taille et de dernière modification des données (avec la taille et de dernière modification des valeurs par défaut). Donc, puisqu'il utilise les attributs de fichier, plutôt que d'un hachage du contenu, j'ai décidé de l'éteindre et de l'utilisation de Dernière modification à la place.
    • Cela semble être ENCORE un problème? Je suis à l'aide d'Apache 2.4.10
    • Avez-vous jamais savoir si c'est encore un problème sur un serveur apache 2.4?
    • pas sûr, si j'ai le même problème. Apache ne pas envoyer 304-têtes pour .js et .les documents css, les images ont 304 correctement. Je suis de proxy pour nodejs. nodejs sans apache envoie tous les 304 correctement.
    • J'ai effectivement confirmé hier que ce bug affecte encore de 2,4, et la solution ci-dessus a fonctionné pour moi.
    • entendez-vous la solution à la modification de l'requestheader? Cela ne fonctionne pas pour moi. Ou avez-vous désactivé les ETags? Je pense que les ETags sont très utiles concept, ce n'est pas vraiment une solution pour les éteindre...
    • RequestHeader éditer "Si-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"' fonctionne pour moi. à partir de bz.apache.org/bugzilla/show_bug.cgi?id=45023 vraiment étrange que ce bug est toujours un problème dans apache 2.4.10 ...

    InformationsquelleAutor p00ya
  2. 9

    "J'ai aussi décidé que les ETags ne sont pas utiles dans Apache, de toute façon."

    Mal,

    par exemple vous avez un fichier avec la date de modification de jeu à '2016.07.27 05:00:00', de la télécharger à votre site, le navigateur récupère ce fichier avec le code HTTP 200, puis il la met en cache et revalide à chaque fois avec HTTP 304.

    Ensuite, vous téléchargez un fichier avec le même nom de fichier à nouveau, mais avec plus d'horodatage '2013.07.27 05:00:00' et avec d'autres contenus.

    Si ETag est désactivé sur le serveur, le navigateur va utiliser seulement If-Modified-Since: demande afin de déterminer si le fichier a été modifié sur le serveur, de sorte que la demande sera If-Modified-Since: 2016.07.27 05:00:00, mais le fichier n'est pas modifié après cette date, de sorte qu'un HTTP 304 est renvoyé, même si le fichier a été modifié.

    Si ETag est activé sur le serveur, en plus de If-Modified-Since:, il y aura un If-None-Match: en-tête provenant de navigateur qui permet de détecter que le fichier a été modifié(par défaut - timestamp incompatibilité+différence de taille) et le fichier va être retéléchargé.


    Ce problème existe toujours dans Apache 2.4.23, donc, j'ai écrit un meilleur code que ci-dessus pour résoudre ce problème. Expanation ligne par ligne:

      1) Si le navigateur envoie un "Si-None-Match' demande '-gzip' à la fin, définir la variable request_etag=gzip.

      2) Modifier les en-tête de demande de sortir la bande '-gzip' partie.

      3) Modifier la réponse de l'en-tête ajouter '-gzip', mais seulement si le navigateur a envoyé a 'gzip' demande d'abord ou le contenu de la réponse est gzip codé.

    Vous pouvez utiliser anticipation négatif ou négatif lookbehind, regex vitesse est la même, Apache supporte à la fois

    \"(.+(?<!-gzip))\"       #using negative lookbehind
\"((?:.(?!-gzip\"))+)\"  #using negative lookahead

    Cas de Test:

      "2e2-5388f9f70c580-afeg"

      "2e2-5388f9f70c580-gzin"

      "2e2-5388f9f70c580-gzipd"

      "2e2-5388f9f70c580-gzip"

      "2e2-5388f9f70c580gzip"

    Copiez-Collez ce code dans Apache .conf

    SetEnvIf           If-None-Match "-gzip\"$" request_etag=gzip
RequestHeader edit If-None-Match "(.+)-gzip\"$" "$1\""
Header edit        ETag     "(.+(?<!-gzip))\"$" "$1-gzip\"" "expr=reqenv('request_etag') == 'gzip' || resp('Content-Encoding') == 'gzip'"

    Personnellement, j'utilise le code suivant, qui bandes-gzip' partie d'abord si c'est un gzip réponse, et ne pas reappend, de sorte que le navigateur ne sera jamais envoyer a 'gzip' 'If-None-Match' en-tête.

    Header edit ETag "(.+)-gzip\"$" "$1\"" "expr=resp('Content-Encoding') == 'gzip'"
    • Le problème existe toujours dans Apache 2.4.25. La 3 ligne de code ci-dessus m'a aidé, mais j'avais besoin pour permettre headers_module.
    InformationsquelleAutor Stalingrad
  3. 2

    Je sais que c'est une très vieille question, mais il semble qu'il y a un plus up-to-date de la réponse.

    À Apache de ne pas ajouter le -gzip suffixe, vous devez utiliser le DeflateAlterETag directive avec une valeur de NoChange.

    Voir la documentation ici: http://httpd.apache.org/docs/trunk/mod/mod_deflate.html#deflatealteretag

    InformationsquelleAutor Sandy Chapman
  4. 0

    Peut-être que vous utilisez un squid proxy qui manipule les Requêtes HTTP?

    • Non, je ne suis pas en utilisant un proxy. Je suis même d'essayer sur mon localhost. Même résultat.
    InformationsquelleAutor powtac