On 14/02/18 17:21, Rémy Maucherat wrote: > On Wed, Feb 14, 2018 at 6:09 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 14/02/18 15:41, Rémy Maucherat wrote: >>> Hi, >>> >>> I'm using h2test on and off to see what's going on. It helps me find a >>> significant issue sometimes (like this one r1823670). >> >> I've been using h2spec which also found a number of issues. Generally, >> test suites are very helpful. >> >>> Now, it almost looks ok, with a few oddities left: >>> - The ping flag may be inverted (ack is supposed to be 0, not 1, from >> what >>> I read in the spec). Did I miss something ? >> >> The relevant text appears to be in 6.7. My reading of that (before I >> look at the code) is that if an endpoint receives a PING frame without >> an ACK, it must echo it back with an ACK. If and endpoint receives a >> PING frame with an ACK it does nothing. >> >> Checking the code now... >> >> For receiving pings[1], the behaviour looks to be correct. If ACK is >> set, the roound-trip time is updated. If ACK is not set, a PING frame is >> sent back and the payload is echoed. >> >> For sending new pings, the ACK[2] is not sent and we use the payload to >> hold the sequence (it makes determining the round-trip time easier). >> >> There are also a handful of test cases for PING frames that check >> various aspects of this. >> >> Everything looks to be correct as far as I can tell. Can you elaborate >> on where you think the problem is? >> > > The test output is: > 6.7. PING > × 1: Sends a PING frame > -> The endpoint MUST sends a PING frame with ACK, with an identical > payload. > Expected: PING Frame (length:8, flags:0x01, stream_id:0, > opaque_data:h2spec) > Actual: PING Frame ((length:8, flags:0x00, stream_id:0, > opaque_data: ) > × 2: Sends a PING frame with ACK > -> The endpoint MUST NOT respond to PING frames with ACK. > Expected: PING Frame (length:8, flags:0x01, stream_id:0, > opaque_data:h2spec) > Actual: PING Frame ((length:8, flags:0x00, stream_id:0, > opaque_data: ) > > And reading the spec, I'd swap the values of the two constants PING and > PING_ACK in Http2UpgradeHandler. So since it was a bit unexpected, I'm > asking for confirmation there. > > >>> - The ping opaque data seems (to me) to be processed and sent back >>> properly, but for some reason the client sees it corrupted. Odd. >> >> Very odd. Can you do this over h2c and get a wireshark trace? >> > > Yes, but it's simply not possible that it is corrupted, other more > important things would be corrupted. Normally there's also no encoding or > decoding (it actually sends chars as you can see above, the opaque value is > "h2spec"). > > So I get from your answer that h2spec fully passes for you ? I'm also using > h2c for this. If you are testing PING (or anything else) you probably need to disable the keep-alive PINGs else they mess up the test.
You want the hidden option initiatePingDisabled="false" on the Http2Protocol See http://svn.apache.org/viewvc?rev=1788554&view=rev h2spec passes for me providing I use the setting above. If I don't set it, I get all sorts of failures, HTH, Mark > > Rémy > > >> >> Mark >> >> >> [1] >> https://github.com/apache/tomcat/blob/trunk/java/org/apache/coyote/http2/ >> Http2UpgradeHandler.java#L1444 >> >> [2] >> https://github.com/apache/tomcat/blob/trunk/java/org/apache/coyote/http2/ >> Http2UpgradeHandler.java#L1436 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
