I've discovered a few things about the HPACK errors I'm seeing during integration testing:
- They are deterministic: they always occur on the first RegisterStreamConsumer call, which is usually assigned streamId 17 or so on the h2 connection. - They are completely unaffected by disabling Huffman encoding. - The RegisterStreamConsumer call succeeds when retried (automatically, by the SDK's default retry logic) on a new connection. I think these facts strongly suggest some sort of client-side corruption of the connection state, causing the client to eventually write a corrupt HEADERS frame that the server rejects. I've posted GitHub gists with full debug logs for the integration tests with Huffman encoding disabled [1] and enabled [2]. I don't think debug logs are an especially useful format in this case, so tomorrow I'll work on dumping just the raw binary sequence of HEADERS frames (for the whole connection) to a dedicated file, which we can then shove up some other HTTP/2 implementation (starting with Netty 4.1.29.Final). By the way, the test I'm running is [3], modified to run with my apache-async-client [4]. [1] https://gist.githubusercontent.com/rschmitt/bd996852c1bb8b56341051e585a4ed93/raw/c0c8bb6d337de3a881ace9bb52ebd55f4bb29dd3/huffman-disabled.txt [2] https://gist.githubusercontent.com/rschmitt/311e8413d88ed7cf8450e844fb74df86/raw/66b559eca0eb9bf5d2192a817881a9efdd3c2c1d/huffman-enabled.txt [3] https://github.com/aws/aws-sdk-java-v2/blob/master/services/kinesis/src/it/java/software/amazon/awssdk/services/kinesis/SubscribeToShardIntegrationTest.java [4] https://github.com/aws/aws-sdk-java-v2/pull/1543
