Subject: [http-devops] HTTP/2 test suite is now available!

From: Michelle Lai <[email-masked]>
Date: Fri, 17 Jan 2014 04:04:05 +0000

Hi Everyone,
I'd like to announce that HTTP/2 test suite is now available at https://github.com/http2/http2-test/

The test suite is based on the principles of HTTP/2 Protocol test draft: http://www.ietf.org/id/draft-trace-httpbis-http2-test-00.txt to:

·         focus on HTTP/2 protocol compliance testing

·         contain client and server test cases

·         use platform-independent programming language - tests are written in JavaScript

·         provide cross-platform support - use NodeJS, grunt, mocha, and GÃbor's node-http2 module as the 09 implementation (will be updated as the draft moves forward)

Usage and proposed test scenarios are listed in readme and wiki at GitHub.

Currently we have few contributors: Akamai, Microsoft Open Tech, and GÃbor and are seeking more contributors to:

·         Implement more test cases

·         Improve framework robustness

·         Make framework as part of your build process, tweak it so that it works

Thanks,
Michelle

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 18 Jan 2014 21:52:17 +0900

Hi,

Thank you for this effort, testing platform is a great step forward for
HTTP/2.0 development.

I'd like to test nghttp2 client/server with this test suite, but I could
not find the document how to hook the test to the ordinary command line
tool.
Could you tell me how to do it?

Best regards,
Tatsuhiro Tsujikawa

On Fri, Jan 17, 2014 at 1:04 PM, Michelle Lai <[email-masked]> wrote:

>  Hi Everyone,
>
> I’d like to announce that HTTP/2 test suite is now available at
> https://github.com/http2/http2-test/
>
>
>
> The test suite is based on the principles of HTTP/2 Protocol test draft:
> http://www.ietf.org/id/draft-trace-httpbis-http2-test-00.txt to:
>
> ·         provide cross-platform support - use NodeJS, grunt, mocha, and
> GÃbor’s node-http2 module as the 09 implementation (will be updated as the
> draft moves forward)
>
>
>
> _______________________________________________
> http-devops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-devops
>
>

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 1 Feb 2014 16:39:42 +0900

On Sat, Feb 1, 2014 at 7:31 AM, Parashuram Narasimhan (MS OPEN TECH) <
[email-masked]> wrote:

>  Hi,
>
>
>
> I wanted to ping you again to see if you were able to get the test cases
> running for nghttp.
>
> We were also able to download your code and ran some initial test cases to
> ensure that we are doing it right on our end. The left column is the
> filenames and should give you an idea of how the http2 payload was sent to
> your server.
>
>
>

With HTTP2_BROWSER environment variable, I can run the test against nghttp
client. Thank you.

>  We did find a few bugs in our implementation, thanks to your code and
> have fixed the tests. Many of the tests passed. The ones labelled
> INCORRECT TEST were issues with the test framework and we have fixed most
> of the issues. We also found some issues other issues that may be in
> nghttp2. It would be great if you could take a look at it and confirm that
> the fails are not caused due to the test framework.
>
>
>
> It would be great if you can continue running your implementation against
> the test framework and let us know if you encounter issues with the test
> framework itself.
>
>
>

- invalid-level-goaway-test

I fixed this sometime ago in nghttp2

- *-when-closed-test

I'm thinking they are really necessary. The spec says it is RST_STREAM
situation, but responding each frame
with RST_STREAM is just wasting the processing and memory (e.g., many DATA
frames comes from the remote and responding each with
RST_STREAM). So "smart" client may remember when RST_STREAM is issued to
certain stream, but what gains if we do that using extra
memory. As a good compromise, I think it is best to ignore these frames.

- *-when-idle-test

I thought that these are the same categories of *-when-closed-test. So I
did not implement the check for this idle test.
It is not generally possible to detect that which stream ID is currently
idle without remembering all stream ID used so far,
especially those which are smaller than the last used/received stream ID.
But it is possible to detect idle stream which has larger stream ID than
the currently used. The current test case uses
stream ID 2, which is just the case. I have pending local commits to detect
this situation to pass the tests.

- push-promise-when-reserved-remote-test
With the latest nghttp2 and http2-test, this test passes.

- priority-when-reserved-remote
What does WRONG TEST mean?

I don't know why but the following tests fail on my PC:

- huge-index-test
  Error: done() invoked with non-Error: Not appropriate error code:
COMPRESSION_ERROR

- invalid-data-1-test
  Error: timeout of 10000ms exceeded

