(en local) Bug Apage, navigateurs, ou de l'OS ?

Version imprimable

Salut à tous :D

Je pensais il y a maintenant longtemps de ça résoudre ce même problème, faut croire que non.
Dans le genre bug incompréhensible, et bien j'ai jamais eu pire, alors pour l'expliquer ça ne va pas être simple.

J'ai tenté de réduire la situation de la manière la plus basique possible, soit une banale page HTML :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <a href="http://127.0.0.1/run/entree/index" title="azertyuiop">Actualiser</a> <html> <head> <title>RUN</title> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> <base href="http://127.0.0.1/run/" /> <script type="text/javascript" src="js/run.js"></script> <script type="text/javascript" src="js/reso_ecran.js"></script> </head> <body> <img src="images/fonds/run_small.jpg" title="azert" /> <img src="images/fonds/run.jpg" title="azert" /> </body> </html>
Le simple fait de mettre un contenu (un lien ici) avant (très important) le <html> provoque en cascade des erreurs sur l'import d'1 des 2 JS et sur les 2 images dans le body.
Dès que j'enlève ce contenu avant le <html>, plus du tout de bug.

Si je mets des URLs absolues et complètes (genre : -http://..../run.jpg) aucun problème.

En résumer : un contenu avant <html> + des URLs relatives de contenu importés provoque le bug.

Pour exemple, la requête HTTP pour rechercher run.jpg serait :
-http://127.0.0.1/run/images
C'est tout ??? Il manque le reste : run.jpg
Pourquoi donc le navigateur envoie t-il des URLs partielles ???

Si je supprime le cache, cookie, etc ... du navigateur, alors plus de bug du tout. Va comprendre pourquoi ?
Dès que je clique sur le lien, alors ça bug à nouveau, c'est systématique. :aie:
Quand je réactualise la page, pareil, ça bug.

Le pire, c'est que j'ai un autre projet quasi similaire, et je n'est pas du tout ce bug, je ne parviens même pas à le provoquer. 8O

A savoir que ce bug ce fait sur FF, IE, mais pas sur Chrome.
Et pour le moment, tout ce fait uniquement en local sur XP.

Là où je n'est pas d'explication aussi, c'est que sur FF les images sont quand même visibles (alors que les requêtes HTTP semblent erronées), mais sur IE elle ne le sont pas (des croix).

Tout porte à croire que c'est du coté navigateur que ça bug, mais ça en concerne au moins 2, et les plus utilisés.
De plus, pourquoi n'ai je pas ce bug dans l'autre projet dont le code est similaire ?
J'ai fais des tonnes d'essais ce week end, j'vous dis pas combien.
J'y comprends franchement rien à ce truc :cry:

La seule manière de ne plus avoir ce bug, c'est de mettre des URLs absolues est complètes à toutes les images, import JS, etc ..., ce qui ne me satisfait pas du tout.

Si vous avez une piste, des explications, alors là, :ccool:

13/12/2010, 14h21
RunCodePhp

Je rajoute 2 informations, sait on jamais si ce serait lié.

J'ai de la réécriture, et le .htaccess est comme ceci :

Citation:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /run/
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule !\.(js|css|jpg|jpeg|gif|png|ico|pdf|xml)$ index.php [PT]

Théoriquement, les images (jpg) et les JS entre autres ne devraient pas passer par le index.php avec ça.
Apparemment ce n'est pas le cas car pour exemple de l'image run.jpg j'obtiens l'erreur suivante :

Citation:

Call to undefined method Controllers_Entree::images()

Ca sous entend que le navigateur lancerait la requête HTTP : -http://127.0.0.1/run/images
Je ne vois pas d'autres explications, mais je ne vois pas comment résoudre ça.

Puis en appliquant la fonction apache_request_headers() pour voir ce qu'il y a coté entête, j'ai entre autre :
[Cache-Control] => max-age=0
Je n'est pas ça avec le projet qui ne bug pas.
Pourquoi 0 d'ailleurs, il me semble n'avoir rien défini à ce niveau.
Il y a peut être matière à exploiter ici, mais là encore je ne vois pas.

Toujours à la recherche du bug indéboggable :mrgreen:
13/12/2010, 14h37
boo64

Je comprends pas trop le but d'inserer du code html ici..8O
13/12/2010, 14h55
RunCodePhp

Citation:

Envoyé par boo64

Je comprends pas trop le but d'inserer du code html ici..8O

Exemple simple, chose que je fais quasi tout le temps, c'est un print_r() sur $_GET, $_POST, des echo sur toute sortes de donnée quand je suis en train de créer ou modifier quelque chose, tout ça dans le but de vérifier, etc ... tout ça un peu n'importe où.
Il me parais donc plus pratique de faire ça à l'endroit même où j'interviens, comme dans une classe par exemple qui elle est déclarée avant que le HTML soit généré, donc avant le DOCTYPE.

Les conséquences sont cependant dramatiques, car dans cet exemple, il n'y a que 2 images, mais dans la réalité, c'est largement plus, et ça provoque tellement d'erreurs que ça en devient ingérable.
Tout ça à cause d'un banal echo qui se voulait un moyen de débug, le comble finalement. :aie:

Ceci ne doit pas provoquer de telles erreurs, c'est pas possible cette histoire, mais je ne sais pas pourquoi. ;)
13/12/2010, 15h17
Benjamin Delespierre

J'ai rencontré un problème du même genre en faisant générer mes pages avec les classes DOM de PHP5 et en les faisant parser par une XSLT avant la sortie (ce qui me permet en outre de sortir le contenu sous plusieurs formats pour les mêmes vues).
J'ai solutionné le problème de la façon suivante: je me suis créé une classe capable d'attraper les erreurs natives de PHP sur le modèle d'un Observer (ça tombe bien, SPL fournit tous les prototypes nécéssaires). Ainsi, en étendant les fonctionalités de la fonction trigger_error, je me suis créé des fonctions de trace capable de se dispatcher sur la page à un endroit connu et/ou sur fichier (ce qui permet de faire des logs et du monitoring à l'execution des scripts).

