5568 sujets

Sémantique web et HTML

Recette du jour :

Prenez un fichier HTML basique :


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>
<body>
test
</body>
</html>


Faites en deux versions :
- une avec l'extension de fichier .html ou .htm
- une autre avec l'extension .php

Hébergez ces deux fichiers quelque part.

Effectuez la validation du fichier .html depuis l'URL : Tout test OK. La bannière verte s'affiche.

Effectuez la validation du fichier .php depuis l'URL : Impossible de valider la page.
L'erreur "end of document in prolog" intervient sans que vous ne compreniez pourquoi.

A présent, oh, grands experts du WEB, si quelqu'un a une explication rationnelle à me fournir, je suis preneur.

D'avance, merci.
Bonjour, et désolé pour le manque de politesse.

Je ne mens absolument pas quand au contenu des pages.
Il n'y a rien d'autres. C'est justement un test pour essayer de comprendre l'erreur qui survient sur le reste du site.

Je ne préfères pas poster l'adresse du site client, de peur comme il est dit dans les règles que ce post soit mieux référencé que le site lui même.

Alsacréations est connu, ancien, et très bien codé, donc il est certain que ce sera le cas.

Je pense personnellement que selon l'hébergement, le validateur W3C n'arrive pas à récupérer le code source quand il a affaire à une page dynamique, avec une extension serveur .php, .asp, .aspx, .jsp etc...

J'ai lu aussi sur certains forums que certains ont pu valider leur page quelques heures plus tard, ou le lendemain sans problème. Je suis sceptique quand à ce point, et je crois en la robustesse du validateur W3C, mais pourquoi pas...
BatMen a écrit :
Je ne mens absolument pas quand au contenu des pages.
Il n'y a rien d'autres. C'est justement un test pour essayer de comprendre l'erreur qui survient sur le reste du site.
Le problème c'est que l'on a pas tous le loisir de créer les fichiers et de les uploader quelque part. Si je demande les pages en ligne c'est pour poouvoir faire les tests moi même, et avoir accès au message d'erreur complet.

Pour qu'une url ne soit pas interprétée comme telle et donc pas référencée, tu peux mettre un tiret juste devant (-), collé à l'URL.
Modifié par Laurie-Anne (30 Dec 2009 - 15:51)
Voici l'adresse en plusieurs bouts :

www
point
centr
elec
point
net
slash
test.html
OU test.php

Cordialement.
Modifié par BatMen (30 Dec 2009 - 16:00)
En effet, pour le fichier php il reçoit un fichier vide, d'où les warning et l'erreur (on le voit en cochant la case "Show Source" du validateur).

J'ai testé en local, pas d'erreur, mais je pense que webdevelopper envoie un fichier html.

Par contre, j'ai aussi testé depuis un repertoire online, et là, pas d'erreur non plus.

==> Il n'y aurait pas un problème avec ton serveur php, qui refuserait par exemple les appels à ses pages depuis l'extérieur ? (je ne sais pas si c'est possible Smiley cligne )

Edit : pour ceux qui voudraient tester depuis un autre serveur, c'est là : -www.mistike.com/tests/
Modifié par mistike (30 Dec 2009 - 17:10)
Ca m'épate.
Moi aussi je pense que ça vient du serveur.
Modifié par MoOx (30 Dec 2009 - 17:06)
Modérateur
Bonjour,

C'est assez mystérieux en effet. As-tu essayé différentes variantes de code, par exemple en changeant le doctype ou l'encodage de caractères pour de l'iso-8859-1? Ça provient peut-être aussi de la façon que le fichier PHP a été sauvegardé?
Modifié par Tony Monast (30 Dec 2009 - 17:07)
Je pense que vous avez tous raison. Cela provient de l'hébergeur.

Dans tous les cas, j'utilise Web Developper avec Ctrl+Maj+A pour envoyer le code source et valider sans passer par l'URL.

Mais je serai curieux de savoir pourquoi tout de même.

En ce qui concerne l'encodage du fichier, il est bien en UTF-8. Et j'ai fait une copie de fichier entre le .html et le .php. Donc il n'y a à priori pas de soucis.

Merci de votre contribution. On ne peut pas dire que le topic soit résolu, mais je pense qu'il est inutile d'aller plus loin, étant donné que je peux arriver à mes fins autrement.

Cela dit, il semble que ce ne soit pas le seul hébergement qui réagit de cette manière au vu de la recherche Google
Modérateur
Vas-tu quand même vérifier auprès de ton hébergeur? Je serais curieux de connaître la raison technique derrière cette erreur...
Salut,

Tu as un serveur IIS et non Apache (donc pas prévu pour tourner avec PHP à la base, même si on peut l'utiliser en API), à mon avis, ça vient de là.
BatMen a écrit :
L'erreur "end of document in prolog" intervient sans que vous ne compreniez pourquoi.

Il me semble que j'ai déjà eu affaire à ce message, qui n'est autre qu'un bug du validateur qui ne met pas en cause la validité (ou l'invalidité) de ta page. Smiley smile
Je confirme que c'est bien un serveur IIS.

Je pense qu'en passant par une URL, le validateur du W3C doit se servir d'une fonction équivalente à file_get_contents en PHP. Et peut être que sur un serveur IIS, des restrictions par défaut ne permettent pas au validateur de récupérer le code source d'une page dynamique.

Je ne pense pas demander à l'hébergeur de chercher la cause de ce dysfonctionnement. Dans un contexte d'entreprise, ce serait une perte de temps, étant donné que je peux valider ma page en envoyant directement le code source (Ctrl+Maj+A sous Web Developper).

C'est comme les sourciers, les gourous, et certains phénomènes, il n'y a pas d'explication scientifique, logique, et pragmatique à toute chose Smiley ravi

Edit : Heureusement que je n'ai pas mis le site du client : Voir ici
Modifié par BatMen (31 Dec 2009 - 09:28)
Modérateur
BatMen a écrit :

Je ne pense pas demander à l'hébergeur de chercher la cause de ce dysfonctionnement. Dans un contexte d'entreprise, ce serait une perte de temps, étant donné que je peux valider ma page en envoyant directement le code source (Ctrl+Maj+A sous Web Developper).


Sans exiger une explication technique de l'hébergeur, je pense qu'il peut être très pertinent de leur en glisser un mot. Ce sera à eux ensuite de déterminer si c'est une perte de temps ou pas. L'idée est que si le validateur n'arrive pas à faire un équivalent de file_get_contents en PHP, qui sait si un jour tu n'auras pas à faire un script semblable pour récupérer des informations sur ton site. Ça peut être une source de problème plus tard, pour toi ou pour un partenaire. Toi, arrives-tu à faire un file_get_contents sur une page de ton site?

Il est possible aussi que ce soit le validateur qui à un bogue et que l'hébergeur ne puisse rien y faire. Étrangement, ce message d'erreur est documenté sur le site du W3C, mais il n'y a aucune explication qui lui est attaché.
Modifié par Tony Monast (01 Jan 2010 - 21:03)