- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 6 Feb 2012 07:28:08 +0100
- To: Henrik Nordström <henrik@henriknordstrom.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 06, 2012 at 05:01:56AM +0100, Henrik Nordström wrote: > lör 2012-01-28 klockan 09:13 +0100 skrev Julian Reschke: > > > > I would apply a lossy conversion (reverse-mapping between UTF-8 and 8859-1). > > > So whatever fits 8859-1 would correctly be mapped, and the rest would be lost > > > or quoted. I don't think it's that big an issue if this is a well-known > > > > There is no quoting we can use, unless we define a new one... > > Or we just accept that HTTP/1.1 implementations do not follow HTTP/1.1 > encoding specifications anyway for non-ascii data and simply say that > when I18N field values need to be gatewayed to HTTP/1.1 then send them > as UTF-8 even if HTTP/1.1 specifications says otherwise, intentionally > overriding HTTP/1.1 specifications. > > Sure it will break some to fix some (and mainly authentication), but > it's not really such a big deal. In the end it's about the same amount > of breakage as today, only different and more consistent. +1 > But it's a bad idea to open for I18N in field names. +1. For me i18n should only appear in values. Otherwise we'll be dealing with a big new can of worms caused by UTF-8 to anything conversion (eg: multiple ways to write "Content-Length" because you can have a number of UTF-8 hyphens which translate into "-"). Regards, Willy
Received on Monday, 6 February 2012 06:28:52 UTC