apache multiviews et priorité d'extension

Le 15/01/2010 17:36, Olivier Masson a écrit :

Savez-vous où et comment se règle la négociation de fichiers sous Apache ?

Non, mais note que toutes tes questions à propos du fonctionnement
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)

Le 15/01/2010 18:04, Olivier Miakinen a écrit :

Le 15/01/2010 17:36, Olivier Masson a écrit :

Savez-vous où et comment se règle la négociation de fichiers sous Apache ?

Non, mais note que toutes tes questions à propos du fonctionnement
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)

Merci, je vais poster là-bas alors.

Le 15/01/2010 18:04, j'écrivais :

la réponse de Bernd n'a pas encore trouvé de réponse

^^^^^^^ ^^^^^^^
Qu'est-ce que je peux raconter comme conneries, parfois !

(suivi nulle part)

Le 1/15/10 5:36 PM, Olivier Masson a écrit :

Bonjour,

Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Pour les langages, ok, mais par exemple pour les images, je ne mets
souvent que le nom du fichier sans l'extension et il va chercher ce
qu'il trouve. Mais dans quel ordre ?

Apache n'a pas besoin des extensions pour trouver un fichier
... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?)
de même nom !

http://httpd.apache.org/docs/2.2/content-negotiation.html ne m'a pas
beaucoup aidé.

Avant d'aller voir
à mon avis les extensions ne lui servent qu'à
- savoir s'il faut passer le fichier à un interpréteur
(php, ssi, cgi ...)
- choisir le fichier de la langue : fr, en, es, etc.
en fonction des préfs du navigateur :
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour>
en fonction de l'url :
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.en>
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.fr>
Les fichiers y sont : bonjour.en.htm et bonjour.en.htm
S'ils avaient été : bonjour.htm.en et bonjour.htm.en
les liens personnalisés ci-dessus n'eussent pas fonctionné.
- pour les jpg, gif, png, tif etc. ...
maintenant que j'ai lu en diagonale et pour ta question,
ça semble assez simple :

Content-type: image/gif; qs=0.5

il n'est peut-être pas obligatoire de le stipuler dans un fichier
extérieur ?
sans doute à placer vers la fin des instructions de type mime ?


<IfModule mod_mime.c>

Content-type: image/gif; qs=0.5

</IfModule>

Les png ou jpg ou tif (les !gif quoi) seront choisies d'abord
sauf à ce que l'extension 'gif' soit donnée
... et que le navigateur n'ait pas dit qu'il n'en voulait pas ;-)
ou qu'il n'ait pas lui-même indiqué un qs différent ?

<IfModule mod_mime.c>

Content-type: image/png; qs=0.9

Content-type: image/jpeg; qs=0.8

Content-type: image/gif; qs=0.5

Content-type: image/tiff; qs=0.1

</IfModule>

Mon but est de pouvoir dire :
- que je veux des png avant tout (s'il existe des gif du même nom)

Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.

Il faut que tu fasses ta css en conséquence :
.fond { background:url(truc.png) !important;
background:url(truc.gif)
}

- qu'il aille chercher des .css.gz avant des .css

Ne suffit-il pas de coder
<link href="styles.gz" ?
si le fichier est : 'styles.gz.css'

Mébon ... pour des css ...
- ça va pas compresser terrible, non ?
... encore que ... y en a qui en mettent des tartines
(dont de moult bis-repetita)
- et puis ... ça file dans le cache du navigateur
donc pas à charger si souvent

Si déjà j'ai une réponse, c'est beau mais j'ai une question auxiliaire :
est-ce qu'Apache met en cache un fichier qu'il compresse ?

C'est pas impossible, mais no sè.

Parce qu'activer la compression sur html, css, js, ça fait bcp de chose
à faire à chaque requête pour Apache.

Vu la vitesse à laquelle ça va ... il ne sera guère impressionné

Néanmoins on ne compresse que ce qu'il y a avantage à l'être :
( envoi direct - (compression + envoi allégé + décompression) ) > 0

À mon avis, c'est surtout intéressant pour les lourds tableaux (où la
compression est très bonne)
Et puis ... si ça fourmille d'images ...
à quoi bon gagner qques ko face à des Mo ?