- invalid-data-2-test
  Error: timeout of 10000ms exceeded

- oversized-ping-test
  Error: done() invoked with non-Error: Not appropriate error code:
FRAME_SIZE_ERROR

Best regards,

Tatsuhiro Tsujikawa

>
> *Multiplexing*
>
> *NGHTTP2*
>
> invalid-level-data-test
>
> passed
>
> invalid-level-goaway-test
>
> FAIL - nghttp2 did not respond any error when receiving GOAWAY with
> specified StreamId - 6.8.  GOAWAY
>
> invalid-level-headers-test
>
> passed
>
> invalid-level-ping-test
>
> passed
>
> invalid-level-priority-test
>
> passed
>
> invalid-level-push-promise-test
>
> passed
>
> invalid-level-rst-stream-test
>
> passed
>
> invalid-level-settings-test
>
> passed
>
> *Framing*
>
> oversized-ping-test
>
> passed
>
> *Push*
>
> invalid-promised-id-1-test
>
> passed
>
> invalid-promised-id-2-test
>
> passed
>
> invalid-promised-id-3-test
>
> passed
>
> *Compression*
>
> huge-index-test
>
> passed
>
> invalid-data-1-test
>
> passed
>
> invalid-data-2-test
>
> passed
>
> *Stream*
>
> data-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> priority-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> push-promise-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> reservation-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> rst-stream-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> window-update-when-closed-test
>
> INCORRECT TEST  -waiting for connection error on closed stream - 5.1
> (closed state)
>
> data-when-idle-test
>
> FAIL - nghttp2 did not fail (did not send GOAWAY) when sending data on
> idle stream  - 5.1 - last paragraph
>
> priority-when-idle-test
>
> FAIL - nghttp2 did not fail (did not send PRIORITY) when sending data on
> idle stream  - 5.1 - last paragraph
>
> push-promise-when-idle-test
>
> FAIL - RST_STREAM (stream error) instead of GOAWAY (connection error) when
> sending PUSH_PROMISE on stream in IDLE state - 5.1 - last paragraph
>
> rst-stream-when-idle-test
>
> FAIL - nghttp2 did not fail when sending RST_STREAM on stream in IDLE
> state - 6.4 last paragraph
>
> window-update-when-idle-test
>
> FAIL - nghttp2 did not fail when sending WINDOW_UPDATE on stream in IDLE
> state - 5.1 - last paragraph
>
> data-when-reserved-remote-test
>
> passed
>
> priority-when-reserved-remote
>
> WRONG TEST -      An endpoint MAY send a PRIORITY frame in this state to
> reprioritize the reserved stream. - 5.1 (reserved-remote)
>
> push-promise-when-reserved-remote-test
>
> FAIL - RST_STREAM instead of GOAWAY -    Receiving any other type of frame
> other than HEADERS or RST_STREAM MUST be treated as a connection error
> (Section 5.4.1) of type      PROTOCOL_ERROR. - 5.1 (reserved-remote)
>
> reservation-when-reserved-remote-test
>
> passed
>
> window-update-when-reserved-remote-test
>
> passed
>
>
>
>
>
> *From:* Parashuram Narasimhan (MS OPEN TECH)
> *Sent:* Saturday, January 18, 2014 9:13 AM
> *To:* 'Tatsuhiro Tsujikawa'; Michelle Lai
> *Cc:* [email-masked]; Brian Raymor (MS OPEN TECH); Elancheziyan,
> Anbu; Rob Trace
> *Subject:* RE: [http-devops] HTTP/2 test suite is now available!
>
>
>
> Hi,
>
>
>
> You can see the instructions to run the client test cases here -
> https://github.com/http2/http2-test/blob/master/README.md#testing-the-client.
> We do not have any server test cases and are working on adding more tests
> for both client and server. Note that the client is expected to talk HTTP2
> directly without upgrade.
>
>
>
> *From:* Tatsuhiro Tsujikawa [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Saturday, January 18, 2014 4:52 AM
> *To:* Michelle Lai
> *Cc:* [email-masked]; Parashuram Narasimhan (MS OPEN TECH); Brian
> Raymor (MS OPEN TECH); Elancheziyan, Anbu; Rob Trace
> *Subject:* Re: [http-devops] HTTP/2 test suite is now available!
>
>
>
> Hi,
>
>
>
> GÃbor's node-http2 module as the 09 implementation (will be updated as the
> draft moves forward)
>
>
>