I think you forgot to attach the patch I did try to add the continue patch for the “blacklisted” headers, and same result (now in this case, it happened on the website request itself:
POST Request to site: h2s_frt_make_resp_data:3180 h2s_frt_make_resp_data:3067 GET Request to site: h2_frt_decode_headers:2621 h2_frt_decode_headers:2643 A bit background info on why you see post and get: Basically it’s a dropdown with automatic submit which then does a 302 redirect – so I post a bit of data e.g. following: _token TApEQSj4V3D3TZXXXXXXXXCUYauWoPan1mKhrk date 12/2017 zone 1 The application will then do a redirect to a specific page based on that input data. On 29/12/2017, 19.11, "Willy Tarreau" <[email protected]> wrote: On Fri, Dec 29, 2017 at 06:02:15PM +0000, Lucas Rolff wrote: > POST Request (to website): > h2s_frt_make_resp_data:3180 > h2s_frt_make_resp_data:3067 > - > GET Request (to website): > h2s_frt_make_resp_data:3180 > h2s_frt_make_resp_data:3067 > - > Get Request (app.css) > h2_frt_decode_headers:2621 > h2_frt_decode_headers:2643 Excellent, it's this one : /* OK now we have our header list in <list> */ outlen = h2_make_h1_request(list, bi_end(buf), try); if (outlen < 0) { h2c_error(h2c, H2_ERR_COMPRESSION_ERROR); goto fail; } Now I'm starting to wonder whether it's true or not that the Connection header is *never* sent... But it might also be that something else violates the rules. Would you want to retest with the extra patch attached ? It will do the same with h2.c which is responsible for h2_make_h1_request() so that we know better. And after this you could try again by applying the patch I sent this morning which silently skips the connection headers (replaces a goto fail with a continue). Do not hesitate to ask me to redo it if you've lost it! Cheers, Willy
