[Bug] Call to getBookPage fails with 406 when using documented media type

[grim7reaper]

Komga environment

• OS: Archlinux
• Komga version:
• I am running Komga with Docker
  • Docker image tag: gotson/komga:0.64.3

Describe the bug

I'm not sure if it's a bug in the code or in the doc.

The API call getBookPage (at /api/v1/books/{bookId}/pages/{pageNumber}) is documented to be used with the HTTP header accept: image/* (as can be seen in the Swagger).
But this doesn't work: the server answer with a 406.

Steps to reproduce

1. Go to the Swagger page
2. Try a call to /api/v1/books/{bookId}/pages/{pageNumber}
3. Observe a failure with HTTP status code 406

Expected behavior

The page should be returned.

Actual behavior

The server answer with a 406.

Additional context

If you try image/* as documented: you get a 406.

% curl -u '[…]' -v "http://192.168.1.33:1515/komga/api/v1/books/030V7MM336TC9/pages/1" -H "accept: image/*"
*   Trying 192.168.1.33:1515...
* Connected to 192.168.1.33 (192.168.1.33) port 1515 (#0)
* Server auth using Basic with user '[…]'
> GET /komga/api/v1/books/030V7MM336TC9/pages/1 HTTP/1.1
> Host: 192.168.1.33:1515
> Authorization: Basic […]
> User-Agent: curl/7.73.0
> accept: image/*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 406
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Set-Cookie: JSESSIONID=5E9EFC2935F65FAFCE3BD8D947345DE1; Path=/komga; HttpOnly
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Length: 0
< Date: Sun, 01 Nov 2020 19:49:16 GMT
<
* Connection #0 to host 192.168.1.33 left intact

If you try with */*, it works:

