Subject: hpack table size 0

From: <[email-masked]>
Date: Mon, 30 Jun 2014 11:58:09 +0000

It's been mentioned previously that resource-constrained implementations may set the table size to 0 (i.e. SETTINGS_HEADER_TABLE_SIZE).

Assume a server has table size 0... Questions:

1. The client's first request will likely include entries that are "Literal Header Field with Incremental Indexing".  I assume it is OK for the server to process a request with this type of literal even though the server won't be adding to its 0-size table?  Am I missing something?

2. If the client is sending multiple requests right after the connection is opened, each request after the first will likely include entries that reference the table (i.e. "Indexed Header Field Representation").  What is an endpoint supposed to do if the peer references something not in its table?  REFUSED_STREAM?  What mechanism should be used to tell the peer to retry?

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Jun 2014 14:15:16 +0000

The server has a couple of options, none of them perfect, while it waits one RTT for the client to process its SETTINGS:
  - Allocate up to 4K temporarily and handle all the requests
  - RST_STREAM CANCEL any request which follows an indexed literal and either references the header table or fails to clear the reference set as the first operation (the indexed header itself is fine, it's whether any subsequent request expects the server to have retained that header that could cause a problem.); let the client resend once it has the SETTINGS frame

Again, this is a problem of reducing a value -- because you're starting from a non-zero default and reducing it, you either have to wait before deallocating the resources or lose a round trip before successful requests can flow.

---

From: <[email-masked]>
Date: Mon, 30 Jun 2014 15:46:54 +0000

On Monday,30 June 2014 16:15, [email-masked]<mailto:[email-masked]> wrote:
> The server has a couple of options, none of them perfect, while it waits one RTT

> for the client to process its SETTINGS:

>   - RST_STREAM CANCEL any request which follows an indexed literal and either

>     references the header table or fails to clear the reference set as the first operation

>     (the indexed header itself is fine, it's whether any subsequent request expects the

>     server to have retained that header that could cause a problem.); let the client resend

>     once it has the SETTINGS frame

Won't "RST_STREAM CANCEL" lead to indeterminate behaviour from the client?  How does the client know to retry the stream?  The spec never mentions that a client should retry.

Furthermore, I just noticed the following "MUST" requirement in Section 4.3 [1]...

A receiver MUST terminate the connection with a connection error (Section 5.4.1) of type COMPRESSION_ERROR if it does not decompress a header block.

> Again, this is a problem of reducing a value -- because you're starting from a non-zero

> default and reducing it, you either have to wait before deallocating the resources or

> lose a round trip before successful requests can flow.

Yes, I knew there would be a loss of a RTT involved.

[1] http://http2.github.io/http2-spec/#HeaderBlock

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

To: [email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jun 2014 09:40:29 -0700

On 30 June 2014 08:46,  <[email-masked]> wrote:
> Won’t "RST_STREAM CANCEL" lead to indeterminate behaviour from the client?
> How does the client know to retry the stream?  The spec never mentions that
> a client should retry.

I think that REFUSED_STREAM is - in this case - perfectly appropriate.