Should sending a GOAWAY frame on header decompression error be valid? about h2spec HOT 7 CLOSED

Your understanding of the spec is correct. However, this test is expected that the stream is closed properly, by sending two "Dynamic Table Size Update". Does your implementation treats "Dynamic Table Size Update" of HPACK as decompression error?

from h2spec.

I believe so. I receive the two hpack dynamic size updates, detect the decompression error, send a GOAWAY w/ COMPRESSION_ERROR set as the reason, then terminate the connection.

I believe that the issue is the test uses TestStreamClose (https://github.com/summerwind/h2spec/blob/master/4_3.go#L45) and in that function implementation, the test fails if it receives GOAWAY: https://github.com/summerwind/h2spec/blob/master/h2spec.go#L800

If I removed the GOAWAY frame before closing the connection, the test passed.

from h2spec.

This test is verifying that your implementation can handle correctly the dynamic table size update. If your implementation respond with GOAWAY, this test will be failed.

Why does your implementation treats the dynamic table size update as a decompression error?

from h2spec.

Ok, I understand the question.

The test sends two dynamic table size updates (0 and 4096) at the beginning of a single header block. The HPack spec contains the following:

A change in the maximum size of the dynamic table is signaled via a dynamic table size update (see Section 6.3). 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]).

My interpretation of this is that a single header frame can contain at most one dynamic table update and it must be at the beginning of the frame.

I also see this:

This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently be restored.

Again, my interpretation of this is that these dynamic updates must be in separate header frames.

I guess this is an incorrect interpretation?

from h2spec.

In paragraph:

Multiple updates to the maximum table size can occur between the transmission of two header blocks. In the case that this size is changed more than once in this interval, the smallest maximum table size that occurs in that interval MUST be signaled in a dynamic table size update. The final maximum size is always signaled, resulting in at most two dynamic table size updates. This ensures that the decoder is able to perform eviction based on reductions in dynamic table size (see Section 4.3).

I was reading "Multiple updates to the maximum table size" as receiving HTTP/2 settings frames w/ the max table size setting set, not multiple dynamic updates in the header block.

from h2spec.

the smallest maximum table size that occurs in that interval MUST be signaled in a dynamic table size update. The final maximum size is always signaled, resulting in at most two dynamic table size updates.

I think this states that 2 dynamic table size updates can occur at the front of encoded header block. If you still think it shouldn't, please ask this on IETF httpbis mailing list.

from h2spec.

Ok, thanks. I believe this is a misread on my part. Sorry for the trouble.

from h2spec.