Re: HPACK problems (was http/2 & hpack protocol review)

On Tue, May 6, 2014 at 7:00 PM, Daniel Stenberg <daniel@haxx.se> wrote:

> On Tue, 6 May 2014, Cory Benfield wrote:
>
>  As an example of the under-specification, consider that the reference set
>> and header sets are defined as unordered but do not say whether they may
>> contain duplicate elements. My assumption was that they could not and so I
>> could assume all implementations will join multiple values with null bytes,
>> but that assumption has not been made elsewhere (nghttp2 certainly doesn't).
>>
>
> Perhaps you can suggest an updated wording for the spec that makes it
> clearer?
>
> I (and others) have used nghttp2 quite a lot for interop lately so I want
> to be sure that what it does is what the spec says so that we don't interop
> against something not actually compliant!
>
>
​The reference set actually does not contain duplicates because its element
is a reference to the header table entry.
On the other hand, the header table may have duplicates.  This is​ covered
by the spec:


>From 3.1.2 <http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-07#section-3.1.2>.
 Header Table:



   There is typically no need for the header table to contain duplicate
   entries.  However, duplicate entries MUST NOT be treated as an error
   by a decoder.



The current HTTP/2 draft-12 says that header fields sharing same name can
be concatenated with "0x0" but it was introduced some where in -6 to -9 and
it is only required if ordering of those header fields are significant.

>From 8.1.3.3.  Header Field Ordering:

   Header fields containing multiple values MUST be concatenated into a
   single value unless the ordering of that header field is known to be
   insignificant.


This means that we must expect duplicated header fields and multiple header
fields sharing same name in header set as input to HPACK.

Best regards,

Tatsuhiro Tsujikawa


>
>  These interop bugs with HPACK are ridiculously difficult to catch.
>>
>
> Any more than other compression or encryption interop bugs (I'm just
> suggesting that the area of compression/checksumming/encryption makes
> annoying interop debugging)? If so, what is it that makes HPACK more
> difficult than others?
>
> --
>
>  / daniel.haxx.se
>
>