- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 28 Jan 2012 01:22:33 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Jan 28, 2012 at 11:08:12AM +1100, Mark Nottingham wrote: > > On 28/01/2012, at 11:04 AM, Willy Tarreau wrote: > > > On Sat, Jan 28, 2012 at 10:37:33AM +1100, Mark Nottingham wrote: > >>> Re HTTP/next: it would be good to collect a list of things we think we > >>> should make progress on; not surprisingly, I'd nominate I18N for header > >>> field values. > >> > >> So, that's an interesting question. > >> > >> If we want HTTP/1.1 <-> 2.0 gateways, and we don't want to force them to know > >> about individual header semantics, that implies that we can't really change > >> header encoding, doesn't it? > > > > Unless we clearly define the transformation operation, which might be > > lossy and advertised as one operational limit to such gateways. > > I don't think that's workable, at least for proxies, which aren't under the control of the client or the server. It also makes gateways (reverse proxies) really complex, as you'd have to configure them very specifically. > > E.g., if I want to use a "foo" extension header that has non-ascii content, I'd have to teach every intermediary along the way about its syntax. But if we define that all headers have the same non-ascii encoding, there is no need for teaching everyone in the chain, right ? Willy
Received on Saturday, 28 January 2012 00:23:00 UTC