add a test case for HTTP/3 Push

[marten-seemann]

Discussed with @martinthomson on Slack: Apparently Firefox wants to have seen the URL before it accepts a Push.
We could generated n files to be pushed, and a .txt file that contains links to these files.
We'd then tell the client the URL of the .txt file. The server would then be expected to push these resources to the client.

How does this sound? quic-go doesn't have a push implementation (yet), so I can't really judge what makes sense here. @mjoras, @ghedo, @kazuho, @huitema, @tatsuhiro-t Any opinions on this?

[huitema]

The picoquic implementation of HTTP3 does not support server push. That would be a new development, the only goal being to test other HTTP3 implementations.

[martinthomson]

It's not pokemon Christian, you are allowed to not support test cases :)

[tatsuhiro-t]

ngtcp2 server has a feature to test push capability:

?push=<PATH_1>&push=<PATH_2>&...&push=<PATH_N>: Push resources specified by <PATH_1>, <PATH_2>, ... and <PATH_N>, where <PATH_I> must start with / (e.g., /?push=/bar)

So client requests URL with push query parameter specifying resource being pushed.

This is very simple scheme, but it looks like firefox won't work with this.

[marten-seemann]

@tatsuhiro-t Could you download the .txt file first, and then construct the ?push-URL from it?

Or do people think that the ?push-URL is a pattern worth standardizing (for testing purposes)?

[martinthomson]

You'd have to generate a redirect to that URL as the client won't know to make the request with all those query parameters. And I doubt that many of the primitive clients follow redirects (Firefox and Chrome probably would, but our test client would not).

[tatsuhiro-t]

If runner generates .txt file, then it can pass its URL with constructed push-URLs to client. Simple client then just request the URL.

[huitema]

@martinthomson hey, I like the way the score looks:

Once you have a stable spec, I might hack something...