Closed Bug 926435 Opened 11 years ago Closed 9 years ago

Basic unit tests for HTTP2

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 950768

People

(Reporter: gabor, Assigned: gabor)

Details

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130917102605
OS: Linux → All
Hardware: x86_64 → All
I plan to do this based on the SPDY unit tests: https://bugzilla.mozilla.org/show_bug.cgi?id=719609, but using node-http2 instead of node-spdy.
Assignee: nobody → gabor
Status: UNCONFIRMED → NEW
Ever confirmed: true
We will need node 0.10 for this on the testing infrastructure. What version is there now? If there was no update since the SPDY testing bug landed, it's 0.7 I guess.

In this case, I'll file a bug for the upgrade. Node-spdy and the spdy unit tests seem to work fine with 0.10 on my machine, and there are precompiled node 0.10 binaries available so the upgrade shouldn't be too difficult.
We've upgraded once since the SPDY tests landed, but I think we're still at 0.8.something on the test slaves, so we'll definitely need an upgrade. For current testing purposes (not to land in m-c, but so you can work on your patches), just commit a binary to the tree next to runxpcshelltests.py, and modify runxpcshelltests.py to look for that binary instead of looking in MOZ_NODE_PATH. I think we should hold off on the node upgrade until we can get a version of node that supports ALPN deployed (no need to make releng upgrade twice when we can work around it for now)
I followed your advice and committed the binary so that I can do try build, one build should be ready soon.

Good news: there _is_ a recent fork of node that supports ALPN: https://github.com/shigeki/node/tree/alpn_support, so we can use that immediately. It works fine for me, although I'm sure it still needs more work to be completely stable. For example, it breaks node-spdy, since if the client supports ALPN, then the server ignores NPN, so node-spdy cannot negotiate SPDY, but I have a patch for that.

I attached the first version of the HTTP2 unit test patches. I used git (https://github.com/molnarg/moz-http2) and hg in parallel, so I it's possible that that the patch is in the appropriate format or broken in some other ways.
The tests as they are now pass, but I had two interesting observations:

1. When doing the multiplexing test, Firefox opens two parallel HTTP2 connections for the two streams.
   In node-http2 this is solved like this:

   1.1. If there's multiple requests for the same host, but there's no completely ready TLS connection yet, then
   1.2. Initiate a new TLS connection
   1.3. When one of the TLS connections finish, and negotiate HTTP2,
        then close every other opened connection, and use this one to send all the requests
   1.4. When one of the TLS connections finish, and doesn't negotiate HTTP2,
        then leave all of them open and do HTTP/1.1 requests on the opened connections in parallel

2. The large post test fails when the server turns of flow control, but works when the server uses flow control.
   It seems that Firefox waits for the server to send WINDOW_UPDATEs, even if the server turns off flow control.
   To reproduce this, comment out line 162 of moz-http2.js


So these tests are simple ports of the SPDY tests, but I plan to integrate https://github.com/molnarg/http2-testpage in the future. For this, the test case have to access the output of the test server, since the test server determines of the client's behaviour is spec conformant or not. I think it would be better to let the test cases start the appropriate server (in case of spdy and these http2 tests too) instead of the test runner framework. What do you think?
(In reply to Gábor Molnár from comment #7)
>
>    It seems that Firefox waits for the server to send WINDOW_UPDATEs, even
> if the server turns off flow control.
>    To reproduce this, comment out line 162 of moz-http2.js
>

thanks for this - I've had this bug before in spdy/3 :(

The issue is a race condition - if the stream is already paused due to flow control then the SETTINGS frame does not unpause it in the way that normal window_updates would. If the stream wasn't paused when the SETTINGS frame arrived then everything would be ok (it would never get paused).

the good news is that is exactly why I added that test! so you can revert the {} setting in moz-http2.

My change is in a pull request for nick's tree.. and its here too: https://github.com/mcmanus/moz-http2/commit/fcb3c0b17f86222e1f387ac9c5a798da841abe60
gabor this is pretty awesome.. can you open a pull to get it into nick's gittree? We can leave this open as part of the review process of getting it into m-c
Sure, I've just opened a pull request! I will also keep the patches in sync (it turned out to be easier than I thought).
Attachment #819502 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: