Access log is pretty useless for vibe server behind a proxy

[schveiguy]

When I turned on the access log for my vibe server that lives behind a proxy, I get for example:

127.0.0.1:52152 - - 2023-Sep-09 08:17:54.4165897Z "GET /customers/job/?filter=%5B%5D HTTP/1.1" 403 1216 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"

That 127.0.0.1 is the address of the Apache server that has forwarded the request.

The X-Forwarded-For header is properly set, but the access log ignores it.

It would be nice if there was a setting on the server to overwrite the IP address of the client peer with the IP address of the X-Forwarded-For inside the HTTPServerRequest object, so it seamlessly works without having to change code that looks at the peer address.

[schveiguy]

I've since discovered that the log is kind of cool because you can customize it. But not really.

In fact the part which does all the intelligence is a final function in the HTTPLogger interface. Why? I would like to fix the issue with the X-Forwarded-For (which I actually fixed by changing the format), plus add the user id who is logged in (specific to my application).

I was resigned to fixing this using a pre-process step, but the advantage of using the builtin logger is that it has access to what happened in the response.

Now, I'm thinking what we want is to reorganize this logger -- HTTPLogger should abstract not only the output of the string to the log file, but also the creation of the string. It would not be difficult to just add calls to the apache formatter in all the implementations. This allows hooking all parts of the logger given access to the request and the response.

[s-ludwig]

I absolutely agree, HTTPLogger should be changed into an interface, with the option to later also support it as a statically typed compile time interface (as is the case for the stream types). I've never actually used the logging functionality, which is why it just stayed in that initial state.

Apart from that, I think the format string uses the Apache format (might also be Nginx, I don't remember), so it would make sense to take another look at that to see whether there are any extensions that would fit the bill here, while staying "standard" compatible. For the username part, we could probably allocate two unused letters and make the params and context fields available for logging custom fields.

[schveiguy]

make the params and context fields available for logging custom fields

I think that would be enough for my purposes. But in general, if we are to abstract the actual logging function, it needs access to all the things that are used by the apache formatter.

In the end, I just ended up not bothering with the log, because my vibe server is behind an apache proxy (which is already logging all this information).