The integration tests I'm running are open source, and so you should be able to reproduce the failure I'm seeing. However, I don't think I'll get around to working on this particular bug today.
On Wed, Dec 11, 2019 at 4:56 AM Oleg Kalnichevski <ol...@apache.org> wrote: > On Wed, 2019-12-11 at 09:33 +0100, Oleg Kalnichevski wrote: > > On Tue, 2019-12-10 at 10:54 -0800, Ryan Schmitt wrote: > > > > That sounds a bit unsettling. Any theory as to why the defect has > > > > not > > > > been manifesting itself with the existing integration tests? > > > > > > Lack of implementation diversity? Hypothetically, if the same HPACK > > > bug is > > > on the client and the server, they could cancel out, and the tests > > > will > > > pass despite the implementation being non-interoperable and out of > > > spec. > > > The integration tests I'm referring to are hitting a production > > > endpoint > > > for Amazon Kinesis, whose HTTP/2 implementation is based on Netty. > > > > > > > I see. My apologies. I thought you were referring to one of the > > issues > > triggered by additional Reactive integration tests. > > > > > > > > I do not think HPACK can be disabled. By disabling HPACK, I > > > > presume > > > > you > > > > mean not using Huffman compression? > > > > > > I'll take whatever I can get. The more sources of complexity I can > > > disable, > > > the more code I can rule out (or rule in). I'll see about the > > > approach ofH2 config option to disable Huffman compression > > > marking all the headers sensitive. > > > > > > > Hi Ryan > > The commit below adds H2 config option to disable Huffman compression > > > https://github.com/apache/httpcomponents-core/commit/0290c300581578e094c526d0a03062e840bf9e32 > > Hope this helps you a bit. > > Oleg > > PS: In the meantime I will try to run some stress tests of the HTTP/2 > client transport against Apache HTTPD and Ngnix servers and see if I > can reproduce the issue. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >