On 4/18/23 17:07, Zakharychev, Bob wrote:
> While experimenting with enabling QUIC in HAProxy sitting in front of
> our closed-source application I stumbled upon a reproducible QUIC
> protocol failure/malfunction while accessing specific CSS resource,
> which is served via internal application proxy: accessing it over QUIC
> results either in ERR_QUIC_PROTOCOL_FAILURE in the browser and no
> mention of request in HAProxy log or incomplete resource being download
> and CD-- request termination flags in HAProxy log (and logged request
> looks a bit different from other, successful, H3 requests). Accessing
> the same resource over HTTP/2 works fine. I need help with setting up a
> proper debug session so that I could capture all necessary information
> which may help with fixing this issue: HAProxy internal
> debugging/tracing flags to enable, etc. I don’t want to open a bug on
> GitHub for this and would appreciate if anyone from HAProxy team could
> reach out to me directly so that I could share relevant information and
> attempt to debug under your direction.
>
>
>
> Thanks in advance,
>
> Vladimir “Bob” Zakharychev
>
>
>
Hello,
Please ignore my first mail which was not sent to the haproxy mailing list.
If possible, please enable the traces with these lines in the global
section:
global
expose-experimental-directives
trace quic sink buf1
trace quic level developer
trace quic start now
trace qmux sink buf1
trace qmux level developer
trace qmux verbosity minimal
trace qmux start now
trace h3 sink buf1
trace h3 level developer
trace h3 start now
trace h3 verbosity minimal
Note that you must also set a ring named <buf1> as follows at the same
level as the global section:
ring buf1
size 134217728
format timed
backing-file /dev/shm/blah
Adapt the <size> value at your convenience. Note that here we use a
temporary filesystem in RAM (/dev/shm) for performance reason.
Also note that enabling the traces may slow down your applications.
