Font paths (maybe others) not resolved correctly in epub files

What happened?

I added an epub file to my Kavita service. It is a programming book that has many code examples that should be rendered in a monospace font. However, the font is not correctly loaded by the browser because of the way Kavita handles the font path, as defined inside a CSS file.

When rendering the ebook, the served HTML produces HTTP requests of the form:

https://<my server>/api/book/13/book-resources?apiKey=<api key>&file=css/../fonts/UbuntuMono-RI.ttf

and they produce HTTP 400 errors, with the output: "File was not found in book"

What did you expect?

The path css/../fonts/UbuntuMono-RI.ttf should be properly normalized into fonts/UbuntuMono-RI.ttf so that it can be fetched and rendered correctly.

Kavita Version Number - If you don't see your version number listed, please update Kavita and see if your issue still persists.

0.9.1.4 - Stable

Are you accessing kavita through a reverse proxy? If yes, confirm that the issue persists with a direct connection

Yes

What operating system is Kavita being hosted from?

Docker (Other)

If the issue is being seen on Desktop, what OS are you running where you see the issue?

None

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Chrome

If the issue is being seen on Mobile, what OS are you running where you see the issue?

None

If the issue is being seen on the Mobile UI, what browsers are you seeing the problem on?

No response

Relevant log output

kavita  | [Kavita] [2026-09-15 19:11:01.649 -05:00  43] [Information] Serilog.AspNetCore.RequestLoggingMiddleware HTTP GET "/api/book/13/book-resources?apiKey=******REDACTED******&file=css/../fonts/UbuntuMono-RI.ttf" responded 400 in 11.4552 ms

Additional Notes

This has been reported before: #3757

Sadly, the answer from Kavita maintainers in that issue was not helpful. They repeatedly try to blame it on "books having invalid metadata", but that is not the case. It was not the case in the original report made in #3757, and it is not the case here. It is not wrong for a EPUB file to have CSS files that reference resources (fonts, among other things) with relative paths (relative to the location of the CSS file itself). The suggested solution of "re-exporting", "flattening", etc. the book with external tools is a work-around to the bug, but is not a solution at all since the epub files are not "broken".

Looking into it, I see that a candidate location to fix this issue could be in the CleanContentKeys method inside BookService.cs. The current algorithm inside that method is quite simple, but wrong. It should ideally deal with paths that contain relative segments and normalize them correctly (e.g. A/B/../C/foo → A/C/foo, A/B/../../C/foo → C/foo and so on.)

I don't know what would be the best way to handle that path normalization since I don't know much C#, but something like the Uri class might be it? Anyway, thanks for your time and the Kavita software which is otherwise a really useful tool.