Re: Reproducible ERR_QUIC_PROTOCOL_ERROR with all QUIC-enabled versions (2.6 to latest 2.8-dev)

2023-04-18 Thread Frederic Lecaille
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  as follows at the same
level as the global section:

ring buf1
size 134217728
format timed
backing-file /dev/shm/blah

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



Re: Reproducible ERR_QUIC_PROTOCOL_ERROR with all QUIC-enabled versions (2.6 to latest 2.8-dev)

2023-04-18 Thread Aleksandar Lazic

Hi Bob.

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


In case you use the HAProxy Enterprise can you get in touch via 
https://www.haproxy.com/contact-us/ or 
https://my.haproxy.com/portal/cust/login


Here are the support options listed.
https://www.haproxy.com/support/support-options/

In case you use the Open Source version please run `haproxy -vv` (with 
two `v`).


What is your configuration?
* Include as much configuration as possible, including global and 
default sections.

* Replace confidential data like domain names and IP addresses.



Thanks in advance,

    Vladimir “Bob” Zakharychev


Regards
Alex



Reproducible ERR_QUIC_PROTOCOL_ERROR with all QUIC-enabled versions (2.6 to latest 2.8-dev)

2023-04-18 Thread Zakharychev, Bob
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