Provide a way to disable logging of requests/responses on certain urls about logbook

[AlexanderYastrebov]

This could be implemented by overriding (Default)HttpLogWriter.isActive and considering request uri there.
But this approach works at Logbook level and has no simple means to distinguish between incoming and outgoing requests.

[AlexanderYastrebov]

Related to #47

[AlexanderYastrebov]

The incoming/outgoing bisection could be achieved by using two Logbook configurations

[lukasniemeier-zalando]

If I understand you correctly 1 is proposing to enable further (custom) filtering inside the _LogbookFilter _ besides what filter registration allows?

While we'd have to do the same in every outgoing adapter (like logbook-httpclient) too, I think the filter and the adapters are the right place to do it, because then near-to-none runtime overhead for ignored URLs is added.

[AlexanderYastrebov]

@lukasniemeier-zalando

1. Yes, first approach raises because there is no way to exclude urls using standard filter registration.
2. Actually right now I like two Logbook conf and overriding HttpLogWriter.isActive approach, because then it is possible to configure logging of incoming and outgoing request differently (e.g. add "incoming" / "outgoing" marker) and exclusion/inclusion logic sits near Logbook conf and not in 100500 different filters/interceptors/etc
3. Overhead should be considered later as it is premature optimization at this point.
4. There could be also interesting usecases on response such as log only responses with certain code etc

[lukasniemeier-zalando]

1. 👍
2. I took a look at HttpLogWriter and it seems like isActive actually steers the buffering of requests/responses, so it seems we are fine there!
3. Logbook potentially adds a non-marginal amount of overhead - therefore if it provides a "skip" feature there is a good chance users expect this to work in a way that skipped requests/responses are just "pass-through". We already have seen Logbook used in a high-volume live environment 😉 so IMO it make sense to think about it (but see 2).
4. 👍

[whiskeysierra]

It's true, the isActive method is the best place to do this right now, but I don't think it's the right place, conceptually. Right now we only have formatters and writers and they define the how and the where to respectively. E.g. the default writer just delegates to a logger and it implements isActive by checking whether the logger is actually enabled for the level which is fine. If we start to throw in URL white/blacklists in there we are mixing different aspects/abstractions. I guess we need something new.