On Sat, Mar 21, 2020 at 03:13:07PM +0500, ???? ??????? wrote:
> > Really you *need* to have some response data, not just an empty 200.
> > Probably that you can do it with something like this to build 10kB of
> > garbage:
> >
> am I correct, dealing with large blocks is something HPACK related ?

No it's unrelated. HPACK only deals with headers encoding. Here it's more
about making sure there are still bytes on the wire to be sent when a window
is reopening after a WINDOW_UPDATE etc.

> so, for example, if we decide, we can split into several steps, like http2,
> HPACK, ...

Quite frankly given that a generic config works fine there's no point in
having distinct setups for all the tests, it would be a burden to maintain
and would cause extra confusion.

> h2spec can report in junit format. but no CI can import it (well, gitlab-ci
> can, but I did not try).
> I'd actually prefer to see history test by test (and for reg-tests as well)

By default in verbose more you have all the output and a summary of failed
tests at the end, which is very easy to read.

> the most we can do (and it is relatively cheap) is to define several steps
> in github actions.
> like, I already done for "build" and "download h2spec", we can define
> several steps for h2spec itself.

I think it's asking for more difficulties and pain than really needed.
The normal case is that h2spec should work fine so we don't need to have
details about what fails, if it fails we can check the output and see what
test failed. You'll never know why anyway, it will always require manual
attempts to reproduce.

Just my two cents,

Reply via email to