Komga doesn't log Tomcat errors

rmanne commented 3 months ago

Steps to reproduce

Install komga
Set up komga behind an nginx proxy
curl -u <auth> 'https://<url/basePath>/opds/v1.2/books/<book ID>/path/<... file path>' (file path includes spaces / other special characters)

Observe the following output of this API matches tomcat's default:

<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>

Expected behavior

Logs should indicate why tomcat rejected the request. There's no way to set up debug logs for komga's internal HTTP server (Tomcat). This makes it very difficult to debug integration between my reverse proxy (nginx) and komga. It's really not clear at all why the setup works fine for most of komga but just doesn't work at all for opds.

Actual behavior

There are no logs at all indicating there was any kind of error.

Logs

No response

Komga version

1.11.1

Operating system

NixOS

Installation method

jar

Other details

No response

Acknowledgements

[X] I have searched the existing issues (open AND closed) and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have checked the FAQ.
[X] I have updated the app to the latest version.
[X] I will fill out all of the requested information in this form.

rmanne commented 3 months ago

I ended up figuring out what the actual issue was by setting nginx up to proxy pass to a different port that I was watching with nc. It turned out nginx was url decoding the input before passing it along because I was setting a uri. Simply removing it fixed the issue. (Reference: https://serverfault.com/questions/459369/disabling-url-decoding-in-nginx-proxy)

This should still be a fair request, though. It's easy to reproduce the 400 bad error by just doing something like:

> curl 'http://127.0.0.1:43101/komga/opds/v1.2/books/\[1\]'
<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>

Despite not providing any authentication header, this returns 400 bad error instead of 401/403, and such a request doesn't get logged in the access logs for komga, so if I was running komga outside of a reverse proxy, such a request wouldn't show up when trying to determine who attempted and failed to log in. Does this deserve an additional bug report?

gotson commented 2 months ago

it cannot return a 401/403 if the url is not even correct.

gotson / komga