- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 28 Jan 2012 09:24:12 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Julian, On Sat, Jan 28, 2012 at 09:13:51AM +0100, Julian Reschke wrote: > >>How do you transform those non-ascii headers to ascii when you convert > >>the message to HTTP/1.1? > > > >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... This is what I was suggesting ; in fact, I suspect that along the design, we'll have to take notes of issues we'll have to face for 2.0->1.1 gateways. At one point we'll have to decide if some issues are serious and need be addressed in 2.0 draft, or if they're minor enough to justify an RFC to explain the best practices to apply on gateways to ensure a high level of interoperability, possibly with minor tweaks on the 1.1 servers to accomodate them. Because I suspect that if it's just a matter of deciding that some char encoding is lost or converted to a TBD quoted format, it's possible that most 1.1 implementors won't care a dime and that remaining ones will be able to apply minor code updates on their side in order to benefit from 2.0. For me it's exactly the same principle as server-side coders who take care of extracting the X-Forwarded-For header to get the real client's address : just a minor tweak to make it easier to accept a gateway which provides other benefits. Regards, Willy
Received on Saturday, 28 January 2012 08:24:46 UTC