Re: h2test

[Rémy Maucherat]

On Wed, Feb 14, 2018 at 6:27 PM, Mark Thomas  wrote:

> 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
>

It didn't work as it is the default, but initiatePingDisabled="true" did :)
Thanks, and sorry for the noise, case closed.

Rémy

>
> See http://svn.apache.org/viewvc?rev=1788554=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
>
>

Re: h2test

[Mark Thomas]

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=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

Re: h2test

[Rémy Maucherat]

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.

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
>
>

Re: h2test

[Mark Thomas]

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 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?

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

h2test

[Rémy Maucherat]

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).

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 ping opaque data seems (to me) to be processed and sent back
properly, but for some reason the client sees it corrupted. Odd.

Comments ?

Rémy