Re: Rechartering HTTPbis

On 2012-01-28 07:49, Willy Tarreau wrote:
> 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

There is no quoting we can use, unless we define a new one...

 > ...

Best regards, Julian

Received on Saturday, 28 January 2012 08:14:28 UTC