Bonjour.

Pour les besoins de ce site http://tandemdirect.mp.atester.fr/demo/
Nous avons réalisé un petit flash capable de lire et de mettre en forme
les flux RSS v1 de eMajine pour les mettre sur la page d'accueil.

Tout marche bien sauf sur IE6 et IE5.5

Après examen, il semblerait que la première ligne du fichier de flu http://tandemdirect.mp.atester.fr/infos/feed-rss1.0.rdf
qui est xml version="1.0" encoding="UTF-8"
soit la source de cette incompatibilité d'humeur entre la flash et IE6 et 5.5...

En effet quand je supprime cette ligne et place mon fichier en dur via
FTP tout marche bien et sur tous les navigateurs...
Mon fichier est bien encodé en UTF-8.

J'ai déjà rencontré ce type de problème avec des fichiers XML
placés sur des serveurs dont le MIME TYPE xml etait érroné
au niveau de la définition dans le HT access si ma mémoire est bonne...

Quand est-il pour eMajine avec les fichiers RDF ?
Qui aurait une piste pour résoudre ce probleme ?

J'ai déjà demandé si il était possible de créer
un second fichier de flu (spécial flash) sans la première ligne.
J'attend une réponse et moi je sèche.

Une piste :
http://notetodogself.blogspot.com/2007/03/flash-in-ie6-xml-compression-problem.html

Bonjour,

J'ai un peu de mal à comprendre le soucis. Les fichiers RSS 1.0 et 2.0 générés par e-majine sont valides. Cela signifie que le fichier XML est parfaitement construit. Si je supprime la déclaration du fichier XML, le fil n'est donc plus valide.
Mes connaissance en flash ne sont pas étendue (pas du tout) et je me demande si tu as la possibilité d'utiliser différents parsers XML ?

Je trouve très étonnant que le parser XML n'accepte pas de fichiers XML correctement construits.
Je te conseil donc d'utiliser un autre parser...

Si ça vous dit de jouer au jeux des "7" différences autour d'un RDF...
Merci de prendre le temps de regarder ces deux tests... ;)

Le premier va chercher le RDF que j ai enregistré "en dur" sur mon bureau
et réinjecté (SANS MODIF) via FTP... LE FLASH MARCHE SOUR IE 6
ce RDF contient bien la ligne xml version="1.0" encoding="UTF-8"
http://tandemdirect.mp.atester.fr/scripts/my-flash/rdf-en-dur/index.html

Le second est le même fichier flash mais il va chercher le RDF qui est généré
à la volée par eMajine... ET QUI FIGE SOUS IE6...
http://tandemdirect.mp.atester.fr/scripts/my-flash/rdf-dynamique/index.html

Les deux RDF doivent être identiques ??? Non ???
et bien non et je ne sait pas pourquoi...