--
sm

Le 1/15/10 6:04 PM, Olivier Miakinen a écrit :

Le 15/01/2010 17:36, Olivier Masson a écrit :

Savez-vous où et comment se règle la négociation de fichiers sous Apache ?

Non, mais note que toutes tes questions à propos du fonctionnement

pour les langues c'est assez facile
yaka lire le fichier de config
c'est assez bien commenté

Le blème qui m'apparait le plus important est d'abord :
les négociations navigateur<->serveur
qui, si j'ai bien compris, prennent le pas sur les petites manies qu'on
aura concoctées amoureusement dans son fichier de config

d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)

S'il fréquente aussi le NG php ...
il ne s'étonnera pas de ne pas recevoir de question à sa réponse
(ou lycée de Versailles) dans l'heure
;-)

--
sm

Le 15/01/2010 20:12, SAM a écrit :

Apache n'a pas besoin des extensions pour trouver un fichier
... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?)
de même nom !

Si, ça fonctionne, mais avec une priorité, apparemment par défaut.

<IfModule mod_mime.c>

Content-type: image/png; qs=0.9

Content-type: image/jpeg; qs=0.8

Content-type: image/gif; qs=0.5

Content-type: image/tiff; qs=0.1

</IfModule>

Je vais essayer ça.

Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.

J'en ai pas vu concernant autre chose que la langue et le fait qu'il
accepte gzip. Jamais vu de "je préfère du svg puis du png32...".

Il faut que tu fasses ta css en conséquence :
.fond { background:url(truc.png) !important;
background:url(truc.gif)
}

Tu penses bien que c'est un raisonnement global. Je ne vais pas m'amuser
à ajouter ça à toutes les images.
De plus, ça concerne d'autres types de fichiers.

Ne suffit-il pas de coder
<link href="styles.gz" ?
si le fichier est : 'styles.gz.css'

Oui, et il se passe quoi si le .gz n'existe pas ?
Encore une fois : raisonnement global. Je ne vais pas m'amuser à
vérifier l'existence d'un fichier, ni même faire un file_exists en PHP.

Mébon ... pour des css ...
- ça va pas compresser terrible, non ?
... encore que ... y en a qui en mettent des tartines
(dont de moult bis-repetita)
- et puis ... ça file dans le cache du navigateur
donc pas à charger si souvent

ça te ressemble comme réflexion ça !
Donc tu préfères bouffer 100k de JS et 50k de CSS plutôt que
respectivement 30 et 15 ?
J'ai déjà parlé de raisonnement global ?
Pense que j'ai un script qui va compresser (supprimer commentaires et
caractères superflus), puis gzipper. Mais que je ne gzippe pas si le
fichier est trop petit. Et que je conserve de toutes façons tous les
fichiers originaux pour garder les commentaires et éditer facilement.

Vu la vitesse à laquelle ça va ... il ne sera guère impressionné

Pour un site qui fait 100 visites/mois avec 10 pages statiques, non.
Mais selon le serveur web, le type de site, le nombre de visiteurs, ça
peut grimper vite. J'ai déjà baissé le niveau de compression pour
text/html (que j'ai laissé à la volée par Apache.)

Néanmoins on ne compresse que ce qu'il y a avantage à l'être :
( envoi direct - (compression + envoi allégé + décompression) ) > 0

À mon avis, c'est surtout intéressant pour les lourds tableaux (où la
compression est très bonne)
Et puis ... si ça fourmille d'images ...

L'intérêt est aussi au niveau de l'exécution. Il faut que le DOM soit
entièrement chargé, le plus rapidement possible.
Les images peuvent se charger moins rapidement, c'est moins génant.