En prime, j'ai gagné la possibilité de récupérer le contexte autours de mes erreurs (et d'enrichir ces contextes avec xdebug qui fournit notamment toute la callstack) ce qui me fournit des logs carrément explicites. Dans un projet de grande envergure, ce genre d'outils m'est apparu incontournable.
13/12/2010, 15h23
boo64

Si on suit tes pistes :

Citation:

13.2.5 Disambiguating Expiration Values

Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same resource that are different.

If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, and the Date header in its existing cache entry is newer than the Date on the new response, then the client MAY ignore the response. If so, it MAY retry the request with a "Cache-Control: max-age=0" directive (see section 14.9), to force a check with the origin server.

If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date header. This situation might arise because the cache is pooling responses from other caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry.
13.2.6 Disambiguating Multiple Responses

Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow through a different set of caches, a client might receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh.

Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response intentionally carries an earlier expiration time. The Date values are ordered to a granularity of one second.

When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older than the one for the existing entry, then the client SHOULD repeat the request unconditionally, and include

Cache-Control: max-age=0

to force any intermediate caches to validate their copies directly with the origin server, or

Cache-Control: no-cache

to force any intermediate caches to obtain a new copy from the origin server.

If the Date values are equal, then the client MAY use either response (or MAY, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap.

pas sur que ca apporte de l'eau a ton moulin!
13/12/2010, 16h23
RunCodePhp

Je suis actuellement en train de prospecter du coté FireBug, il y a vraiment des trucs bizarres :

Citation:

URL | Statut | Domaine
----------------------------------------
Get index | 200 Ok | 127.0.0.1
Get run.js | 200 Ok | 127.0.0.1
Get reso_ecran.js | 404 Not Found | 127.0.0.1
Get run_small.jpg | 404 Not Found | 127.0.0.1
Get run.jpg | 404 Not Found | 127.0.0.1
Get reso_ecran.js | 200 Ok | 127.0.0.1

Pourquoi donc le run.js ce fait correctement, et pas pour le reso_ecran.js ? 8O
Ils sont dans le même répertoire, leur liens sont identiques.

Pourquoi donc une 2ème requête HTTP pour le reso_ecran.js, dont la 1ère échoue et pas la 2ème ? ;)

Pour les 2 images, les 2 requêtes HTTP échoues, aucune 2ème tentative cette fois.

Ici, c'est quand je clique sur le lien.
Si j'actualise la page, tout est quasi doublé, en gros, ça rechercherait une 1ère fois les JS et images dans le cache (du moins apparemment), et là, c'est Ok (304 Not Modified).
Puis ça lance des requêtes HTTP, normal, j'actualise, et comme d'hab, des erreur 404 Not Found.

Je n'arrive pas à comprendre toutes ces incohérences, juste pour une histoire de contenu mal placé, même volontairement.
Les URLs sont bonnes, c'est une certitude, aussi bien pour les JS que les images.

Encore une fois, sur l'autre projet j'y met volontairement un contenu mal placé, pour tester justement, ce n'est pas pour autant que les éléments de la page (JS, images) ne sont pas récupérés.

Plus je cherche, moins j'comprends. :aie:
C'est la déprime :cry:
:mrgreen:
13/12/2010, 18h58
RunCodePhp

Pour encore apporter de l'eau au moulin (pour mieux me noyer tiens :mrgreen: )

FireBug confirme en quelque sorte que les requêtes HTTP ne sont pas correctes.
Je prends pour exemple les 2 reso_ecran.js, qui bizarrement se lancent 2 fois.

Celle qui est correcte :
GET /run/js/reso_ecran.js HTTP/1.1
Host: 127.0.0.1

Et celle incorrecte :
GET /run/entree/js/reso_ecran.js HTTP/1.1
Host: 127.0.0.1
Le navigateur rajoute dans l'URL entree/ ??? Va savoir pourquoi ???

J'insiste, sait on jamais.
Dès que je supprime le contenu avant le <html>, plus du tout de bug.
Ou alors, si j'utilise des URLs absolue et complètes plus de bug aussi.

Comment un truc pareil, aussi bateau peut il déboussoler un navigateur à ce point :calim2:
13/12/2010, 20h03
RunCodePhp

:yaisse:
Je crois que là, j'ai peut être une solution, sinon LA solution.

Le truc viendrait de l'URL de départ, des liens en général qui sont lié à la réécriture, de ma façon de faire, qui est très récente (modifié il y a peu).

Un lien actuellement est fait comme ceci : -http://127.0.0.1/run/entree/index
Donc sans de slash à la fin.

Et bien si je rajoute un slash ... plus de bug :D

J'le crois pas, mais ça fait pas un pli : (donc avec le contenu mal placé avant <html>)
-> avec un slash à la fin, tout fonctionne bien : -http://127.0.0.1/run/entree/index/
-> sans le slash : bug :aie:

Moralité : Faire gaffe à la réécriture, ne faites pas du n'importe quoi. :mrgreen:

Si certain on une explication du pourquoi du comment de ce slash à la noix ;)