- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 11 Feb 2015 03:53:04 -0800
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>
Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > I think there is currently no adequate specification to reference for > use in a security-sensitive environment. Much as I would agree that > non-ASCII characters in URIs and parts of URIs or equivalent protocol > elements should be permissable wherever ASCII is permissable, I think > it would be better to do this at a later time for CSP. These issues exist for Link and other header fields too. I think there should be a general framework for solutions to this problem of IRIs in HTTP header fields. I agree that CSP 2 shouldn't have to create that framework. > (You ended that paragraph in the middle of a sentence.) Just ignore that. >>You mentioned that urlencode(normalize(utf8encode(...))) is most >>probably wrong. However, consider a document that is NOT in UTF-8 >>encoding, but instead in Shift-JIS. I believe that there does need to >>be a first step of converting the text to Unicode and then UTF-8 >>encoding the Unicode text. However, I could very well be wrong here. > > You have to decode character encodings, sure, but that does not seem > relevant here. It is relevant for CSP policies that are defined in <meta>. Cheers, Brian
Received on Wednesday, 11 February 2015 11:53:31 UTC