сб, 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 : .github/h2spec.config [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 https://github.com/chipitsine/haproxy/runs/531318490 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 >