- From: Martin Nilsson <nilsson@opera.com>
- Date: Fri, 03 Aug 2012 01:25:08 +0200
- To: ietf-http-wg@w3.org
On Thu, 02 Aug 2012 10:27:35 +0200, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > That being said, I am not a big fan of UTF8 in high-performance > protocol context: It is much slower to process than 8bit string > formats. > I would like to know more on what operations you need. I imagine that most relevant operations (splitting, joining, comparing, strlen) can be performed directly on the encoded UTF8 string as efficient as on ASCII. Normalization and upper/lowercasing is trickier, but mostly because of all the Unicode rules, not UTF8 itself(though it doesn't help). > UTF8 also gives rise to a number of interesting security aspects, > primarily where humans eyeball for security and don't detect minor > differences between glyphs, particularly in FQDNs, but I can't see > how we can do anything about that in HTTP/2.0. Defining legal character ranges and what character encodings to use are two different problems. Similar looking characters are indeed a problem already today, and it is known and worked on on the browser side. /Martin Nilsson -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Thursday, 2 August 2012 23:25:33 UTC