- From: Chris Lilley <chris@w3.org>
- Date: Wed, 24 Nov 2004 15:49:47 +0100
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: Thomas DeWeese <Thomas.DeWeese@Kodak.com>, www-svg@w3.org
On Wednesday, November 24, 2004, 3:06:42 PM, Robin wrote: RB> Thomas DeWeese wrote: >> I personally think that the only reasonable thing to do here >> is state that if a charset is provided and it doesn't match >> the xml encoding then the response is ill-formed and the >> behavior is implementation dependent. Then the only people >> who have work to do are people who are sending content with >> contradictory charset and xml encoding specifications. Which >> is exactly where the burden of resolving this issue should lie. RB> Those are the precise people we do *not* want to put the burden of RB> resolving this on. They will have to deal with uncooperative server RB> administrators Well, they already do. So do authoring tools, which do not know how a particular server is set up or what conventions have to be applied to reliably generate a correct charset parameter. RB> that'll refuse to let them control the character encoding RB> because all they (think they) know about character encodings is that you RB> have to provide one to avoid certain XSS attacks. Can you explain the XSS attack and charset in more detail? What is the attack, does a default charset actually help prevent it or is that mythology, how should people actually guard against such attacks. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Wednesday, 24 November 2004 14:49:49 UTC