RE: HPACK, Dynamic Table Size Update

For #1, the required position is because the encoder MUST respond to the newly-received setting as soon as it's received and acknowledged.  Functionally, it *could* occur sooner -- there's no reason it couldn't immediately signal a lower size upon receive during compression of a header block, then acknowledge the SETTINGS frame after the currently-in-process frame was done, but that's likely to be needlessly complex.  But the latest you can drop to within the required bounds is the start of the next HEADERS frame, because it's the next time the encoder gets to speak after the ack.

So in short, it could legitimately go earlier if you were in the process of sending a HEADERS frame already, but it cannot go later.

For #2, you're correct -- an otherwise-empty HPACK frame will no longer result in a valid header-set.  (This was possible with previous drafts.)

-----Original Message-----
From: Pavel Rappo [mailto:pavel.rappo@gmail.com] 
Sent: Tuesday, June 9, 2015 1:57 PM
To: Martin Thomson; Mike Bishop
Cc: ietf-http-wg@w3.org
Subject: Re: HPACK, Dynamic Table Size Update

Michael, Martin, thanks for your answers! I have two more questions if I may.

1. ...This dynamic table size update MUST occur at the beginning of the first
   header block following the change to the dynamic table size. In HTTP/2,
   this follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]).

To me it seems like it _only_ applies to solicited updates. Mostly because this paragraph mentions "settings acknowledgment" which is (as I understand) absent when size update is initiated by encoding side. So the question is -- could an unsolicited update go in the middle of a header block, for example:

    -- header block begin --
    == Literal indexed ==
    == Literal indexed ==
    == Indexed - Add ==
    == Size Update ==
    == Literal indexed ==
    == Literal indexed ==
    ...
    -- header block end --

?

Just curious, what was the rationale behind binding size updates to a specific location in a header block (for the solicited case)?

2. As I understand a header block cannot consist of only size updates because "size update" is not a header field representation. So size updates (if any) has to go with some header fields. Am I right?

-- header block begin --
== Size Update ==
== Size Update ==
== Size Update ==
-- header block end --

Thanks.

-Pavel

Received on Tuesday, 9 June 2015 23:54:25 UTC