I understand that all parts of HTTP requests (within TLS) are equally "private", however HTTP path is considered non-secret by most HTTP client and server libraries. That means they don't think twice before logging the paths.
Server part is covered by your project, however user must be aware of that if they run telegram-bot-api behind reverse HTTP proxy. You need to adjust your configs so the access URLs are not logged in access.log.
The same applies for clients: HTTP clients library do not think twice about logging the URLs. While direct HTTP requests logging is usually disabled by default or performed at very verbose log level which is usually filtered out, they also do not hesitate to insert URL into the exception message. Which is usually printed by library user at WARN/ERROR severity.
That means that if a bot developer (or client library developer) wants to avoid leaking Telegram token to the logs, they need very deep knowledge of the implementation specifics of the HTTP library they are using. Usually such specifics are not a part of public library contract, so when they bump the HTTP client version, they have to check for these details again.
Here is the level of hacks you may have to do as a bot API user:
https://github.com/gagarski/vertigram/blob/88127d7b9cc2a98a4581816cec0c6de915b6a811/vertigram-telegram-client/src/main/kotlin/ski/gagar/vertigram/telegram/client/impl/TelegramImpl.kt#L129-L134
https://github.com/gagarski/vertigram/blob/88127d7b9cc2a98a4581816cec0c6de915b6a811/vertigram-telegram-client/src/main/kotlin/ski/gagar/vertigram/telegram/client/impl/TelegramImpl.kt#L43-L47
Hiding token somewhere in the header does not formally increase security, but solves the problem: it's harder to accidentally print HTTP headers in your logs and even harder if you use Authorization header for this (at least any reasonable HTTP library won't do that).
I understand that all parts of HTTP requests (within TLS) are equally "private", however HTTP path is considered non-secret by most HTTP client and server libraries. That means they don't think twice before logging the paths.
Server part is covered by your project, however user must be aware of that if they run telegram-bot-api behind reverse HTTP proxy. You need to adjust your configs so the access URLs are not logged in access.log.
The same applies for clients: HTTP clients library do not think twice about logging the URLs. While direct HTTP requests logging is usually disabled by default or performed at very verbose log level which is usually filtered out, they also do not hesitate to insert URL into the exception message. Which is usually printed by library user at WARN/ERROR severity.
That means that if a bot developer (or client library developer) wants to avoid leaking Telegram token to the logs, they need very deep knowledge of the implementation specifics of the HTTP library they are using. Usually such specifics are not a part of public library contract, so when they bump the HTTP client version, they have to check for these details again.
Here is the level of hacks you may have to do as a bot API user:
https://github.com/gagarski/vertigram/blob/88127d7b9cc2a98a4581816cec0c6de915b6a811/vertigram-telegram-client/src/main/kotlin/ski/gagar/vertigram/telegram/client/impl/TelegramImpl.kt#L129-L134
https://github.com/gagarski/vertigram/blob/88127d7b9cc2a98a4581816cec0c6de915b6a811/vertigram-telegram-client/src/main/kotlin/ski/gagar/vertigram/telegram/client/impl/TelegramImpl.kt#L43-L47
Hiding token somewhere in the header does not formally increase security, but solves the problem: it's harder to accidentally print HTTP headers in your logs and even harder if you use
Authorizationheader for this (at least any reasonable HTTP library won't do that).