Hmm, je ne suis pas sûr de bien comprendre.

Ça ressemble à un serveur IIS qui cherche un fichier sur le serveur (et qu'il ne trouve pas, donc) et qui affiche l'erreur au client.

Comme si tu faisais en PHP un fopen("trucquinexistepas.conf") avec l'affichage des erreurs activés : le client verrait le même genre de message.

Ou alors il y a un truc que je loupe complètement ?

Non, tu loupes rien, c'est bien lui le pebkac. Ensuite, pebkac aussi pour le webmestre puisque le site est mal configuré.

Du même avis que FBM, rien que le nom du path devrait te faire comprendre qu'il s'agit du serveur, et pas du client (HostingSpaces, wwwroot, webform).

Bon en plus je viens de faire quelques tests, et effectivement il semble impossible d'inclure un fichier local du client dans une page web (ce qui semble logique, car sinon n'importe quel site pourrait lire les fichiers de ses visiteurs simplement en devinant le nom).

Pour les webmasters, gros PEBKAC quand même car foirer un déploiement en prod à cause d'un fichier de conf inexistant, ça veut dire que ça n' a pas été testé (PEBKAC 1) et afficher les erreurs du serveur aux clients en prod, c'est mal (PEBKAC 2). PEBKAC1 + PEBKAC2 => Gros PEBKAC.

@FBM : Et tu fais quoi des cookies ? Ce sont bien des fichiers locaux inclus dans le traitement distant.

<chipote>
il y a aussi le raccourci fichier ini = fichier de conf.
dans Joomla!, les traductions sont stockées dans un fichier ini par exemple.
Bon ok, l'utilisation classique c'est pour la config, mais faut pas généraliser trop vite hein?
</chipote>

et oui il s'agit d'un chemin local, mais c'est le serveur qui l'exécute donc chemin local au serveur. A moins que krosoft ait un moyen de faire exécuter le code du serveur par les navigateurs.... un doute et une peur m'habitent d'un seul coup la, on parle de krosoft quand même...

Oui, wwwroot est typique de IIS.

@mini : cette idée que les cookies sont des fichiers est fausse.

Les cookies sont des paires (clé => valeur), avec une date d'expiration et d'autres paramètres (HTTPS only par exemple).

Que certains browsers choisissent de les stocker sous forme de fichier, pourquoi pas, mais ça n'en fait pas des fichiers pour autant.

Exemple : Firefox et Chrome ne stockent pas les cookies sous forme de fichiers.

Quand bien même on prend le cas où les cookies sont stockés sous forme de fichiers, ça n'a rien à voir avec le cas décrit : on parle d'inclure un fichier arbitraire en fournissant son chemin complet. Les cookies sont envoyés automatiquement par le navigateur à chaque requête en fonction du domaine et du protocole utilisé.

@FBM : Il me semble que le HTML5 propose des possibilités pour accéder au filesystem local, non ? (c'est une vraie question, vu que je n'ai pas lu la norme intégralement...)

@Mat : je ne connais presque pas HTML5, mais il me semble que ce dont tu parles, c'est le session storage, un espace de stockage lié à une session sur un site web, donc pas d'accès au filesystem local.

À faire confirmer par un maître du HTML5 :)

@achille: le message d'erreur spécifie qu'il s'agit d'un "settings file".

Je ne suis pas un maître, mais en effet HTML5 propose une ou deux API permettant de stocker des données en local : localStorage pour stocker des plus gros volumes sous forme de map et une autre API pour des données structurées qui a été je crois abandonnée (WebSQL de mémoire).

Rien à voir avec le PEBKAC j'ai pas assez de connaissances pour le comprendre.
C'est juste pour dire que j'aime bien l'avatar de pbx.

Voilà.
repars dans son monde

Un navigateur peut tout à fait afficher du contenu local dans une page distante. J'ai ainsi déjà vu des pages web où des images n'étaient pas chargées, la source se rapportant à une image sur l'ordi de l'auteur. Pour celui-ci, évidemment, tout paraissait en ordre puisque ses images apparaissaient.

