Forum ZitePLUS
Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 03/05/2013 14:37:22
- kyodev
- Membre
- Lieu : Lyon
- Inscription : 19/04/2013
- Messages : 11
correction view.php
bonjour
2 petits défauts que j'ai été amené à corriger sur Zite+ 0.9.2, fichier view.php
fichier de type non déclaré
si le type mime n'est pas déclaré (dans zplus/mime.txt?), le fichier est affiché au lieu d'être proposé en téléchargementdocument inexistant
si on appelle n'importe quoi, par ex: /view.php/fghjkljhg.jpg, on se retrouve avec une page vide et un entete:
HTTP/1.1 200 OK
...
Content-Type: text/html
1: correction; par défaut envoi entete application/octet-stream (au lieu de text/plain)
diff:
[== Indéfini ==]
@@ -24 +24,2 @@
- $contenttype= isset($mimetype[$doc[cDocExt]])?$mimetype[$doc[cDocExt]]:'text/plain';
+ // force le téléchargement d'un tyoe de fichier inconnu au lieu de l'afficher
+ $contenttype= isset($mimetype[$doc[cDocExt]])?$mimetype[$doc[cDocExt]]:'application/octet-stream';2: complétion condition négative inexistante
diff:
[== Indéfini ==]
@@ -36,0 +38,3 @@
+ } else {
+ // en cas de document inexistant, envoi erreur 404
+ header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');fichier complet view.php visible ici
Hors ligne
#2 05/05/2013 00:40:16
- jpg
- Administrateurs
- Inscription : 19/11/2008
- Messages : 2 086
- Site Web
Re : correction view.php
Bonsoir,
1. fichier de type non déclaré
si le type mime n'est pas déclaré, le fichier est affiché au lieu d'être proposé en téléchargement
Tout à fait, et certains navigateurs (à l'époque ou j'ai fait les tests) sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.
Mais je comprends ta remarque: j'aurais pu faire le choix inverse.
2. document inexistant
si on appelle n'importe quoi, par ex: /view.php/fghjkljhg.jpg, on se retrouve avec une page vide et un entete:
HTTP/1.1 200 OK
...
Content-Type: text/html
Une version interne qui renvoyait un code 404 a existé ... le temps du test.
Le fait de ne pas renvoyer d'erreur 404 sur un document inexistant ou inaccessible à certains utilisateurs (car privé) est un choix que j'assume pleinement 
Il est ainsi possible d'avoir sur une seule page HTML, des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur et cela sans provoquer de disgracieux messages d'erreurs.
a+
Jean-Paul
Hors ligne
#3 05/05/2013 08:06:59
- kyodev
- Membre
- Lieu : Lyon
- Inscription : 19/04/2013
- Messages : 11
Re : correction view.php
bonjour
certains navigateurs sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.
humm, ça dépend du type de fichier, dans mon cas, un .kml affiché c'est pas ... esthétique
et encore faut-il, si l'appli n'est pas correctement configurée, que le serveur le soit... ça commence à devenir technique pour un utilisateur final (je pense à celui qui devrait faire ou compléter une page).
et puis si la configuration n'est pas courante (pré-configurée), dans mon cas: application/vnd.google-earth.kml+xml .kml, il n'y pas de raison que le navigateur soit capable de gérer, et dans ce cas, c'est à l'utilisateur final de prendre le relais s'il ne veut pas télécharger mais ouvrir dans une appli.
des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur
oui, je n'ai pas envisagé le cas des droits. pour les pages, c'est parfait, l'erreur 404 est bien émise, mais dans le cas que j'ai rencontré, pour une image un
header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');ne perturbe pas l'affichage, je pense (mais non testé) qu'une erreur 403 ne devrait pas gêner, c'est le navigateur qui décide.
ça permetterait:
.de tester automatiquement un site avec une appli, Xenu par exemple,
.de surveiller le site avec des outils webmaster ou les logs (je logue spécifiquement les erreurs 404 pour suivre les évolutions et pour mettre à jour au besoin un htaccess pour aiguiller les moteurs de recherche ).
de plus un code 200 avec un même contenu (vide) ne doit pas participer à un bon indexage par les moteurs de recherche, de même 403 devrait éviter de maintenir l'indexage d'un document privé.
amha, il faudrait peaufiner alors, 403? si ce n'est déjà fait? ou 404.
mais il n'y a pas que les images, un pdf, participant pour beaucoup à l'indexage, doit absolument renvoyé un 404 à un moteur s'il n'est pas présent.
si ça peut aider à la réflexion...
cordialement
Hors ligne
#4 05/05/2013 12:04:13
- jpg
- Administrateurs
- Inscription : 19/11/2008
- Messages : 2 086
- Site Web
Re : correction view.php
jpg a écrit :certains navigateurs sont capables dans ce cas là d'afficher correctement le fichier dans le navigateur.
humm, ça dépend du type de fichier, dans mon cas, un .kml affiché c'est pas ... esthétique
C'est sur c'est affiché comme du texte
et encore faut-il, si l'appli n'est pas correctement configurée, que le serveur le soit... ça commence à devenir technique pour un utilisateur final (je pense à celui qui devrait faire ou compléter une page).
et puis si la configuration n'est pas courante (pré-configurée), dans mon cas: application/vnd.google-earth.kml+xml .kml, il n'y pas de raison que le navigateur soit capable de gérer, et dans ce cas, c'est à l'utilisateur final de prendre le relais s'il ne veut pas télécharger mais ouvrir dans une appli.
Oui, comme je le disais je comprends ta remarque, elle est légitime, je ne dis pas non.
Dans l'immédiat le plus simple pour toi est de rajouter ce type dans mime.txt.
jpg a écrit :des documents (de type image) qui s'affiche ou ne s'affiche pas en fonction de l'utilisateur
oui, je n'ai pas envisagé le cas des droits. pour les pages, c'est parfait, l'erreur 404 est bien émise, mais dans le cas que j'ai rencontré, pour une image un
header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found');ne perturbe pas l'affichage, je pense (mais non testé) qu'une erreur 403 ne devrait pas gêner, c'est le navigateur qui décide.
Les documents, c'est autres choses: rien à voir avec les pages. Ils ont aussi des droits propres (oui, ZitePlus, c'est un tout petit CMS, mais puissant sur les droits )
Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible 
ça permetterait:
.de tester automatiquement un site avec une appli, Xenu par exemple,
.de surveiller le site avec des outils webmaster ou les logs (je logue spécifiquement les erreurs 404 pour suivre les évolutions et pour mettre à jour au besoin un htaccess pour aiguiller les moteurs de recherche ).de plus un code 200 avec un même contenu (vide) ne doit pas participer à un bon indexage par les moteurs de recherche, de même 403 devrait éviter de maintenir l'indexage d'un document privé.
Pour l'instant, cela n'a pas semblé être un frein pour l'indexation
amha, il faudrait peaufiner alors, 403? si ce n'est déjà fait? ou 404.
mais il n'y a pas que les images, un pdf, participant pour beaucoup à l'indexage, doit absolument renvoyé un 404 à un moteur s'il n'est pas présent.si ça peut aider à la réflexion...
ça aide, ça aide
a+
Jean-Paul
ps: la version suivante des view.php et thumb.php a déjà été publié il y a quelques semaines dans un autre sujet (pour la 0.9.3 de test), mais elles sont compatible 0.9.2
Hors ligne
#5 05/05/2013 17:55:56
- kyodev
- Membre
- Lieu : Lyon
- Inscription : 19/04/2013
- Messages : 11
Re : correction view.php
Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible
?? je ne sais pas si on se comprend, une image manquante (404) ne dégrade pas une page, si l'attribut alt existe, il est affiché, si pas d'attribut alt, rien n'est affiché. par contre, des appli, des scripts serveur eux peuvent dans ce cas fonctionner.
pour 403, jamais testé, je veux bien le faire mais je présume que pas de problèmes
Pour l'instant, cela n'a pas semblé être un frein pour l'indexation
content duplicate?
une erreur ne sera jamais grave, si c'est en nombre, le site n'aura pas sa position optimum. le référencement, c'est pas 1 règle, c'est une somme de détails, qui pour la plupart ne sont que du bon sens.
mais si les choses sont figées, je m'arrête donc là.
Hors ligne
#6 06/05/2013 18:05:14
- jpg
- Administrateurs
- Inscription : 19/11/2008
- Messages : 2 086
- Site Web
Re : correction view.php
jpg a écrit :Il faut penser aux documents images insérés dans une balise <img>, et un code d'erreur 404 (ou 403 quand l'image est privé), c'est pas terrible
?? je ne sais pas si on se comprend, une image manquante (404) ne dégrade pas une page, si l'attribut alt existe, il est affiché, si pas d'attribut alt, rien n'est affiché. par contre, des appli, des scripts serveur eux peuvent dans ce cas fonctionner.
pour 403, jamais testé, je veux bien le faire mais je présume que pas de problèmesjpg a écrit :Pour l'instant, cela n'a pas semblé être un frein pour l'indexation
content duplicate?
une erreur ne sera jamais grave, si c'est en nombre, le site n'aura pas sa position optimum. le référencement, c'est pas 1 règle, c'est une somme de détails, qui pour la plupart ne sont que du bon sens.
content-duplicate ?
Sauf erreur ça apparaît dans google analytics, donc on peut suivre et corriger.
Après, bien sur, il vaut mieux que cela n'arrive pas, comme les erreurs 404 d'ailleurs
mais si les choses sont figées, je m'arrête donc là.
Figées ou pas: la question ne se pose pas en ces termes là.
Mais avant de toucher à un script de base ... je prends toujours des précautions
D'autant plus qu' à l'époque ou j'ai fait les tests avec IE et Firefox, il y a des trucs qui ne marchaient pas bien si on renvoyait via php un code d'erreur 404 pour une
image avec par exemple <img src=..../view.php/testimage.png>. Je ne sais plus avec lequel des deux navigateurs, mais vu que c'était les deux qui dominaient sans
partage le marché, je me suis adapté et j'ai retiré la génération de l'erreur 404.
Je n'ai pas re-testé depuis, peut-être que c'est parfaitement géré maintenant.
Je regarderai afin de déterminer ce qu'il en est avec les principaux navigateur du marché aujourd'hui.
a+
Jean-Paul
Hors ligne
#7 12/07/2015 19:03:52
- jpg
- Administrateurs
- Inscription : 19/11/2008
- Messages : 2 086
- Site Web
Re : correction view.php
D'autant plus qu' à l'époque ou j'ai fait les tests avec IE et Firefox, il y a des trucs qui ne marchaient pas bien si on renvoyait via php un code d'erreur 404 pour une
image avec par exemple <img src=..../view.php/testimage.png>. Je ne sais plus avec lequel des deux navigateurs, mais vu que c'était les deux qui dominaient sans
partage le marché, je me suis adapté et j'ai retiré la génération de l'erreur 404.Je n'ai pas re-testé depuis, peut-être que c'est parfaitement géré maintenant.
Je regarderai afin de déterminer ce qu'il en est avec les principaux navigateur du marché aujourd'hui.
J'ai pris un peu de temps, mais j'ai re-testé depuis: plus de différence de comportement selon les navigateurs.
Aussi à partir de la version 0.9.5, view et thumb renvoient tous les deux un code d'erreur 403 s'il n'est pas possible d'accéder à l'image pour une raison ou une autre.
Aucune différence n'est faite entre un document inexistant ou des droits inapropriés (inutile de renseigner un éventuel attaquant )
a+
Jean-Paul
Hors ligne
Pages : 1