Après qq. surprises dans l'élaboration et le rendu de page web en html,
pourriez-vous me dire quel codage choisir pour avoir le minimum de
surprise lors de la relecture par éditeur de texte et surtout par un
navigateur ?
Je visite une(*) de mes pages z'au zazzard: http://perso.wanadoo.fr/stephane.moriaux/truc/tables_highlight_rows_fr.htm
(...)
et où est le charset envoyé-employé par le serveur ?
autre menu FF -> information sur la page : le charset (utf-8) semble bien avoir été vu
Le codage est bien déclaré dans le meta, et le navigateur peut s'appuyer dessus. Mais voir le message de Patrick, qui détaille pourquoi il est mal de ne pas spécifier le codage en entête.
Par ailleurs utf-8 contient us-ascii, on peut donc très bien renvoyer que des choses codées en utilisant us-ascii, le reste en entités, en spécifiant utiliser de l'UTF-8. Mais quel intérêt ?
ASM wrote:
Je visite une(*) de mes pages z'au zazzard:
http://perso.wanadoo.fr/stephane.moriaux/truc/tables_highlight_rows_fr.htm
(...)
et où est le charset envoyé-employé par le serveur ?
autre menu FF -> information sur la page :
le charset (utf-8) semble bien avoir été vu
Le codage est bien déclaré dans le meta, et le navigateur peut s'appuyer
dessus. Mais voir le message de Patrick, qui détaille pourquoi il est
mal de ne pas spécifier le codage en entête.
Par ailleurs utf-8 contient us-ascii, on peut donc très bien renvoyer
que des choses codées en utilisant us-ascii, le reste en entités, en
spécifiant utiliser de l'UTF-8. Mais quel intérêt ?
Je visite une(*) de mes pages z'au zazzard: http://perso.wanadoo.fr/stephane.moriaux/truc/tables_highlight_rows_fr.htm
(...)
et où est le charset envoyé-employé par le serveur ?
autre menu FF -> information sur la page : le charset (utf-8) semble bien avoir été vu
Le codage est bien déclaré dans le meta, et le navigateur peut s'appuyer dessus. Mais voir le message de Patrick, qui détaille pourquoi il est mal de ne pas spécifier le codage en entête.
Par ailleurs utf-8 contient us-ascii, on peut donc très bien renvoyer que des choses codées en utilisant us-ascii, le reste en entités, en spécifiant utiliser de l'UTF-8. Mais quel intérêt ?
Pierre Goiffon
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal:
1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Patrick Mevzek
Le Tue, 12 Jul 2005 12:14:41 +0200, Pierre Goiffon a écrit :
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html pour les détails et notamment le paragraphe Web Page Developers Should Recode Dynamically Generated Pages to Validate Output où l'on peut lire: In addition, web pages should explicitly set a character set to an appropriate value in all dynamically generated pages.
(que j'étend personnellement à toutes les pages, vu que le risque peut être présent aussi ailleurs, et que cela ne fait pas de mal de toute façon).
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html le paragraphe Explicitly Setting the Character Encoding (mais malheureusement leur exemple utilise la balise META, grrrrr...)
Pour Apache, les explications en rapport avec cette note du CERT sont là: http://httpd.apache.org/info/css-security/
Personnellement, un HTTP/1.2 qui contiendrait l'obligation de la présence du charset dans le Content-Type aurait mes faveurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Tue, 12 Jul 2005 12:14:41 +0200, Pierre Goiffon a écrit :
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal:
1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html
pour les détails et notamment le paragraphe
Web Page Developers Should Recode Dynamically Generated Pages to Validate Output
où l'on peut lire:
In addition, web pages should explicitly set a character set to an
appropriate value in all dynamically generated pages.
(que j'étend personnellement à toutes les pages, vu que le risque peut
être présent aussi ailleurs, et que cela ne fait pas de mal de toute
façon).
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html
le paragraphe
Explicitly Setting the Character Encoding
(mais malheureusement leur exemple utilise la balise META, grrrrr...)
Pour Apache, les explications en rapport avec cette note du CERT sont là:
http://httpd.apache.org/info/css-security/
Personnellement, un HTTP/1.2 qui contiendrait l'obligation de la présence
du charset dans le Content-Type aurait mes faveurs.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Tue, 12 Jul 2005 12:14:41 +0200, Pierre Goiffon a écrit :
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html pour les détails et notamment le paragraphe Web Page Developers Should Recode Dynamically Generated Pages to Validate Output où l'on peut lire: In addition, web pages should explicitly set a character set to an appropriate value in all dynamically generated pages.
(que j'étend personnellement à toutes les pages, vu que le risque peut être présent aussi ailleurs, et que cela ne fait pas de mal de toute façon).
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html le paragraphe Explicitly Setting the Character Encoding (mais malheureusement leur exemple utilise la balise META, grrrrr...)
Pour Apache, les explications en rapport avec cette note du CERT sont là: http://httpd.apache.org/info/css-security/
Personnellement, un HTTP/1.2 qui contiendrait l'obligation de la présence du charset dans le Content-Type aurait mes faveurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pierre Goiffon
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html
(...)
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html
(...)
Pour Apache, les explications en rapport avec cette note du CERT sont là: http://httpd.apache.org/info/css-security/
Ok, vu dans le 2eme document : "Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<". Some browsers recognize this alternative encoding and act on it"
Je crois me souvenir avoir lu qu'en UTF-8 certains caractères peuvent être codés sous plusieurs formes mais je ne retrouve plus comment ?? Un pointeur quelqu'un ??
Patrick Mevzek wrote:
Il devrait être dans le Content-Type. Il n'est pas là c'est mal:
1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html
(...)
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html
(...)
Pour Apache, les explications en rapport avec cette note du CERT sont là:
http://httpd.apache.org/info/css-security/
Ok, vu dans le 2eme document :
"Some 16-bit character-encoding schemes have additional multi-byte
representations for special characters such as "<". Some browsers
recognize this alternative encoding and act on it"
Je crois me souvenir avoir lu qu'en UTF-8 certains caractères peuvent
être codés sous plusieurs formes mais je ne retrouve plus comment ?? Un
pointeur quelqu'un ??
Il devrait être dans le Content-Type. Il n'est pas là c'est mal: 1) augmente les risques de vulnérabilité aux attaques XSS
Jamais entendu parler de ça. Pourrais-tu en dire plus ?
Cf http://www.cert.org/advisories/CA-2000-02.html
(...)
Ou dans http://www.cert.org/tech_tips/malicious_code_mitigation.html
(...)
Pour Apache, les explications en rapport avec cette note du CERT sont là: http://httpd.apache.org/info/css-security/
Ok, vu dans le 2eme document : "Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<". Some browsers recognize this alternative encoding and act on it"
Je crois me souvenir avoir lu qu'en UTF-8 certains caractères peuvent être codés sous plusieurs formes mais je ne retrouve plus comment ?? Un pointeur quelqu'un ??
