сб, 21 мар. 2020 г. в 15:23, Willy Tarreau <w...@1wt.eu>:

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

I created 16kb response file, and found something that looks like an error

Run ./haproxy -f .github/h2spec.config -D
[WARNING] 083/174625 (3194) : custom error message file '.github/errorfile'
larger than 16384 bytes. Truncating.
[ALERT] 083/174625 (3194) : parsing [.github/h2spec.config:29] : errorfile
: unable to convert custom error message file '.github/errorfile' in HTX.
[ALERT] 083/174625 (3194) : Error(s) found in configuration file :
[ALERT] 083/174625 (3194) : Fatal errors found in configuration.

since, I see "WARNING", i.e. "no worry, I'll truncate file". but file is
not loaded :-)

I reduced file size a bit, 146/146 tests


no valgrind yet, but we can add it later.

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

Reply via email to