RDF en dur : http://tandemdirect.mp.atester.fr/scripts/my-flash/rdf-en-dur/feed-rss1.0.rdf
RDF Dynamique : http://tandemdirect.mp.atester.fr/infos/feed-rss1.0.rdf
Côté Parser il n'y a pas 36 façons de charger du XMl dans du flash
alors je pense que la vérité est ailleurs (Preuve par l'exemple 1)

Il apparait en effet des différences sur l'en-tête retournée par le serveur.
Dans le lien donné dans mon post précédent, il apparait que le problème survient à cause soit de la compression GZIP, soit de l'encodage.

Voici les en-têtes retournées par le serveur :

Header RDF static :
---------------------------------------------------
Date Mon, 26 Mar 2007 16:12:22 GMT
Server Apache
Last-Modified Mon, 26 Mar 2007 16:09:52 GMT
Etag "145db38-1be3-a2a0b400"
Accept-Ranges bytes
Content-Length 7139
Keep-Alive timeout=15, max=99
Connection Keep-Alive
Content-Type application/rdf+xml


Header RDF e-Majine :
---------------------------------------------------
Date Mon, 26 Mar 2007 16:16:21 GMT
Server Apache
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
content-disposition inline; filename=news-fr-16-feed-rss1.0.rdf
Content-Encoding gzip
Vary Accept-Encoding
Content-Length 1595
Keep-Alive timeout=15, max=73
Connection Keep-Alive
Content-Type application/xml; charset=UTF-8; filename=news-fr-16-feed-rss1.0.rdf

La pêche dans la kb Microsoft :

Internet Explorer ne peut pas décompresser le contenu HTTP lorsque vous visitez un site Web : http://support.microsoft.com/kb/871205/fr

Un page Web ne se charge pas correctement lorsque vous ouvrez une page contenant des données codées via Gzip : http://support.microsoft.com/kb/822002/fr

Bref, c'est du grand Microsoft ça.

Salut,

Alors je viens de tester pas mal de choses pour comprendre ce dysfonctionnement. Et au final, je me suis aperçu que notre cher IE n'est pas capable de lire un fichier XML si un header apache est balancé avec déclaration d'un charset.

On avait : "Content-Type application/xml;charset=UTF-8;filename=news-fr-16-feed-rss1.0.rdf"

J'ai juste enlevé le charset pour obtenir : "Content-Type application/xml;filename=news-fr-16-feed-rss1.0.rdf"

Et donc maintenant sur mon IE ca fonctionne...

Oui en cliquant sur un lien "HTML" ça marche
maintenant le fil RSS du formum marche sous IE 6 "Youhou !!!"
mais pour le flash sous IE6 c'est pas encore ça...

RDF Dynamique :
http://tandemdirect.mp.atester.fr/scripts/my-flash/rdf-dynamique/index.html

RDF en DUR :
http://tandemdirect.mp.atester.fr/scripts/my-flash/rdf-en-dur/index.html

Entre les deux il y a bien une différence de compression ???
Content-Encoding gzip

Visiblement IE6 et son Flash Player n'aiment pas ça... et peu importe la version (testé sous flash v7 v8 v9)... Non ?
Même Microsoft le dit... alors comment fait-on ?

Le gros problème c'est que je ne peux pas désactiver la compression gzip uniquement sur le fil RSS et il n'est pas pensable de désactiver complètement la compression sur le serveur pour des raisons évidentes de performances.
Je regarde dans les forums spécialisés flash pour trouver une solution.

Bonne nouvelle ça marche...
avec une contre-partie toutefois...

Dans le FLASH, et dans l urgence j ai modifié la façon dont flash va terminer le chargement du XML avant de "parser" les infos.

Sur xml_rdf.onload je force un saut de la tête de lecture
pour arrier à afficher les infos (parsées par une autre fonction)

Ceci afin de contourner la compression... qui fait que
jamais (au grand jamais) xml_rdf.getBytesLoaded() ne sera égal
à xml_rdf.getBytesTotal()... le premier nombre résultant d une compression et le second non. flash gère la decompression mais n adapte pas la valeur en consequence car sur flash il n y a pas (en tout cas en MX2004) de truc du genre "url_xml.getUncompressedBytesLoaded()"...

La contrepartie c est que flash ne "vérifie plus" que tout est bien chargé.
pour lui c est un peu comme si, dès que le flu cesse de charger c est fini.

En cas de gros fichier XML, sur de petites connexions (56K, GSM) ,ou quand la demande sur une ressource est grande, ou doit-être actualisée plusieurs fois depuis flash (mise à jour du contenu), le risque est de perdre le flu en cours de charge et donc comme le loader qui teste normalement le chargement est court-circuité le flash stop le chargement et ne reprend pas, il attend... sans plus d information pour l utilisateur...

En résumé, ça marche mais pour une utilisation plus intensive des contenus dynamiques importés dans flash serait-il possible de desactiver la compression
gZip sur les fichiers "interpretables" par flash (XML, css...) ou bien d en creer des copies en dur et non compressées.

Merci à tous pour vos efforts de recherche grace auquels...
Le site est en ligne...
http://www.tandemdirect.fr

C'est cool si tu as pu avancer de ton coté. J'ai fait quelques recherches sur ce problème et j'ai trouvé une nouvelle piste. Il se trouve que IE6 a un problème de gestion du mode deflate (gzip) si un header "no-cache" est passé.
J'ai donc supprimé la gestion de ce "no-cache" lors de la génération du fil RSS. Quand tu auras 5 minutes, tu pourras retester ton flash...