Re: hpack static table question?

I was wondering this about a month back, when I was helping debug an issue
centered around this case (a copy of a static entry being evicted). So I
looked back in the list archives, and saw that basically, some people
wanted setting the table size to 0 to mean that literally no state was
kept, not even references to the static table. (I'm on my phone, so no link
to the thread, sorry.)

Personally, I think it's silly, too (it means that periodically I have to
send an indexed representation that I wouldn't have to if I could put
static :method GET headers in the reference set). But it's what we have,
and I have to re-send :method if some resources are POST anyway, so it's
not a big loss. This is why I didn't bring it up a month ago.

Personally, while I'm not a fan of this restriction, I'd rather keep the
spec as is so we can get to last call sooner.
--
Peace,
  -Nick
On Jun 2, 2014 9:25 AM, "Cory Benfield" <cory@lukasa.co.uk> wrote:

> On 2 June 2014 17:05, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> > Sorry, I don't understand.  What is the problem here exactly?
>
> Let's get everyone on the same page.
>
> Greg is concerned that he has to copy a header out of the static table
> into the header table in order to add it to the reference set. He has
> to do this because the spec states that references may only be to
> headers in the header set without being clear of _why_ that's the
> case.
>
> Tatsuhiro has provided the most compelling reason so far, which is
> that it enables the clearing of the reference set by the slightly
> obscure means of setting the header table size to zero via HTTP/2
> SETTINGS. I don't think anyone actually wants to do this.
>
> I think the real question here is: why can't we have references to the
> static table? What is the architectural reason that ruled it out?
>
>