Hi Willy, On Tue, Aug 25, 2020 at 14:53:05PM +0200, Willy Tarreau wrote:
> Thus an HTTP/2 request effectively "looks like" an HTTP/1 request using > an absolute URI. What causes the mess in the logs is that such HTTP/1 > requests are rarely used (most only for proxies), but they are perfectly > valid and given that they are often used to take routing decisions, it's > mandatory that they are part of the logs. For example if you decide that > every *url* starting with "/img" has to be routed to the static server > and the rest to the application, you're forgetting that "https://foo/img/"; > is valid as well and will be routed to the application. That's what I do > not want to report fake or reconstructed information in the logs. > > In 1.8, what happened when we introduced H2 is that it was directly turned > into HTTP/1.1 before being processed and that given that we didn't support > server-side H2, the most seamless way to handle it was to just replace > everything with origin requests (no authority). That remained till 2.0 > since it was not really acceptable to imagine that depending on whether > you enabled HTX or not you'd get different logs for the exact same request. > But now we cannot cheat anymore, it had caused too much trouble already I clearly understood the problem is more complex than it seems in the first place, due to protocol + internal representations changes that occured recently. > What I understand however is that it's possible that we need to rethink > what we're logging. Maybe instead of logging the URI by default (and missing > the Host in HTTP/1) we ought to instead log the scheme, authority and path > parts. These are not always there (scheme or authority in H1) but we can > log an empty field like "-" in this case. Clearly that was my point. Especially when you manipulate "high-level variables" such as %HP %HQ %HU and so on, you probably expect the hard work to be done for you. > We cannot realistically do that in the default "httplog" format, but we > can imagine a new default format which would report such info (htxlog?), > or maybe renaming httplog to http-legacy-log and changing the httplog's > default. We should then consider this opportunity to revisit certain > fields that do not make sense anymore, like the "~" in front of the > frontend's name for SSL, the various timers that need to report idle > and probably user-facing time instead of just data, etc. I +1 on this as a tradeoff (even though ~ in front frontends is already OK by using %f vs. %ft - I understand it's more a matter of leveraging this change in order to remove tech debt). > So I think it's the right place to open such a discussion (what we should > log and whether or not it loses info by default or requires to duplicate > some data while waiting for the response), so that we can reach a better > and more modern solution. I'm open to proposals. That's wider than I initially thought :) -- Pierre
