Apache: envoyer des fichiers gzip pré-emballés

8

Je veux qu'Apache envoie des fichiers statiques gzip sur le fil, mais je veux aussi qu'Apache ne les gzip pas toujours encore et encore. J'ai donc pensé qu'il ne serait pas possible de livrer un fichier .gz s'il existe. Cette configuration:

Structure du fichier:

static/
|
|--- style.css
|
\--- style.css.gz

Et ce qui suit dans un .htaccess:

règle mod_rewrite:

RewriteCond %{REQUEST_FILENAME}.gz -s
RewriteRule ^(.+) $1.gz [L]

Et ce paramètre:

AddEncoding x-gzip .gz

En fait, cela fonctionne dans la mesure où le fichier .gz est envoyé à la place du .css, si la demande est envoyée à /static/style.css. Le problème est seulement que le fichier est livré en tant que "application / x-gzip" et non en tant que "text / css". L'utilisation de l'indicateur T de mod_rewrite ne change rien à cela. Ni explicite

AddType text/css .css

Quelqu'un a-t-il une idée de comment je pourrais obtenir le comportement souhaité? Ou est-ce inutile pour une raison que je n'ai pas prise en compte?

EDIT: Il existe une difficulté supplémentaire: l'envoi du fichier d'origine aux clients sans prise en charge gzip. Quelqu'un at-il une idée de comment cela pourrait fonctionner?

apache-2.2 cache gzip rewrite Boldewyn
la source
Je suis étonné que ce ne soit pas plus évident, car il semble fou d'avoir un serveur Web qui ne fait pas cela. Je pense que IIS a un système pour mettre en cache des copies gzippées de fichiers statiques au premier accès. mod_deflate ne mentionne pas une telle fonctionnalité.
rjmunro
Les documents mod_deflate d'apache ont maintenant leur propre exemple: httpd.apache.org/docs/2.4/mod/mod_deflate.html#precompressed
cweiske

Réponses:

5

Une solution pour envoyer la bonne version aux navigateurs qui n'acceptent pas gzip serait quelque chose comme:

RewriteCond %{HTTP:Accept-Encoding} !gzip
...your rules here...

De plus, il existe une autre façon de changer le type, à savoir:

<FilesMatch .*\.css.gz>
    ForceType text/css
</FilesMatch>

<FilesMatch .*\.js.gz>
    ForceType text/javascript
</FilesMatch>

HTH.

Sam Halicke
la source
Cool merci! Existe-t-il des documents pour le truc% {HTTP: ...}? Je n'en ai vu aucune mention dans la section RewriteCond d'Apache 2.2. Le FilesMatch était une autre idée que j'avais, mais je l'ai trouvé plus verbeux. Étant donné que les deux règles doivent déclencher le moteur d'expression rationnelle, il ne devrait pas y avoir de réelle différence.
Boldewyn
OK, j'ai trouvé les documents. httpd.apache.org/docs/2.2/mod/mod_rewrite.html Je viens de sauter la partie intéressante.
Boldewyn
Ce n'est pas un gros problème, mais en lisant cette configuration, si quelqu'un récupérait manuellement le fichier .css.gz, il obtiendrait le texte / css, alors qu'il devrait obtenir le type application / x-gzip.
rjmunro
Pourquoi le ! avant gzip sur la ligne Accept-Encoding? C'est sûrement le contraire de ce dont vous avez besoin?
rjmunro
Je pensais la même chose, il est logique d'avoir le RewriteCondseul match lorsque le client n'accepte la compression gzip.
David Z
3

Ah, il semble que j'ai trouvé une solution: le drapeau T ne fonctionne pas s'il est défini sur la même règle, mais il le fait, si vous le dépensez une règle qui lui est propre:

RewriteCond %{REQUEST_FILENAME}.gz -s
RewriteRule ^(.+) $1.gz

RewriteRule \.css\.gz$ - [T=text/css]
RewriteRule \.js\.gz$ - [T=text/javascript]

J'aimerais encore entendre les solutions et les opinions des autres.

Boldewyn
la source