%  curl -u '[…]' -v "http://192.168.1.33:1515/komga/api/v1/books/030V7MM336TC9/pages/1" -H "accept: */*"
*   Trying 192.168.1.33:1515...
* Connected to 192.168.1.33 (192.168.1.33) port 1515 (#0)
* Server auth using Basic with user '[…]'
> GET /komga/api/v1/books/030V7MM336TC9/pages/1 HTTP/1.1
> Host: 192.168.1.33:1515
> Authorization: Basic […]
> User-Agent: curl/7.73.0
> accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Set-Cookie: JSESSIONID=6CCB996E05E52B0D9D804CE201EBB7FA; Path=/komga; HttpOnly
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< Last-Modified: Tue, 27 Oct 2020 22:45:24 GMT
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< ETag: "01f696ae31a83ba8be2db4cc3e001890d"
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Type: image/jpeg
< Content-Length: 882390
< Date: Sun, 01 Nov 2020 19:51:32 GMT
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0

We can see that the Content-Type is image/jpeg, but using it as accept also fails with a 406:

%  curl -u '[…]' -v "http://192.168.1.33:1515/komga/api/v1/books/030V7MM336TC9/pages/1" -H "accept: image/jpeg"
*   Trying 192.168.1.33:1515...
* Connected to 192.168.1.33 (192.168.1.33) port 1515 (#0)
* Server auth using Basic with user '[…]'
> GET /komga/api/v1/books/030V7MM336TC9/pages/1 HTTP/1.1
> Host: 192.168.1.33:1515
> Authorization: Basic […]
> User-Agent: curl/7.73.0
> accept: image/jpeg
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 406
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Set-Cookie: JSESSIONID=1D50A7567E355E7CD6E9E2F11B3B13B2; Path=/komga; HttpOnly
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Length: 0
< Date: Sun, 01 Nov 2020 19:51:15 GMT
<
* Connection #0 to host 192.168.1.33 left intact

[gotson]

I think it's a Swagger issue, if you look at the code:

@ApiResponse(content = [Content(
    mediaType = "image/*",
    schema = Schema(type = "string", format = "binary")
  )])

The media type is set for the response, not for the request. I noticed this kind of thing before, where it's difficult to have accurate Swagger documentation for dynamic content. Here the actual return type is a ByteArray, but contains an image, and thus the media type is image/*.

I honestly don't have time to spend on the Swagger annotations to make it work, but if you feel like sending a PR, please do 🙏

[grim7reaper]

Ok, then the Swagger doc looks correct (i.e. if the Content-Type is image/*, then it's fair to suggest using image/* as accept header.)
It's probably an issue with the code then.

With the piece of code you posted + searching on the web for the error message I got in the log:

Resolved [org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation]

I'm wondering if the fix something like that:

--- a/komga/src/main/kotlin/org/gotson/komga/interfaces/rest/BookController.kt
+++ b/komga/src/main/kotlin/org/gotson/komga/interfaces/rest/BookController.kt
@@ -298,7 +298,8 @@ class BookController(
   @GetMapping(value = [
     "api/v1/books/{bookId}/pages/{pageNumber}",
     "opds/v1.2/books/{bookId}/pages/{pageNumber}"
-  ])
+  ], produces = ["image/*"]
+  )
   @PreAuthorize("hasRole('$ROLE_PAGE_STREAMING')")
   fun getBookPage(
     @AuthenticationPrincipal principal: KomgaPrincipal,

Are there instructions somewhere on how to build Komga from the source code?
If so, I could try this fix locally 🙂

[gotson]

Are there instructions somewhere on how to build Komga from the source code?

Check the Readme 😉

[grim7reaper]

Found it 😉

I can confirm that it works with the fix I mentioned

--- a/komga/src/main/kotlin/org/gotson/komga/interfaces/rest/BookController.kt
+++ b/komga/src/main/kotlin/org/gotson/komga/interfaces/rest/BookController.kt
@@ -298,7 +298,7 @@ class BookController(
   @GetMapping(value = [
     "api/v1/books/{bookId}/pages/{pageNumber}",
     "opds/v1.2/books/{bookId}/pages/{pageNumber}"
-  ])
+  ], produces = ["image/*"])
   @PreAuthorize("hasRole('$ROLE_PAGE_STREAMING')")
   fun getBookPage(
     @AuthenticationPrincipal principal: KomgaPrincipal,

Both with image/*

% curl -u 'test@test.com:test' -v "http://127.0.0.1:8080/api/v1/books/032MKDEPTH6HD/pages/1" -H "accept: image/*"
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'test@test.com'
> GET /api/v1/books/032MKDEPTH6HD/pages/1 HTTP/1.1
> Host: 127.0.0.1:8080
> Authorization: Basic dGVzdEB0ZXN0LmNvbTp0ZXN0
> User-Agent: curl/7.73.0
> accept: image/*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Set-Cookie: remember-me=dGVzdCU0MHRlc3QuY29tOjE2MDY5MDgzNTc3NTk6NjFiY2ViMmQ1OTY1OTQwODNmNmRhNzk3MGYwYTM5NTk; Max-Age=2592000; Expires=Wed, 02-Dec-2020 11:25:57 GMT; Path=/; HttpOnly
< Set-Cookie: JSESSIONID=795D59771EA7255E9800E2260A52CA97; Path=/; HttpOnly
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< Last-Modified: Mon, 02 Nov 2020 12:25:38 GMT
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< ETag: "0526480051d045cefc01be56bb5a1faac"
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Type: image/jpeg
< Content-Length: 581960
< Date: Mon, 02 Nov 2020 11:25:57 GMT
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0

and image/jpeg (if one know the type beforehand):

% curl -u 'test@test.com:test' -v "http://127.0.0.1:8080/api/v1/books/032MKDEPTH6HD/pages/1" -H "accept: image/jpeg"
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'test@test.com'
> GET /api/v1/books/032MKDEPTH6HD/pages/1 HTTP/1.1
> Host: 127.0.0.1:8080
> Authorization: Basic dGVzdEB0ZXN0LmNvbTp0ZXN0
> User-Agent: curl/7.73.0
> accept: image/jpeg
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Set-Cookie: remember-me=dGVzdCU0MHRlc3QuY29tOjE2MDY5MDgzNjQ5MzU6MjIyM2NiMGZiZmE5Yjg0YjMzYjY1MzliZmE5MjA4OWE; Max-Age=2592000; Expires=Wed, 02-Dec-2020 11:26:04 GMT; Path=/; HttpOnly
< Set-Cookie: JSESSIONID=C5AC6D2AB8C620B44D388623EA890434; Path=/; HttpOnly
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< Last-Modified: Mon, 02 Nov 2020 12:25:38 GMT
< Cache-Control: max-age=0, must-revalidate, no-transform, private
< ETag: "0526480051d045cefc01be56bb5a1faac"
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Content-Type: image/jpeg
< Content-Length: 581960
< Date: Mon, 02 Nov 2020 11:26:04 GMT
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0

That being said, seems like this break an existing test: BookControllerTest > HttpCache > given request with If-Modified-Since headers when getting page then returns 304 not modified()
I don't know why :/

[gotson]

You can send a PR, I'll have a look!

[gotson]

🎉 This issue has been resolved in version 0.64.4 🎉

The release is available on:

• v0.64.4
• GitHub release

Your semantic-release bot 📦🚀