I wonder if there're gRPC test tests similar to h2spec (I couldn't find them)
сб, 16 сент. 2023 г. в 18:06, Valters Jansons <[email protected]>: > On Thu, Sep 14, 2023 at 12:35 PM Christopher Faulet <[email protected]> > wrote: > > After a discussion with Willy, we've hopefully found a way to fix the > issue by > > delaying detection of the server abort on the request processing side > when there > > is a response to forward to the client. It should do the trick in your > case and > > it should be safe. > > > > However, the fix remains sensitive. It is really hard to be sure it will > not > > introduce a regression. The worst could be to block a session or to get > a loop > > because of an unhandled event. > > > > Thus it could be go to test it on your side if it is possible. The patch > is in > > attachment. It can be applied on top of the 2.9 or 2.8. Is this possible > for you ? > > I applied the patch on top of v2.9-dev5. For what it's worth, I build > on Ubuntu 22.04 with defaults from INSTALL: TARGET=linux-glibc > USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1. > > The delayed processing patch does not appear to change anything for > me. I am still seeing HTTP 502 (Bad Gateway) and HAProxy logs report > session state as SH--. According to documentation, that is "the TCP > session was unexpectedly aborted by the server, or the server > explicitly refused it" together with "the proxy was waiting for > complete, valid response HEADERS from the server (HTTP only)". > Somehow, if the H2 connection to backend is half-open(local), HAProxy > is expecting more HEADERS from the backend server. > > I am providing a short diff below, which force-closes the H2 > connection to backend upon remote ES (which would break long-running > upload from frontend to client). The change is interesting, because it > highlights something weird with processing. Without this change, even > with your provided patch, HAProxy never finishes processing HEADERS. > However, with this change, response is delivered to the frontend > client when the stream closes. > > The session state is probably not relevant, but for what it's worth, > it becomes CL--. C for "the TCP session was unexpectedly aborted by > the client" -- not sure why unexpectedly, because from the client side > everything received successfully -- and L for "the proxy was still > transmitting LAST data to the client while the server had already > finished. This one is very rare as it can only happen when the client > dies while receiving the last packets". Maybe this gives some other > ideas. > > diff --git a/src/mux_h2.c b/src/mux_h2.c > index cc698b66b..c1ff014dd 100644 > --- a/src/mux_h2.c > +++ b/src/mux_h2.c > @@ -2934,7 +2934,7 @@ static struct h2s *h2c_bck_handle_headers(struct > h2c *h2c, struct h2s *h2s) > else if (h2s->flags & H2_SF_ES_RCVD) { > if (h2s->st == H2_SS_OPEN) > h2s->st = H2_SS_HREM; > - else if (h2s->st == H2_SS_HLOC) > + if (h2s->st == H2_SS_HLOC || h2s->st == H2_SS_HREM) > h2s_close(h2s); > } > > The clients should send proper and timely END_STREAMs, so this should > not be a major issue, but something still feels strange here with > connection state processing. > > Let me know if I can help brainstorm this further. > > Best regards, > Valters Jansons > >
