W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Rechartering HTTPbis

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 28 Jan 2012 07:49:00 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20120128064900.GE22945@1wt.eu>
On Sat, Jan 28, 2012 at 11:28:02AM +1100, Mark Nottingham wrote:
> 
> On 28/01/2012, at 11:22 AM, Willy Tarreau wrote:
> 
> > 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 ?
> 
> 
> 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
limitation. That said I agree with PHK that transport headers should be
left 100% ASCII to save performance.

Willy
Received on Saturday, 28 January 2012 06:49:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:53 GMT