Re: Proposal about new default SSL log format

2021-07-07 Thread Remi Tricot-Le Breton
Hello, On 06/07/2021 14:55, Willy Tarreau wrote: On Tue, Jul 06, 2021 at 12:19:56PM +0200, Tim Düsterhus wrote: Willy, On 7/6/21 12:12 PM, Willy Tarreau wrote: A few points first, that are needed to address various concerns. The goal here is to defined an HTTPS log format because that's what

Re: Proposal about new default SSL log format

2021-07-06 Thread Remi Tricot-Le Breton
Hello Aleksandar, On 03/07/2021 13:19, Aleksandar Lazic wrote: Hi Remi. How about to combine ssl_version/ssl_ciphers in one line. Yes why not. It would be helpful to see also the backend status. Maybe add a 14th and 15th line with following fields *backend_name '/' conn_status '/' SSL

Re: Proposal about new default SSL log format

2021-07-05 Thread Remi Tricot-Le Breton
Hello, On 02/07/2021 16:52, Илья Шипицин wrote: I worked with log formats a lot, couple of thoughts 1) tab separated is better for any log import tool (mixing spaces and "/" is terrible for import) I don't have any problems with that apart from inconsistency with the other default formats.

Re: Proposal about new default SSL log format

2021-07-05 Thread Remi Tricot-Le Breton
Hello, On 02/07/2021 16:56, Илья Шипицин wrote: also, "process name" is something that is prior knowledge. no need to log it every time (for millions of requests) This process name part does not seem to come from the log format line, it is never mentioned in the HTTP log-format string. If it

Re: Proposal about new default SSL log format

2021-07-05 Thread Remi Tricot-Le Breton
Hello Tim, On 02/07/2021 16:34, Tim Düsterhus wrote: Remi, On 7/2/21 4:26 PM, Remi Tricot-Le Breton wrote: But if anybody sees a missing information that could be beneficial for everybody, feel free to tell it, nothing is set in stone yet. […] Feel free to suggest any missing data, which

Proposal about new default SSL log format

2021-07-02 Thread Remi Tricot-Le Breton
Hello list, Some work in ongoing to ease connection error and SSL handshake error logging. This will rely on some new sample fetches that could be added to a custom log-format string. In order to ease SSL logging and debugging, we will also add a new default log format for SSL connections.

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

2021-06-18 Thread Remi Tricot-Le Breton
Hello Tim, On 18/06/2021 15:26, Tim Düsterhus, WoltLab GmbH wrote: 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

Re: Upgrading from 1.8 to 2.4, getting warning I can't figure out

2021-06-08 Thread Remi Tricot-Le Breton
Hello, On 07/06/2021 01:23, Shawn Heisey wrote: On 6/5/2021 10:47 PM, Shawn Heisey wrote: On 6/5/2021 9:30 PM, Shawn Heisey wrote: [WARNING]  (81457) : Loading: OCSP response status not successful. Content will be ignored. This error message happens when a call to OpenSSL's

Re: [PATCH 1/3] MINOR: cache: Remove the `hash` part of the accept-encoding secondary key

2021-01-18 Thread Remi Tricot-Le Breton
Hello Tim, The patches look good to me. Just one point concerning the first one, you could have removed everything related to ACCEPT_ENCODING_MAX_ENTRIES since the limit was induced by the array that does not exist anymore. The comment of the accept_encoding_normalizer function does not match

Re: [PATCH] BUG/MEDIUM: cache: Fix hash collision in `accept-encoding` handling for `Vary`

2020-12-29 Thread Remi Tricot-Le Breton
Hello Willy, Tim, On 29/12/2020 07:52, Willy Tarreau wrote: Hi Tim, On Mon, Dec 28, 2020 at 12:47:52PM +0100, Tim Duesterhus wrote: This patch fixes GitHub Issue #988. Commit ce9e7b25217c46db1ac636b2c885a05bf91ae57e was not sufficient, because it fell back to a hash comparison if the bitmap