Bonjour,
En faisant une vérification, je viens de m’apercevoir que certaines images dont le nom commence par un point (« . ») ne sont plus affichées dans aucun navigateur (vérifié avec Firefox, Chrome, Opera, Brave, Edge, Internet Explorer).
Tous les navigateurs affichent un micro carré et ne donnent aucune explication sauf Firefox qui, toujours plus intelligent que les autres, se fend d'un message d'erreur ("L'image ne peut être affichée, car elle contient des erreurs"), mais ne dit pas de quelle erreur il s'agit (un code erreur et une nomenclature de ces codes seraient les bienvenus).
Il n’y a pas d’erreur 404 donc le fichier existe bien sur le serveur.
Exemple qui tombe en erreur :
https://assiste.com/Assiste/media/Logo_72/.NET_Version_Detector.png
Toutes les autres images de ce répertoire s’affichent normalement.
Exemple :
https://assiste.com/Assiste/media/Logo_72/0-day_warez.png
Je duplique l'image et lui retire son point initial
https://assiste.com/Assiste/media/Logo_72/NET_Version_Detector.png
Elle s'affiche, donc le problème n'est pas son contenu, mais son enveloppe (son nom).
J’utilise Photoshop. Je régénère l'image .NET_Version_Detector.png de son original en PSD (le format Photoshop) en format PNG et upload sur le serveur. Même erreur de lecture.
Je fais une autre opération : l'inverse - je duplique l’image 0-day_warez.png, qui s’affiche bien :
https://assiste.com/Assiste/media/Logo_72/0-day_warez.png
Je colle un point devant, soit .0-day_warez.png. J’upload sur le serveur et je teste : message d’erreur !
https://assiste.com/Assiste/media/Logo_72/.0-day_warez.png
b]Bon... c'est bien le point initial[/b] et c'est nouveau, ça (ou alors je ne m'en suis pas aperçu depuis un moment - Les dernières modifications de ces images remontent à 2013 et 2015 et je ne passe pas mon temps à relire des pages anciennes normalement stables.).
Est-ce que quelqu’un à la moindre idée ?
Je sais qu’il y a eu des correctifs PHP récents comme
[http://assiste.forum.free.fr/viewtopic.php?f=173&t=34251
Mais le site est en HTML pur (il n’utilise pas PHP) et n’est donc pas concerné par ces correctifs.
Quelque chose venant du logiciel serveur Apache ? Un correctif intempestif Apache ?
Historique des avis et alertes Apache
Quelque chose venant de l'hébergeur OVH ?
Je suis à court de spéculations (mais je pencherais bien pour l'implémentation d'un correctif Apache).
Cordialement,
Problème avec certaines images sur le serveur
Sujets apparentés
- [RESOLU] Server unable to read htaccess file, denying access to be safe
25792
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
22978
10.01.2019 11:14
- Comment récupérer son mot de passe phpmyadmin ?
19961
14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
19767
22.12.2016 11:46
- Variable upload_max_filesize plus grande que post_max_size
19740
11.06.2017 16:01
- Résiliation hébergement+domaine
15450
11.09.2018 20:28
- Résiliation hébergement
14617
27.07.2018 10:39
- Transfert hebergement et domaine .fr entre client OVH ?
13822
21.12.2016 15:10
- Ne supporte pas FTP sur TLS
13788
11.12.2018 18:48
- Nouvelle fonctionnalité : SFTP pour tous
13473
06.01.2017 14:50
```text il y a une erreur, mal appréhendée
```text
curl --head -XGET https://assiste.com/Assiste/media/Logo_72/.NET_Version_Detector.png
HTTP/2 302
date: Wed, 19 Jun 2019 09:10:47 GMT
location: https://assiste.com/404.php
``` ```
Merci, Kyodev,
Je ne vois pas quoi faire pour l'instant (et je n'ai pas de 404).
> 302 : Document déplacé de façon temporaire. La ressource demandée réside temporairement à une adresse (URI) différente. Cette redirection étant temporaire, le navigateur Web doit continuer à utiliser l'URI original pour les requêtes futures.
Donc j'attends.
Cordialement,
```text attendre quoi?
302 ok...
mais la location est la cible finale:
```text
content-type: text/html; charset=iso-8859-1
location: https://assiste.com/404.php
```
c'est ta page personnalisée **404**
redirection via le .htaccess (onError ?) ```
Re, Kyodev
.htaccess
Page de substitution si erreur 403 ou 404
ErrorDocument 404 https://assiste.com/404.php
ErrorDocument 403 https://assiste.com/404.php
Rien de prévu pour l'erreur 302
Et puis, pourquoi quelque chose qui fonctionne tout-à-fait normalement depuis des années se met, tout d'un coup, à sortir en erreur ? C'est, tout de même, étonnant, et certainement justifié par un changement de gestion des noms de fichiers commençant par un point .
On dirait une nouvelle gestion en assimilation aux fichiers cachés, commençant par un point, sous Unix/Linux.
Mais pourquoi cela toucherait les images et pas les pages HTML ? Exemple :
https://assiste.com/.NET_Framework_Versions_installees.html https://assiste.com/.NET_Framework_Versions_installees.html
Cordialement,
je n'ai pas lu tout ton message
tu signales une image sans erreur, mais je te montre que si erreur 404
passer par ErrorDocument induit par une redirection 302 (j'avais jamais testé :)
un essai sur Ovh: un point en tête d'une image permet son listage et son affichage
http://test.1o5b.com/.avatar_300.pngo5b.com/.avatar_300.png
donc il va falloir chercher ... mais je sais pas trop quoi :/
à l'instant même 15:30
wget https://assiste.com/Assiste/media/Logo_72/.NET_Version_Detector. png
--2019-06-19 15:29:09-- https://assiste.com/Assiste/media/Logo_72/.NET_Version_ Detector.png
Resolving assiste.com (assiste.com)... 2001:41d0:1:1b00:213:186:33:24, 213.186.3 3.24
Connecting to assiste.com (assiste.com)|2001:41d0:1:1b00:213:186:33:24|:443... c onnected.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:10-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:11-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:11-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:11-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:11-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:12-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:12-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:12-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:13-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:13-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:13-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:13-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:14-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:14-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:14-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:15-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:15-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:15-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:15-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
--2019-06-19 15:29:16-- https://assiste.com/404.php
Reusing existing connection to assiste.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://assiste.com/404.php [following]
20 redirections exceeded.
Moi j'enlèverais le point.
```text Bonsoir, Fritz2cat et Kyodev,
Je pense, en effet, à supprimer le point, mais, avant tout, j’aimerais comprendre.
Ça a fonctionné durant des années et, tout d’un coup, ça ne fonctionne plus (ou cela ne fonctionne plus depuis un moment, mais je ne m'en était pas aperçu).
Voyons :
Il me semble que les fichiers statiques sont délivrés directement par Apache.
Il me semble que, par défaut, Apache, manipule tout en l’UTF-8.
Kyodev, je ne comprends pas ta note :
> content-type: text/html; charset=iso-8859-1
> location: https://assiste.com/404.php
> c'est ta page personnalisée 404
> redirection via le .htaccess (onError ?)
Tu supposes que j’ai cela codé dans mon .htaccess ?
Pas du tout. Il n’y a rien en ce sens.
Pour faire bonne mesure, j’ai ajouté, dans le .htaccess :
AddDefaultCharset utf-8
AddCharset utf-8 .html .css .js
DefaultLanguage fr-FR
Rien de changé et toujours pas de 404. Le fichier .0-day_warez.png est bien sur le serveur, mais il n’est pas servi pour une raison nouvelle et indéterminée. C’est vraiment curieux.
## Sous Firefox (Moteur de rendu Quantum)
https://assiste.com/Assiste/media/Divers/dotnet_01_Firefox.png
## Sous Brave (Moteur de rendu Blink)
https://assiste.com/Assiste/media/Divers/dotnet_02_Brave.png
## Sous Edge (Moteur de rendu EdgeHTML (fork de Trident) - passera à Blink)
https://assiste.com/Assiste/media/Divers/dotnet_03_Edge.png
## Sous Internet Explorer (Moteur de rendu Trident)
https://assiste.com/Assiste/media/Divers/dotnet_04_IE.png
## Sous Chrome Explorer (Moteur de rendu Blink)
https://assiste.com/Assiste/media/Divers/dotnet_05_Chrome.png
## Sous Opera (Moteur de rendu Blink)
https://assiste.com/Assiste/media/Divers/dotnet_06_Opera.png
Cordialement, ```
> Tu supposes que j’ai cela codé dans mon .htaccess ?
oui:
> ErrorDocument 404 https://assiste.com/404.php
je ne vois pas ce que le l'utf8 viendrait faire, on ne parle pas de contenu de fichier
je ne vois pas ce que le moteur de rendu vient faire, l'erreur est dès la serveur Apache, charset=iso-8859-1, *"avant"* php
à moins d'un souci ponctuel, je constate que pour une image valide, un point ajouté, elle le reste
http://test.1o5b.com/o5b.com/
> Je sais qu’il y a eu des correctifs PHP récents comme
mise en oeuvre chez Ovh hier à priori, il faut le temps que Ovh réagisse
https://community.ovh.com/t/bug-ovh-php-gd-freetype-out-captcha-down/18502/6
mais à priori, cela peut amèner d'autres soucis
Re, Kyodev
serveur 213.186.33.24 (en mutualisé).
```text ```text
dig +short -x 213.186.33.24
cluster013.ovh.net
```
tu peux mettre une image *à point* posant soucis avec son image *sans point* valide pour tester? ```
Image à point
https://assiste.com/Assiste/media/Logo_72/.NET_Version_Detector.png
https://assiste.com/Assiste/media/Logo_72/.NET_Version_Detector.png
La même, au même endroit, sans point
`https://assiste.com/Assiste/media/Logo_72/NET_Version_Detector.png`
https://assiste.com/Assiste/media/Logo_72/NET_Version_Detector.png
je sens que ça va pas te plaire:
http://test.1o5b.com/o5b.com/
l'image valide, renommée avec un point en tête
visibles toutes les deux :/
```text par acquit de conscience, je viens d'ajouter un .htaccess:
```text
ErrorDocument 404 https://assiste.com/404.php
```
textuel, sans plus d'erreur ```
Mais c'est vexant, à la fin ;)
Un doute subi m’assaille et m’étreint.
Et si d’autres fichiers qui comportent des points (cas des numéros de versions des logiciels) avaient le même problème ?
Donc je télécharge https://assiste.com/Assiste/ftp/AppRemover-3.1.13.1.exe https://assiste.com/Assiste/ftp/AppRemover-3.1.13.1.exe
Et bien, non, tout va bien.
Alors, je lui mets un point initial et je télécharge https://assiste.com/Assiste/ftp/.AppRemover-3.1.13.1.exe https://assiste.com/Assiste/ftp/.AppRemover-3.1.13.1.exe
Tout va bien aussi.
De plus en plus obscure (du côté de mon serveur).
si tu charges mon manchot (issu de PS aussi, avec un point aussi :/) et le charges sur ton serveur?
bonjour,
des mises à jour faites hier sont en cours de correction.
cela vient/viendrait de php?
oui, une maj 7.2 avec un module problèmatique à priori.
on verra ce que @PierreP8 sur le cluster13 dira s'il essaye en php7.1 ou 7.3, mais son souci semble ***au niveau du serveur Apache***, sans utilisation de php... (appel direct d'une image)
je check en détail si c'est pas lié.
@PierreP8 possible de passer l'image en stable ? (à la place de légacy)
https://docs.ovh.com/fr/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/#choisir-un-environnement-dexecution
merci
Le manchot :
Image à point
https://assiste.com/Assiste/media/Logo_72/.avatar_300.png
https://assiste.com/Assiste/media/Logo_72/.avatar_300.png
La même, au même endroit, sans point
`https://assiste.com/Assiste/media/Logo_72/avatar_300.png`
https://assiste.com/Assiste/media/Logo_72/avatar_300.png
passe en image stable comme a dit antoine, cela devrait résoudre le souci
si ça règle pas le pb , j'aimerai un sous domaine de test avec juste deux image. sans cdn / en stable.
Je veux bien, mais je ne sais pas ce que cela veut dire et, à la lecture du doc, ça fou la trouille :
Je ne suis pas du tout un administrateur et je n'y connais rien. J'écris des pages sur des sujets que je maîtrise et les mets en ligne, mais ne touche jamais au côté serveur ni ne parle de ce que je ne connais pas.
En plus, c'est un site perso, bénévole. Lorsque je lis :
> Avant d’initier tout changement, assurez-vous que la manipulation ne rendra pas inaccessible votre site internet. Si vous n’en êtes pas sûr ou si vous éprouvez des difficultés, nous vous recommandons de faire appel à un prestataire spécialisé. En effet, nous ne serons pas en mesure de vous fournir une assistance.
Je n'ai pas un centime à mettre sur la table auprès d'un prestataire. J'ai même été obligé de mettre un peu de pub, car 700 € de donations en 17 ans, ça n'incite pas à travailler tant.
Cela dit, que fais-je ?
c'est transparent, et au pire le rollback est instantané #itsgonabealright
yep,aies confiance :)
en ftp, `/.ovhconfig`:
```text
app.engine=php
app.engine.version=7.2
http.firewall=none
environment=production
container.image=stable
```
1mn d'attente et c'est pris en compte
retour en arrière: ctrl+z ;)
tu n'étais pas en ligne au siècle dernier (il me semblait)?
Si. Depuis 1999 (et même 1997 de manière confidentielle/non publique).
Je viens de passer en legacy php 7.3
> La modification de configuration de votre hébergement mutualisé a bien été prise en compte.
Je teste.
```text ```text
curl --head -XGET --user-agent firefox https://assiste.com
HTTP/2 301
content-type: text/html; charset=iso-8859-1
location: https://assiste.com/..Dossier.html
```
quelle est cette redirection: `https://assiste.com/..Dossier.html`?
au niveau du .htaccess? ```
> et même 1997 de manière confidentielle/non publique
pages free?
j'étais peut-être ton seul lecteur de l'époque? :o))
La page index.html de chaque répertoire, y compris à la racine, est renvoyée (par un Canonical) sur la même page nommée ..Dossier pour une raison de classement alpha du contenu de chaque répertoire qui est un dossier sur un sujet unique.
J'ai dû, dans le temps, le faire avec des Redirect 301 dans le htaccess. Je virerais après vérification.
Yep ! Mais ma popularité vient d'en prendre un coup !
```text Canonical ne redirige pas mais indique à google quoi indexer
il y a encore une redirection dans .htaccess il me semble
c'est original, mais tu peux utiliser
```text
DirectoryIndex ..Dossier.html index.html index.php
```
dans le .htaccess, pour que ..Dossier.html soit le fichier index par défaut d'un répertoire
et cela permet aux moteurs un accès en un seul saut sur le domaine assiste.com
certains moteurs aiment ça ```
Merci, Kyodev.
A faire dès que tous les ..Dossier seront créés.
Le .ovhconfig n'est pas modifié (mis à jour) après modification depuis mon espace client.
Je le modifie et l'upload.
> app.engine=php
> app.engine.version=7.3
> http.firewall=security
> environment=production
> container.image=stable
Rien de changé. Point d'image à point.
Est-ce que je tente un 7.2 ?
tentons , comme indiqué, il me faudrait un sous domaine de test pour faire un ticket à mes administrateurs.
linux interprète le . comme un htaccess ou un .ovhconfig.
à creuser.
> A faire dès que tous les ..Dossier seront créés.
dans la ligne indiquée: ..Dossier.html est prioritaire sur index.html puis index.php prend le relais (en cas d'absence du fichier immédiatement prioritaire)
> Le .ovhconfig n'est pas modifié (mis à jour) après modification depuis mon espace client.
vérifie que tu n'as pas un fichier `.ovhconfig` dans la racine du site (www?)
il serait prioritaire et le manager Ovh ne le prend pas en charge
gardes juste le `.ovhconfig` tout en haut
7.3 ne peut pas être en cause
firewall... c'est mal foutu sur Ovh, un mod_security mal configuré, rien à voir avec un firewall!
commence à tester avec none?
Passé en 7.2 dans ovhconfig et configuration dans mon espace client.
Rien de changé (sauf s'il faut un délai).
Répertoires en droits 0705 et fichiers en 0604
À oui, AntoineB1
J'ai cherché un peu. Linux et Unix interprètent tous fichiers/répertoires dont le nom commence par un point comme un objet caché. Mais cela concerne l'admin ou celui qui est à la console (du serveur, en l’occurrence), pas les fichiers d'un domaine servis par Apache, non ? Les fichiers des clients (des domaines hébergés) ne doivent pas être cachés à Apache (enfin, en mutu je pense, car le webmasteur/admin ne peut bricoler la config du serveur, mais la config de son hébergement). J'ai bon ou j'ai tout faux, là ?
> Rien de changé (sauf s'il faut un délai).
humm... php n'intervient pas pour afficher une image, du moins pas dans le cas étudié
délai 1 à 2 mn pifométrique
firewall et image sont des paramètres plus bas niveau, donc potentiellement influants
> pas les fichiers d'un domaine servis par Apache
oui, sauf .htaccess (convention propre à apache)
le fichier *"caché"* est une indication pour un affichage
le choix est possible, facilement
Si, j'ai un .ovhconfig à la racine et, dans .htaccess, un
> #Forcer appels AVEC www vers SANS www (SEO - évite la qualification en duplicate content)
> RewriteCond %{HTTP_HOST} ^www.assiste.com$ [NC]
> RewriteRule ^(.*) https://assiste.com/$1 [QSA,R=301,L]
Où doit être l'ovhconfig ?
Passé le firewall à none
> app.engine=php
> app.engine.version=7.2
> http.firewall=none
> environment=production
> container.image=stable
> Où doit être l'ovhconfig ?
ta racine est `www`?
.ovhconfig doit-être au dessus de `www` pour que le manager le gère
le `www/.ovhconfig` est à supprimer sauf besoin spécifique
pour les redirections SEO du .htaccess, peut mieux faire ;)
mais c'est pas la priorité du jour, et il faudrait que les ...Dossier.html soient gérés autrement, comme suggéré
Ben non ? Le domaine est assiste.com. Je ne veux pas entendre parler de www qui est un sous-domaine. D'où le
>
Compris.
Au-dessus de www. Fait.
Et le .htaccess ? Au-dessus aussi ?
```text humm, je parle de la racine du site, le dossier, en FTP
pour être un peu plus propre et éviter un saut inutile (drosophilement parlant pas top en SEO), c'est pour cela que je te suggère le directoryIndex pour gérer les ..Dossier (qui ne devrait ***surtout*** pas être indexés)
beurk:
```text
curl --head http://assiste.com/
curl --head http://www.assiste.com/
curl --head https://assiste.com/
curl --head https://www.assiste.com/
locations utilisées:
https://assiste.com/
https://assiste.com/..Dossier.html
```
2 sauts constatés ```
J'ai bien fait de venir prendre des leçons.
Que dois-je faire pour éviter le beurk beurk beurk ?
Pour les images à point, toujours la même chose.
pour le beurk, juste directoryIndex et suppression redirection .htaccess, à priori
pour les points... antoine avait proposé:
> linux interprète le . comme un htaccess ou un .ovhconfig.
j'avais pas vu, pas linux, linux s'en fout royalement
Apache oui, mais j'ai testé l'image avec point, elle est listée ET affichée
la restriction Apache doit porter sur le mime type txt j'imagine
```text ```text
curl --head https://assiste.com/404.php
HTTP/2 200
content-type: text/html; charset=UTF-8
x-powered-by: PHP/7.2
```
à priori, tu es bien en php7.2, pas de firewall, donc ton .ovhconfig semble actif et j'imagine que l'on peut te croire si tu indiques que tu as l'image stable
si Antoine veut tester les images à points: http://test.xn--chauffeur-priv-rennes-o5b.com/
hors sujet:
théoriquement, ton 404.php, devrait sortir un code HTTP/404 et non 200
voir https://www.php.net/manual/fr/function.header.php ```
je reste sur ma position d'un besoin d'un sous domaine de test coté @PierreP8
+ le test croisé de @kyodev
j'aurai assez d'info.
Wikipedia : https://fr.wikipedia.org/wiki/Fichier_et_r%C3%A9pertoire_cach%C3%A9 https://fr.wikipedia.org/wiki/Fichier_et_r%C3%A9pertoire_cach%C3%A9
> Sous Unix, Linux, et les logiciels prévus pour ces systèmes, les fichiers cachés sont des fichiers dont le nom commence par un point (.). Ce sont le plus souvent des fichiers de configuration (exemple : .htaccess pour apache, .bashrc pour bash, etc.) ou des répertoires contenant des fichiers de configuration (exemple .ssh pour SSH, .kde pour KDE, .gconf pour GConf, .mozilla et .thunderbird pour des logiciels de Mozilla, etc.). Les fichiers cachés peuvent être aussi :
> des fichiers contenant l'historique des commandes pour un shell Unix, ou les commandes SQL (par exemple pour l'outil psql de postgreSQL) ;
> une corbeille (répertoire trash) contenant des fichiers sur lesquels il y a eu une demande de suppression via l'interface graphique ;
> fichier lock utilisé par LibreOffice (exemple .~lockTOTO.odt# pour un fichier TOTO.odt)
> La commande ls par défaut n'affiche pas les fichiers et répertoires cachés (il faut préciser ls --all).
> Ces fichiers se retrouvent également sous Windows, pour les applications portées concernées (exemple : apache).
tu veux démontrer quoi là?
linux **n'interprète RIEN**
tu veux démontrer quoi là?
linux **n'interprète RIEN**
```text
file .NET_Version_Detector.png
.NET_Version_Detector.png: PNG image data, 170 x 72, 8-bit colormap, non-interlaced
file ..htaccess
.htaccess: UTF-8 Unicode text, with very long lines
file ..ovhconfig
.ovhconfig: ASCII text
```
donc selon le logiciel utilisateur (explorateur, Apache ou autre), selon les mimes types des fichiers concernés et des directives d'affichage:
**LE LOGICIEL** interprète et agit en conséquence
l'ami wiki ne dit pas l'inverse ou il faudrait corriger
GNU/Linux est le système, bas niveau, il n'agit pas sur l'affichage
De ce que j'ai compris, mais sans doute de travers, ce n'est pas un problème d'affichage, mais un problème de mise à disposition du fichier par le logiciel serveur Apache.
Il n'y a pas d'affichage parce que le serveur ne donne pas le fichier au client (navigateur) depuis mon serveur, alors qu'il le fait sur ton serveur.
Il y a, certainement, une différence de paramétrage (privilèges ?).
Toutes les images commençant par un point, dans les articles sur le .Net, qui ont toujours illustré ces articles ne s'affichent pas non plus, quel que soit le répertoire où elles se trouvent.
Création d'un sous-domaine : tests.assiste.com
Un répertoire racinetests
Attendre 2 heures (propagation vers DNS OVH et les plus proches) et régénérer le certificat.
```text > ce n'est pas un problème d'affichage
nous sommes d'accord, pas de *"caché"*, mais Apache n'interdit pas l'accès non plus à ces fichiers, sauf .htaccess ou autres fichiers configurés
voir http://test.xn--chauffeur-priv-rennes-o5b.com/, fichier .text (vide, texte)
> sur ton serveur.
un serveur sur un mutu Ovh, théoriquement, le même que le tien
(pas de propagation lors de la création d'un sous-domaine)
@AntoineB1 peut intervenir ```
tests.assiste.com
Forbidden
You don't have permission to access / on this server.
+ j'ai pas de droit d'importer de données, possible de mettre deux images :)
Sur le site Apache
https://httpd.apache.org/docs/2.4/fr/mod/directive-dict.html
> ## extension
> En général, c'est la partie du nom de fichier qui suit le dernier point. Cependant, Apache reconnaît plusieurs extensions de noms de fichiers ; ainsi, si un nom de fichier contient plusieurs points, chacune des parties du nom de fichier séparées par des points et situées après le premier point est une extension. Par exemple, le nom de fichier fichier.html.en comporte deux extensions : .html et .en. Pour les directives Apache, vous pouvez spécifier les extensions avec ou sans le point initial. Enfin, les extensions ne sont pas sensibles à la casse.
J'espère qu'il ne se met pas à prendre .net comme une extension.
Je continue de spéculer ? Allez... Microsoft a mis un © sur ces noms de fichiers (moouuaaarrrfff !)
Merci à vous deux.
Cordialement,
tu lis ce que j'écris?
tu vas voir le test que je fais QUE pour toi?
tu verras tout les cas de figures que tu nous ressors
les doc des autres n'apportes rien, tu n'es pas dans le cas d'une extension verrouillée par Apache
> j'ai pas de droit d'importer de données
dossier racine?
manager Ovh/hébergement/multisite: ne doit pas être `.`, `tests` à priori
antoine a dit:
> j'ai pas de droit d'importer de données
dossier racine?
manager Ovh/hébergement/multisite: ne doit pas être `.`, `tests` à priori
Les fichiers "cachés" sont cachés aux yeux de la commande "ls" et des commandes Linux, mais si on spécifie le nom du fichier dans une string explicitement, la string d'une image dans le html ou autre, ils ne sont pas cachés. Si ça déconne c'est pour une autre raison mais ce n'est pas à cause de la notion de fichiers cachés. Cette notion n'a de sens que pour l'OS, pas pour le php ni autre langage serveur.
le dossier racine est bien racinetests coté multisite et coté serveur...
> Les fichiers "cachés" sont cachés aux yeux de la commande "ls
même pas...
`ls -a`
un explorateur: `ctrl+h`
il manque un fichier index?
ou un `Options -Indexes` dans un dossier supérieur?
Corrigé
Effacé
Autre chose à faire ?
je pense que antoine voulait un espace indépendant, car il a peur de tout casser :)
change le dossier racine de tests.assiste, avec `tests` par exemple
(`www` étant la production en cours)
Effacé
heu.. une erreur d'image?
ok, j'ai mis un faux index. un .test.txt qui marche.
dans l'attente de l'upload d'une image :
Manchots montés
.avatar_300.png
avatar_300.png
le dossier est chez mes administrateurs.
Merci, AntoineB1.
Cordialement,
Pierre
les administrateurs y arrivent avec un jpeg, et indique que ce n'est pas coté serveur mais coté navigateurs...
tests°assiste°com/°test.jpg
http://tests.assiste.com/.test.jpg
Sur tous les navigateurs en même temps ?
Ils ont tous implémenté une règle en même temps ?
Une nouvelle règle émanant du W3C ?
Je ne sais pas, le type de chiffrement du png peut être;
http://tests.assiste.com/.test. png est ok
http://tests.assiste.com/.test.png
**CE N'EST PAS POSSIBLE**
le manchot, c'est mon image, selon les conditions de Pierre
elle s'affiche depuis des années
**y compris sur hébergement OVh**
as tu pris le temps de regarder MON lien de test?
http://test.1o5b.com/o5b.com/
les admins Ovh font peur dans leur capacité à investiguer...
je les relance
:) merci
C’est ce que laissent entendre les admins ? Tous les clients donc c’est pas nous, c’est PNG !
Le coup des virus cachés dans des formats d’images existe depuis 2002. C’est « alcopaul » (un jeune philippin) qui avait produit un POC (il l’avait appelé « Perrun ») et l’avait filé aux éditeurs d’antivirus, sans jamais développer de virus en suivant cette technologie (d’autres s’y sont engouffrés) et de nombreux formats d’images (en fait, tout ce qui n’est pas du bitmap (raster)) peuvent être manipulés pour véhiculer un virus (nécessitant ou non un programme compagnon injecté à l’aide d’un cheval de Troie).
C’est le même principe que dans le format PDF. On produit un encodage pour forcer l’interpréteur, qui le décode, à fabriquer du code malicieux (sans s’en rendre compte), ou on cache un lien qui va s’ouvrir à l’insu de l’utilisateur et de son client.
Tous les antivirus (au moins les bons) le savent et aucune image n’est ouverte sans passer par la sandbox de l’antivirus lorsque son hashcode n’est pas répertorié.
En plus, il y a d’autres formats que PNG pour jouer aux virus. Ce n’est pas dans cette direction, je pense, qu’il faille chercher.
Le 24 mars 2016, Kaspersky écrivait : des virus dans les images PNG
https://securelist.com/png-embedded-malicious-payload-hidden-in-a-png-file/74297/
Ce qui m’étonne, c’est que cela touche tous les clients. Je vois plus un problème consécutif à l’application/implémentation d’un patch qu’une règle générale (d’autant que je n’ai trouvé aucune alerte PNG).
je n'ai pas d'anti-virus, et je vois le souci chez TOI avec MON image qui fonctionne ailleurs chez Ovh
ma curiosité est à son comble
Observation :
Les navigateurs plantent tous et Firefox explique qu'il s'agit d'un problème d'erreurs dans l'image.
Regardez les deux images du manchot en liste dir dans le sous-domaine tests.
Je les ai uploadées avec FileZilla à jour (donc en FTP)
.avatar_300.png pèse, sur le serveur, 67.985 octets
avatar_300.png, la même image, pèse 68.222 octets
Cette différence de poids n'a aucune raison d'être, non ?
Mais le problème est né avant.
bien vu
ce ne peut pas être ton client FTP?
tu peux essayer avec un autre client ?
ou le manager OVh/Hébergement/FTP: ftpExplorer?
https://i.imgur.com/wpQTENO.png
Je vais regarder cela dans la soirée, mais le problème a été détecté alors que je n'avais pas touché aux images hébergées depuis des années et que cela fonctionnait parfaitement.
Peut-être que cela c'est produit lors du déplacement de l'hébergement (changement de data center, copie du serveur sur un autre) qui a eu lieu il y a quelques mois et que je ne m'en suis aperçu que maintenant.
ce n'est pas une erreur du à un transfert puisque aujourd'hui, une image valide, ne fonctionne sur TON hébergement :/
c'est vraiment étonnant ton histoire
```text Gravelines HTTP2 oui
```text
curl --head https://test.xn--chauffeur-priv-rennes-o5b.com/.avatar_300.png
HTTP/2 200
``` ```
à plusieurs on les aura toutes eues?
Je viens de faire un truc simple :
Sur le serveur, je vire .avatar_300.png, qui pèse 67.985 octets
Je renomme avatar_300.png, qui pèse 68.222 octets, en .avatar_300.png
J'upload avatar_300.png de ma machine sur le serveur avec filezilla et elle pèse aussi 68.222 octets.
Lecture :
Sans point
https://tests.assiste.com/avatar_300.png
À point
https://tests.assiste.com/.avatar_300.png
Il n'y a plus d'erreur de lecture - il n'y a plus d'erreur de l'image.
Poursuite du test :
Je renomme, sur ma machine, .avatar_300.png en .avatar_301.png
Cette image pèse toujours 68.222 octets
Upload avec filezilla
.avatar_301.png pèse 67.985 octets
Le mot de CAMBRONE ! En 5 lettres !
Comparaisons entre répertoire images local et répertoire images serveur.
J'ai demandé à FileZilla de conserver l'horodatage des fichiers transférés, mais FileZilla de donne pas la date de création côté serveur. Ce serait intéressant. Ces images n'ont pas été changées depuis leur dernières créations/modifications et sont uploadées dans la foulée.
## Les images à point. Aucune n'a la même taille localement et sur le serveur !
https://assiste.com/Assiste/media/Divers/Apoint-1.png
## Les images sans point. Toutes ont la même taille localement et sur le serveur !
https://assiste.com/Assiste/media/Divers/Sanspoint-1.png
Je chercherais bien la cause au 24 janvier 2019 (transfert à Gravelines) avec conséquences se poursuivant aujourd'hui :
http://assiste.forum.free.fr/viewtopic.php?f=154&t=33927
**## Arrrggghhh !**
Je viens de transférer toutes les images à point, avec FileZilla, en type de transfert "binaire" au lieu d'"automatique" (j'ai toujours utilisé le mode "automatique" depuis... que FileZilla existe) et tous les fichiers, côté serveur, retrouvent leur taille.
https://assiste.com/Logitheque/.Net_1.0_Tous_les_telechargements.html
C'est une solution, mais ce n'est pas clair.
Note :
L'illustration que cherche à faire ce forum OVH pour fabriquer un snippet de la page indiquée cherche une image au mauvais endroit.
si j'ai compris
* fileZilla (Fz) en mode binaire c'est Ok?
* Fz mode auto c'est mauvais? (il y a eu il y a peu un truc similaire ici, me souviens plus si avec image)
cette taille différente, à l'arrivée sur le serveur expliquerait tout, et ton client en cause serait une bonne hypothèse
***mais ça n'explique le changement que tu dis avoir subi d'un coup?***
j'ai toujours utilisé Fz en mode auto depuis... longtemps
mais depuis 6ans, c'est seulement sur Linux
ayé: https://community.ovhcloud.com/community/fr/resolu-2000-fichiers-corrompus-sur-mon-ftp?id=community_question&sys_id=68057100e5d286d02d4c0165b3e76626
ayé: https://community.ovhcloud.com/community/fr/resolu-2000-fichiers-corrompus-sur-mon-ftp?id=community_question&sys_id=68057100e5d286d02d4c0165b3e76626
je découvre...
mode auto par défaut:
**traiter les fichiers dont le nom commence avec un point comme fichier ASCII**
https://i.imgur.com/qEDBx8S.png
ce qui n'explique pas alors pourquoi lors de mon essai, ça n'a pas été transféré en mode ASCII :/ ?
hypothèse: car sous Linux, le mime type est vérifié par Fz (`file`)?
https://wiki.1project.org/Data_Typeproject.org/Data_Type
Merci Kyodev,
https://wiki.1project.org/Data_Typeproject.org/Data_Type
C'est écrit en toutes lettres :
> Compared to ASCII type, binary type is the easier one: the file is just transferred as-is, and no line ending translation is done.
> So when you are not sure what to use, always go for binary type.
Si je comprends bien, le serveur sert un fichier au client en modifiant à la volée le contenu de l'objet en fonction du type du client (Linux; Windows; etc.). Par exemple, les sauts de ligne, sous les clients Linux, sont uniquement un LF (Line Feed) tandis que sous les clients Windows, les sauts de lignes sont CR (Cariage Return) + LF (Line Feed).
Mais si on fait un upload en type automatique, FileZilla choisit automatiquement le type Linux pour les fichiers dont le nom commence par un point, car il pense, implicitement et à tort, que ce sera obligatoirement un fichier à servir pour un client Linux et modifie déjà, à l'upload, son contenu. C'est une erreur de décision - c'est un choix "à priori", en subodorant fautivement quelque chose qui devrait être pris en charge par le serveur (download) et non par l'upload avec le FTP (peut-être avec l'idée généreuse d'accélérer l'envoie au client [le download futur] sans passer par la conversion).
FileZilla ferait mieux de disposer d'un module de minification, qui accélèrerait réellement le service au client, protègerait la bande passante de l'hébergeur et l'occupation disque sur les serveurs, au lieu de jouer avec nos objets sur des supputations (nouvelles, car cela n'existait pas dans le temps).
3 jours et 85 messages !
Je vais en profiter pour tout relire et mettre à jour puis tout ré-uploader en binaire.
Je vais aussi faire un résumé à FileZilla et me faire expliquer quand c'est apparu et pourquoi.
Si j'ai une réponse, je ne manquerais pas de la reproduire ici.
Merci à tous les intervenants,
Cordialement,
Pierre
PS : je suis en FileZilla 3.42.1 Windows.
je t'ai mis le wiki fileZilla... c'est la spécification Ftp tout simplement
il y a transformation au départ/arrivée, si les deux systèmes diffèrent , ça peut poser le souci
Fz a aussi la config par défaut cochée que je n'avais jamais vue, pour toi il te suffit de décocher: *traiter les fichiers dont le nom commence avec un point comme fichier ASCII*
**mais il y a quelque chose que je ne comprends pas, tu dis que le souci est apparu seul ?**
Re, Kyodev,
Hier, avant de corriger les ups à point, je l'ai paramétré ainsi :
https://assiste.com/Assiste/media/Divers/FileZilla_parametrage_09.png
C'est bon ?
J'étais en automatique avec les deux cases cochées (fichiers sans extension et fichiers dont le nom commence par un point)
Sincèrement, je n'ai aucun souvenir d'avoir touché à ces paramètres depuis que j'ai installé FileZilla la première fois, il y a des années.
J'ai toujours utilisé FZ et je monte toujours des répertoires entiers.
Il est rarissime que je monte un fichier unique, et je le faisais alors avec mon vieil Adobe Golive dont j'avais acheté la suite CS (CreativeSuite) en me fendant d'une fortune (je suis un légaliste acharné).
Je me souviens, par contre, il y a peut-être 2 ou 3 ans que, tout d'un coup, je n'ai plus pu faire d'upload (de connexion FTP) avec Golive. Je n'ai pas cherché à comprendre (toujours pressé !) et tout passe par FZ depuis, y compris les up ponctuels.
Fichiers sans extension (ou dont l'extension est trompeuse) : ils ont un type qui peut être détecté par analyse de ses empreintes (paterns).
TrID le fait gratuitement, en mode local ou en ligne. VirusTotal s'en sert.
https://assiste.com/Logitheque/TrID.html
Cordialement,
Pierre
j'ai toujours utilisé Fz sans me poser de questions, par défaut...
Fz ne va pas utiliser de programme tiers pour le type de fichier, c'est le système qui va fournir cette info, à ma connaissance, sur windows, c'est l'extension :/
Linux détecte le mime type pour chaque fichier, quelque soit son nom
**mais ça ne m'explique pas pourquoi tu as dit que c'était apparu tout seul?**
Parce que je n'ai rien changé, nulle part, depuis des années, et que les images à point s'affichaient (j'avais tout de même vérifié/relu en ligne mes pages lorsque je les ai uploadées avec leurs dépendances.
Ce que je peux dire, c'est que je viens de m'apercevoir d'un problème inconnu, par hasard, portant sur l'altération d'objets.
Ce que je ne peux pas dire, c'est la date d’occurrence. Un passé entre 48 heures et 2 ou 3 ans. Je n'ai aucune souvenance d'une opération qui aurait porté sur :
1. Modification des réglages de FZ, voire réinstallation neuve de FZ sans reconduire de précédents paramètres.
2. Réupload de tout ou partie du site. Je me souviendrais d'un truc pareil. Et pourquoi aurais-je fait un truc pareil ?
Le problème vient de me sauter à la figure, est solutionné, est expliqué (avec votre aide), mais son apparition n'est pas expliquée. L'opération Gravelines, si le transport des données ne s'est pas fait avec un banc de copie des volumes disque, mais par un transfert Internet (sous un logiciel de transfert), me plairait bien (je n'accuse personne et ne rencontre strictement aucun problème OVH ni d'hébergement ni de continuité du service, depuis le début de mon hébergement, et je les recommande).
Cordialement,
Pierre
très curieux, seul Ovh saura apporter des précisions
la copie via le net se s'est pas faite en Ftp, il y a plus efficace, et de Linux à Linux, pas de soucis de conversion de fin de ligne
Je suis surpris que FZ fasse de la conversion du format PNG. Cela m'étonnerait que l'on y trouve des LF/CR convertible en LF selon le système hôte.
Là, je pense qu'il y a une faute côté FZ.
PNG est PNG, rien d'autre, et ne dépend d'aucun OS, heureusement, comme aucun autre format d'images, d'ailleurs.
On ne voit pas, on ne peut même pas imaginer intellectuellement, un PS demander, lors de "Enregistrer pour le Web" une question additionnelle du type "Pour quel système hôte".
Cordialement,
Pierre
> Je suis surpris que FZ fasse de la conversion du format PNG
relis ce message: https://community.ovhcloud.com/community/fr/probleme-avec-certaines-images-sur-le-serveur?id=community_question&sys_id=7033bdcc355a82d0f078b41a47e1f087
ce sont les options par défaut pour les fichiers commençant par un `.`
ET tu as choisis ça pour le nommage de tes images :/
> Là, je pense qu'il y a une faute côté FZ.
NON, parce que c'est clairement dit
ET sous linux, c'est une convention souvent utilisées pour tous les fichiers de paramétrage, genre .htaccess, .gitignore, .eslintignore, .bashrc ...
si faute, c'est l'utilisateur qui ne tient pas compte du système hôte, càd Linux (ou unix like, BSD, MacOsX, Android...) et windows qui n'a pas voulu se conformer aux standards comme l'a pu faire Apple par exemple
UNIX existait avant Windows, et celui-ci a fait croire à beaucoup que la vie était mono système...