Re: [PATCH] MINOR: Add either(,) converter

Willy, Am 11.09.20 um 16:46 schrieb Willy Tarreau: > First, I really like the feature, that's a great idea. :-) >>> - choice (my initial choice) >>> - ifor / if_or >>> - ifelse / if_else >>> - iftrue (with the argument being optional) >> >> Maybe something like this would be appropriate (IIF)?

[PATCH] MINOR: Add either(,) converter

Willy, [keep this email in CC, it's not subscribed to the list] "either() takes a boolean as input and returns one of the two argument strings depending on whether the boolean is true." Find the full details in the attached patch. --- We've had a bit of discussion regarding the naming of the

Re: [PATCH] MINOR: Add either(,) converter

Miroslav, Am 11.09.20 um 17:10 schrieb Miroslav Zagorac: > there is a small typo in the patch, if says 'iff' instead of 'iif': > > --- > +  Example: > +    http-request set-header x-forwarded-proto %[ssl_fc,iff(https,http)] > --- > Fun. I didn't receive your reply on company mail. I only got

Large difference between response time as measured by nginx and as measured by HAProxy

Hi List, please keep this email in Cc for all responses, I am not subscribed to the list. We are running HAProxy 2.1.8 in front of nginx serving static files and acting as a FastCGI gateway. HAProxy is communicating with nginx using HTTP/2. Clients are regular web browsers, mostly using HTTP/2.

Re: Large difference between response time as measured by nginx and as measured by HAProxy

Ilya, Am 26.08.20 um 13:13 schrieb Илья Шипицин: > nginx buffers output by default. > > can you try > > proxy_request_buffering off; > proxy_buffering off; > The GIF file with the 734ms difference in response time between the two logs is a static file served from the local file system. The

Re: Large difference between response time as measured by nginx and as measured by HAProxy

Willy, Am 26.08.20 um 16:59 schrieb Willy Tarreau: > On Wed, Aug 26, 2020 at 12:59:55PM +0200, Tim Düsterhus, WoltLab GmbH wrote: >> Within the HAProxy logs we're sometimes seeing largish 'Tr' values for >> static file requests. For example 734ms for the example request below. &

Re: Large difference between response time as measured by nginx and as measured by HAProxy

Willy, Am 27.08.20 um 10:29 schrieb Willy Tarreau: >> I now have the trace results and my HAProxy log where I can correlate >> the slow requests using the timestamp and path. Unfortunately the trace >> does not appear to contain the unique-id of the request. > > Sadly, due to the way HPACK works

Re: Large difference between response time as measured by nginx and as measured by HAProxy

Willy, Am 26.08.20 um 17:51 schrieb Willy Tarreau >> As I said: It's not really reproducible. > > Yeah but we all have a definition of "not really reproducible". As you > consider that it doesn't happen in HTTP/1 after only 4 hours, for me > this means you expect it to usually happen at least

Re: Large difference between response time as measured by nginx and as measured by HAProxy

Hi List, Am 27.08.20 um 11:45 schrieb Tim Düsterhus, WoltLab GmbH: >> You can see two h2c connections, one is on the frontend (hence the 'F') >> and the other one is on the backend. The h2s is the H2 stream, unique to >> a request (though it comes from a pool, so it will

[PATCH] BUG/MINOR: http_act: don't check capture id in backend (2)

Willy, find the patch attached. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P >From

Re: Disable client keep-alive using ACL

Lukas, Am 17.11.20 um 17:37 schrieb Lukas Tribus: >>> is it possible to reliably disable client keep-alive on demand based on >>> the result of an ACL? >>> >>> I was successful for HTTP/1 requests by using: >>> >>> http-after-response set-header connection close if foo >>> >>> But apparently that

Re: Disable client keep-alive using ACL

Christopher, Am 19.11.20 um 11:47 schrieb Christopher Faulet: > Le 19/11/2020 à 10:49, Tim Düsterhus, WoltLab GmbH a écrit : >> John, >> >> Am 19.11.20 um 06:57 schrieb John Lauro: >>> A couple of possible options... >>> You could use tcp-request inspect-d

Re: Disable client keep-alive using ACL

John, Am 19.11.20 um 06:57 schrieb John Lauro: > A couple of possible options... > You could use tcp-request inspect-delay to delay the response a number of > seconds (and accept it quick if legitimate traffic). I believe the tcp-(request|response) rules only apply to the very first buffer of a

Re: Disable client keep-alive using ACL

Hi Am 09.11.20 um 12:36 schrieb Tim Düsterhus, WoltLab GmbH: > is it possible to reliably disable client keep-alive on demand based on > the result of an ACL? > > I was successful for HTTP/1 requests by using: > > http-after-response set-header connection close if foo &

Disable client keep-alive using ACL

Hi List is it possible to reliably disable client keep-alive on demand based on the result of an ACL? I was successful for HTTP/1 requests by using: http-after-response set-header connection close if foo But apparently that has no effect for HTTP/2 requests. I was unable to find anything

[PATCH] BUG/MINOR: cache: Correctly handle existing-but-empty, 'accept-encoding' header

Remi, please find a small fix for the 'Vary' support of the cache to correctly handle the difference between a missing 'accept-encoding' and an empty 'accept-encoding'. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331

Re: [PATCH] BUG/MINOR: cache: Correctly handle existing-but-empty, 'accept-encoding' header

Remi, On 6/18/21 3:46 PM, Remi Tricot-Le Breton wrote: please find a small fix for the 'Vary' support of the cache to correctly handle the difference between a missing 'accept-encoding' and an empty 'accept-encoding'. Nice catch, I completely forgot about this case. Frankly it's a bit

Termination Code 'CC' + HTTP status?

Hi List [this email is not subscribed, please keep it in Cc] I'd like your advice on a few log entries that confuse me. I am seeing HTTP 2.0 requests dying with a termination code of 'CC', i.e.: C : the TCP session was unexpectedly aborted by the client. C : the proxy was

Re: Termination Code 'CC' + HTTP status?

Willy, On 5/25/21 11:02 AM, Willy Tarreau wrote: We've already noted that significant improvements in close/abort need to be made to 1) process them better and 2) report them more accurately. This is a tedious task which *will* inevitably cause regressions, but it's the price to pay to improve

Re: Termination Code 'CC' + HTTP status?

Willy, On 5/21/21 6:48 PM, Willy Tarreau wrote: I'd like your advice on a few log entries that confuse me. I am seeing HTTP 2.0 requests dying with a termination code of 'CC', i.e.: C : the TCP session was unexpectedly aborted by the client. C : the proxy was waiting for the

[PATCH] MINOR: halog: Add -qry parameter allowing to preserve the query string in -uX

Willy, please find the patch attached. Our use-case for this is a dynamic application that performs routing based on the query string. Without this option all URLs will just point to the central entrypoint of this location, making the output completely useless. Best regards Tim Düsterhus

[PATCH] halog stuff

Willy, please find another halog series attached. 1. Some small changes to the new -qry/-query flag. 2. A new -hdr flag, resolving my own GitHub issue. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338

Re: [PATCH] halog stuff

Willy, On 10/28/21 6:50 PM, Willy Tarreau wrote: Just one thing (but do not worry, I'll rearrange it later), I initially took great care of limiting the output to 80 columns for having suffered a few times from it, and I think it broke when time ranges were added. ack From

Re: [PATCH] halog stuff

Willy, On 10/28/21 6:50 PM, Willy Tarreau wrote: Just one thing (but do not worry, I'll rearrange it later), I initially took great care of limiting the output to 80 columns for having suffered a few times from it, and I think it broke when time ranges were added. This did not happen, yet. So

Re: [OPINIONS DESIRED] (was Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name)

Willy, On 3/27/23 20:25, Willy Tarreau wrote: OK, let's see what other users and participants think about it. If I get at least one "please don't change it" I'll abide, otherwise it may make sense to fix it before it ossifies and annoys some future users. Anyone has any opinion here ? Wanted

Re: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name

Willy, On 3/27/23 18:17, Willy Tarreau wrote: Hmmm that's embarrassing indeed. On the one hand we should consider that it's part of the visible API and should stay like this eternally (like "Referer" in HTTP). On the other hand, it was introduced only in 2.3, splicing is not the most commonly

[PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name

Hi please find the patch attached. This email address is not subscribed to the list, please keep it in Cc when replying. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com

[PATCH] DOC: Attempt to fix dconv parsing error for tune.h2.fe.initial-window-size

Hi please find the patch attached. This email address is not subscribed to the list, please keep it in Cc when replying. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com

[PATCH] Add missing tune.h2.* options to table of contents

Hi please find two patches attached. This email address is not subscribed to the list, please keep it in Cc when replying. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com

Re: [PATCH] DOC: Attempt to fix dconv parsing error for tune.h2.fe.initial-window-size

Hi On 6/13/23 15:18, Tim Düsterhus, WoltLab GmbH wrote: please find the patch attached. This email address is not subscribed to the list, please keep it in Cc when replying. Ping :-) There's also a second patch email I sent around the same time where I'm not sending a second ping to reduce