Il y a aussi une vieille démo Javascript qui affiche le contenu des répertoires de l'ordi local.

Par contre, sauf faille, il n'est pas possible pour le serveur d'accéder à un fichier local.

Ça fait quelque temps que les navigateurs refusent de charger des fichiers locaux si la page n'est pas elle même chargée localement.

Le test que j'ai fait consistait à essayer de charger une image de mon disque dur depuis une page distante. Ça ne marche pas, et voici ce que firefox annonce dans la console d'erreurs :

Erreur de sécurité : le contenu situé à http://88.191.xxx.xxx/test-img-int.html ne peut pas charger de données ou établir un lien vers file:///d:/test.png.

@1138, je précise au cas où : la même page chargée depuis mon disque dur affiche l'image correctement.

peut être mais windows déduit le type de fichier par rapport à l'extension même si le contenu est complètement différent. Prends un fichiers texte de base, renomme le en .jpg et windows cherchera à l'ouvrir avec le logiciel d'images par défaut.

alors pourquoi penser que iis serait moins con ???

après j'ai jamais utilisé iis donc je sais pas si c'est un fichier de conf standard

En lisant vos commentaire je me pose la question : est-ce qu'un script javascript pourrait charger des données locales (donc sur le poste client) et envoyer tout ça sur le serveur via un webservice par exemple ?

@Acorah : non.

Au début du web, les contrôles faits par les navigateurs étaient beaucoup moins poussés.

Maintenant, la sécurité est leur principale priorité. D'où le cas que j'ai expliqué : impossible depuis une paire d'années de charger une simple image locale depuis une page web distante, ce qui marchait très bien avant.

Donc, sauf vulnérabilité, c'est impossible.

@FBM

En effet, je viens de tester la chose avec différents navigateurs : l'image ne s'affiche pas (sauf avec IE6).

Avec HTML5 et son API Web Storage, il est effectivement possible de stocker des choses plus vastes que de simples cookies sur le poste client.
Mais ce n'est pas un accès au système de fichiers du poste client.

C'est juste pour stocker des informations de manière plus riche et plus structurée que de simples cookies, mais ça reste dans ce que j'appellerai le scope navigateur (attention énorme abus de langage).

Le fonctionnement est plus ou moins identique aux cookies, car c'est toujours des paires clés/valeurs. Il y a localStorage qui marche avec une date de validité, et il y a même sessionStorage pour stocker le temps de la session, sans date de validité définie.

Je n'ai pas testé ni étudié en profondeur, mais paraît-il que c'est un stockage plus rapide, et plus sécurisé que les cookies.
(Je ne suis pas sûr par contre que la spécification soit définitive et validée)

En effet... du coup c'est moi le PEBKAC.


Pour info, l'erreur n'a toujours pas été corrigée, et se situe dans la partie "vente" du site, la rendant inutilisable.

J'ai testé rapidement localStorage et je ne crois pas qu'il y ait de limite de temps ; ça ne serait pas plutôt la session qui est limitée en temps? Cela me semblerait plus logique.
Par contre en effet pas moyen d'accéder à ce que l'on veut, en effet toutes les données accessibles sont liées à l'URI de la page et doivent donc avoir été crées par celle-ci.

M. Troll: Si par mal configuré, tu entends "utiliser un serveur IIS" ... ouais ok :D

La dernière fois que j'ai essayé, le HTML5 pouvait récupérer le contenu d'un dossier mais pas écrire et je ne suis pas sûr qu'il pouvait même lire les fichiers, ça reste assez limité.

En effet :
http://www.lais.be/exec/ic2web.exe?lcon=uk&page=/website/shop.htm

Message envoyé au responsable.

J'ai obtenu une réponse.

> Dear 1138,
>
> Thanks you so much for your remark! We've recently moved the Lais website to another provider and it turned out to be a problem with the access rights for the webshop program which we didn't have/noticed directly after moving the site.
> As a note: on request of Annelies of Laïs, the webshop isn't active anymore but we keep it running as a discography awaiting future steps to update the website.
> Currently all works again.
>
> Best regards,
> <Le responsable>.