On Thu, Jul 08, 2021 at 02:48:32PM +0200, Willy Tarreau wrote: > On Thu, Jul 08, 2021 at 02:18:32PM +0200, William Lallemand wrote: > > I saw that you hesitated between "conn_status" and "conn_err_code", the > > "conn_" prefix could be confusing at some point once you try to have > > errors on the frontend and the backend side in the same log-format, I > > think something starting by "fc_conn_" would be more understandable. > > Indeed, and more consistent with what we already have. fc_* is for the > front connection, bc_* is for the back connection. By the way if we're > focusing on SSL it should even be ssl_fc_* (we already have a ton of > them, nobody will find the new one if it doesn't use the same prefix). >
That's what Rémi implemented for the SSL fetches, but the connection error one is more generic and does not focus on SSL at all. > > That seems good to me, we only need frontend info IMHO. People who need > > the SSL backend connection are not the most common case so they could > > make their own log-format with it. > > I tend to think that if we're focusing on https vs http, it makes sense > to consider the frontend only as well for the standard logs. > I agree. > Also some background on the log format, originally we used to place the > URI at the end of the line because most loggers used to truncate logs > at 1024 bytes and the tail of the URI was far less important than other > fields. This explains why we've started to insert certain fields at > certain places before this. 20 years later I think it is perfectly > reasonable to consider appending fields *after* the URI, which is also > a great way of applying minimal changes to existing log parsers, and > to allow http/https log lines to be easily compared when aligned. > I agree, this way it's easily readable without having to realign mentally the fields in common between an http line and an https one. -- William Lallemand
