OVH Community, your new community space.

Release 3 - pas de compression des images


janus57
04/01/2015, 16h53
Bonjour,

et pour les code utilisé la balise [code] sinon sa fait mal aux yeux, surtout en gras :/

Sinon le deflate est utile pour la compression pas parce que les personnes ont des petite connexion mais surtout car c'est plus rapide à télécharger les données, et sur mobile cela peu faire une différence comme sur PC fixe, car on a beau avoir le haut débit, mais si on est 5 personne sur un pauvre ADSL le débit en prend un sacré coup.

Cordialement, janus57

BBR
04/01/2015, 16h01
c'est pour Plesk mais ça devrait te donner les bonnes pistes, il faut juste créer le fichier de configuration : http://fabien.podium-adrenaline.fr/c...te-avec-plesk/

Fredo_L
04/01/2015, 15h23
J'ai regardé sur mon ancien serveur et ce qui est marqué exactement dans le httpd.conf, c'est la chose suivante :
#Sous Apache2 mod_gzip est devenu mod_deflate


# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|zip|gz|rm|flv|rar|mp3|avi|doc|p pt|pps|ppsx|xls|mkv|mp4|pdf)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary



La compression gzip est donc gérée par le module mod_deflate.

Sur le nouveau serveur, le httpd.conf contient la phrase suivante :
LoadModule deflate_module modules/mod_deflate.so
J'ai donc l'impression que la configuration du module est déportée ailleurs.

Je suis allé voir usr/lib64/httpd/modules/mod_deflate.so, mais c'est un binaire et non pas un fichier de configuration.
Je vais donc continuer à chercher.

Je n'ai pas de fichier de test à donner car je n'ai pas réussi à reproduire le problème du fichier corrompu (j'ai essayé plusieurs téléchargements de fichiers avec Firefox, IE et Chrome). De mémoire, c'était surtout les internautes utilisant Safari qui rencontraient le problème. De mémoire, certains navigateurs utilisent les connaissances de l'ordinateur pour savoir si le fichier à télécharger est un binaire, alors que d'autres (Safari) font confiance au serveur pour décider s'il convient de compresser ou non. L'idéal étant que seuls les fichiers textes et html soient compressées lors de la transmission.

Merci pour vos réponses en tout cas. Si je trouve plus d'infos, je posterai ici.

La version de mon serveur Apache est "Apache version 2.2.15 "
La doc du module est ici : http://httpd.apache.org/docs/2.2/mod/mod_deflate.html

Edit ; J'ai testé mes sites à l'aide de l'outil http://www.whatsmyip.org/http-compre...xhbmtob3IubmV0
Cela m'a dit que mes sites n'avaient pas l'option de compression d'activée.

J'ai donc ajouté dans le httpd.conf la ligne sur la compression de données et j'ai redémarré Apache. A présent, le test me dit que le serveur compresse bien les données.
Je suppose que la Release 2 activait par défaut la compression, alors que ce n'est plus le cas avec la Release 3.
La compression me permet de réduire de 75% la taille de mes pages html (on passe de 12 Ko à 4 Ko), mais avec des connexions haut débit, je pense que c'est assez négligeable.

Je considère que mon problème est à présent résolu.

janus57
04/01/2015, 13h50
Bonjour,

par défaut apache ne gère pas ça tout seule par hasard ?

Car en général sur les mutualisé aussi y a Gzip d'activé et les images ne sont jamais pris dedans, d'ailleurs je viens de tester ton site et pas de Gzip sur les images et pas de Gzip tout court en faite, même pas sur le CSS.

Tu aurait pas un lien vers une archive à télécharger pour que l'on test ?

Mais perso je dirais que apache gère cela tout seule comme un grand si on active gzip/deflate.

Cordialement, janus57

cassiopee
04/01/2015, 11h36
N'ayant pas de Release 3, je ne saurais te dire précisément.

Ceci dit, soit le serveur compresse par défaut, soit ce n'est pas le cas.

S'il ne compresse pas, la directive sera simplement inutile.

S'il compresse par défaut, alors oui, ça sera utile.

De toute façon, compresser des fichiers qui sont déjà compressés
(gif, jpeg, mp3, etc.) ne sert effectivement à rien.

Fredo_L
03/01/2015, 18h07
Bonjour,

Quand j'étais avec la Release 2 d'OVH, j'avais eu des visiteurs qui se plaignaient de télécharger des archives corrompues au format ZIP sur mon site. Pourtant, je ne comprenais pas car de mon côté, je n'avais aucun problème et tout me semblait bon. Finalement, je m'étais rendu compte que certains navigateurs tentaient de récupérer mes archives ZIP en effectuant une compression, ce qui avait pour conséquence de les corrompre.

J'avais fini par trouver une solution.
Dans le fichier httpd.conf, il y avait le paragraphe suivant :
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary


Ce paragraphe permettait d'indiquer au serveur les formats de fichiers à envoyer en binaire sans compression ou modification.
J'avais remplacé par la chose suivante :
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|zip|gz|rm|flv|rar|mp3|avi|doc|p pt|pps|xls|mkv|mp4|pdf)$ no-gzip dont-vary


Je viens de passer à la Release 3 d'OVH et j'ai l'impression que le paragraphe a disparu du httpd.
Est-ce que quelqu'un sait si le programme que j'avais rencontré avec la Release 2 est susceptible de se reproduire avec la Release 3 ?
C'est pour savoir si cela est utile que j'ajoute le paragraphe dans mon httpd.conf

Merci d'avance.