Re: h2 header field names

Hash: SHA1

On 5/09/2014 1:38 a.m., Michael Sweet wrote:
> Martin,
> Seems like binary header values would require some indication in
> the HPACK encoding that those headers contain binary data, so that 
> 2.0-to-1.1 proxy can convert the binary data to Base64.  And
> *that* seems fraught with interoperability issues since then a
> 1.1-to-2.0 proxy will either a) need to know which headers want
> binary encoding or b) make some guess based on the value being all
> Base64.

I dont see why the gateway would need to know which headers want
binary encoding in particular. To trasmit over 1.1 the headers already
"want" a base-64 encoded form which should be able to relay over 2.0
without decoding.

* a 2.0->1.1 gateway gets the binary indicator.

* a 1.1->2.0 gateway gets base-64 and sends as non-binary.

* a 2.0->1.1->2.0 chain the second 2.0 gateway gets base-64 and sends
either non-binary storing base-64 or binary forms.

The end recipient "just" needs to handle:
 * optionally base-64 encoded in non-binary form for both 2.0 or 1.1, or
 * UTF-8 in binary form for 2.0 traffic.

If the header sent with non-ASCII does not define a suitable base-64
representation for 2.0->1.1 gateways to emit then the content is
invalid 1.1 and invalid message rejection should not be a problem.

> Regardless, what are you trying to accomplish with binary header 
> values?

Good question. In a nutshell, the gain is simplicity for
implementations no longer having to include base-64 encoder/decoders
or spend CPU cycles doing the coding.

Version: GnuPG v2.0.22 (MingW32)


Received on Thursday, 4 September 2014 14:41:35 UTC