Christopher Faulet comments

Results 325 comments of


                                            Christopher Faulet

QUIC: Assert failure in qcs_is_close_local

Damned ! Thanks Tristan, We'll take a look

QUIC: Assert failure in qcs_is_close_local

Sorry to ask Tristan, are you sure you've applied the patch above ? I asked because we don't understand how it is possible to call `qmux_strm_done_ff` here. We are still...

QUIC: Assert failure in qcs_is_close_local

No problem. I prefer this explanation

QUIC: Assert failure in qcs_is_close_local

Thanks guys. The fix was backported to 2.9. I'm closing the issue.

QUIC: Assert failure in qcs_is_close_local

Nop, Amaury's fix must be backported as far as 2.6.

In some circumstances, TCP receive queue fills up despite sockets being closed

I checked. At first glance, it seems similar but I doubt it is related. Especially because here the listeners don't seems to be limited when the issue occurred.

In some circumstances, TCP receive queue fills up despite sockets being closed

However, the fix was backported, thus it can be tested.

In some circumstances, TCP receive queue fills up despite sockets being closed

Thanks for the confirmation :) So it is indeed another issue.

Unexpected and random content-length in HTTP/1.0 responses with filter bwlim-out and 3.0-dev7-50d8c1-78

The issue here is about the bwlim filter mixed with `http-after-response del-header content-length` rule. So there is an unexpected side effect here and I'm annoyed because I don't know yet...

Unexpected and random content-length in HTTP/1.0 responses with filter bwlim-out and 3.0-dev7-50d8c1-78

HTTP/1.0 without explicit `connection: keep-alive` header is always in close mode. In HAProxy, it is unexpected to change or remove the `content-length` header. The same is true with `transfer-encoding` header....