W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Tue, 6 May 2014 19:52:08 +0900
Message-ID: <CAPyZ6=+FhkDF+Bjs5qdqjO=KJ=yQXimGszwmDbuW7eCVuCjnYA@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Daniel Stenberg <daniel@haxx.se>, James M Snell <jasnell@gmail.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
On Tue, May 6, 2014 at 7:34 PM, Cory Benfield <cory@lukasa.co.uk> wrote:

> On 6 May 2014 11:30, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> > 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:
> >
> > [..snip..]
> >
> > This means that we must expect duplicated header fields and multiple
> header
> > fields sharing same name in header set as input to HPACK.
> I'm happy with the header table itself having duplicates, I'm
> concerned about the header _set_ (see what I mean about the ambiguity
> of the spec?). The header table is a list of headers that we can
> reference, but the header _set_ is defined as follows:
> > Header Set: A header set is an unordered group of header fields that
> > are encoded jointly.  A complete set of key-value pairs contained
> > in a HTTP request or response is a header set.
> Are we allowed duplicates in here? The spec doesn't seem to say
> anything about them.
‚ÄčIt is true that spec does not say anything about it.
I think this is an editorial issue and can be solved by proposing suggested
text with PR as Daniel said.
And now the problem is what is the expected behavior.
I think duplicates should be allowed because the algorithm in HPACK does
not break if we allow them.
I don't think the complexity of HPACK is much lowered if we get rid of

Best regards,
Tatsuhiro Tsujikawa
Received on Tuesday, 6 May 2014 10:52:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC