HTTP 302 on epub resources when accessing from internet

[fengyufeiyang]

HTTP 302 on epub resources when accessing from internet

[fengyufeiyang]

你正在比较无法比较的东西。1.8 中添加了对 Epub 的支持。

Indeed, as you mentioned, versions 1.7.2 and earlier do not have this issue. I have tested them already.

[gotson]

Without details on how you access Komga from the internet, i cannot really help. You are getting a HTTP 302 response, you probably need to investigate that.

[fengyufeiyang]

如果没有有关如何从互联网访问 Komga 的详细信息，我真的无能为力。您收到 HTTP 302 响应，您可能需要对此进行调查。

I re-downloaded and deployed the Docker image for version 1.5.1, and indeed everything is functioning normally. I have deployed Komga via Docker on a server that uses reverse proxy, enabling access from the internet through the HTTPS protocol, forwarding to Komga's default HTTP protocol on port 25600. While using version 1.5.1, all file formats (CBZ, ZIP, and EPUB) worked perfectly. However, after upgrading to version 1.8.3, CBZ and ZIP files still have normal access, but EPUB files can only be opened when accessed from within the local network. When accessed from the internet side, the result is as described earlier. I have tried deleting all configuration and cache files, and redeploying version 1.8.3, but the outcome remains unchanged.

[fengyufeiyang]

I am considering downloading and testing versions sequentially starting from 1.5.1 to identify at which version the issue first occurs. I apologize for my lack of knowledge in networking, programming, development, debugging, etc. I can only do my best to cooperate with you. I hope Komga can become the Emby, Jellyfin, or Plex of the book world.

[gotson]

You are comparing things that cannot be compared. Epub support was added in 1.8.

[gotson]

Can you provide more details on which reverse proxy you use and what configuration you have for Komga?

[briandking]

This issue sounds like the one I am having. Even though it's described as a 302 issue, I think that's a side effect of the actual issue. I notice the original report uses https externally but http internally. The issue I am seeing is that it has nothing to do with internal vs external, but with http vs https.
When accessing over https the browser console has a warning like this

Mixed Content: The page at 'https://XXXXX/book/0EPX0VWBCBYBH/read-epub' was loaded over HTTPS, but requested an insecure resource 'http://XXXXX/api/v1/books/0EPX0VWBCBYBH/resource/OEBPS/cover.xhtml'. This request has been blocked; the content must be served over HTTPS.

While the browser view window just shows the loading spinner forever.

It appears to be caused by the manifest url (https://XXXXXX/api/v1/books/0EPX0VWBCBYBH/manifest) containing fully qualified http://.... links rather than relative ones. E.g. links like http://XXXXX/api/v1/books/0EPX0VWBCBYBH/resource/OEBPS/cover.xhtml
If I load the http or https link to cover.xhtml directly in another tab, they both work fine, it's just the switch to http from https that is the issue.

[gotson]

It appears to be caused by the manifest url (https://XXXXXX/api/v1/books/0EPX0VWBCBYBH/manifest) containing fully qualified http://.... links rather than relative ones. E.g. links like http://XXXXX/api/v1/books/0EPX0VWBCBYBH/resource/OEBPS/cover.xhtml

if the manifest has http instead of https, then your reverse proxy configuration is incorrect. Webpub manifest mandates full url, not relative urls.

[briandking]

I'm not really familiar with the format requirements, but if this is the right specification (I'm not certain it is): https://www.w3.org/TR/pub-manifest/#example-37-identifying-an-html-cover-page

Then it looks like it supports relative links from the example.
It's quite possible my reverse proxy is misconfigured but it works fine for the rest of komga (and many other applications) by only rewriting headers. It's not configured to also search and rewrite document content on the fly since that's more resource intensive and not usually required. Perhaps in the case of epubs and komga that is required?

[gotson]

https://readium.org/webpub-manifest/#23-links

[gotson]

It's quite possible my reverse proxy is misconfigured but it works fine for the rest of komga (and many other applications) by only rewriting headers. It's not configured to also search and rewrite document content on the fly since that's more resource intensive and not usually required. Perhaps in the case of epubs and komga that is required?

the fact that it works on some endpoints does not mean anything. You are probably missing https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

[briandking]

I'll dig deeper tomorrow but I'm not missing that header in the nginx config.

location / {
      proxy_pass http://127.0.0.1:8090;
      proxy_set_header Host $host;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

[briandking]

https://readium.org/webpub-manifest/#23-links

This shows the link to the manifest is fully qualified but further down it shows the links inside the manifest are relative. It's the links inside the manifest that have the wrong protocol on them. The link to the manifest works, the manifest is retrieved and the resources inside are blocked by the browser because they are http.

[gotson]

all the links in the manifest are built the same way, using the current context. If the links are correct on local, and incorrect behind a reverse proxy, it's a reverse proxy configuration issue.

[briandking]

Confirming that you were 100% correct. Komga was behaving correctly and it was a reverse proxy issue.
The proxy was not setting $scheme as expected when it was not the front end proxy that was providing SSL.

For future people seeing this, you can test Komga's behaviour using curl (with a session auth cookie taken from a logged in browser) and see that it is generating the URLs with any protocol or server name specified in the headers (correct behaviour)

$ curl -s 'http://127.0.0.1:8090/api/v1/books/0AWDD2375F685/manifest'  -H 'cookie: SESSION=NTM5YjBlYTUtYjE1NC00YWQ5LWE1NTgtM2E5MjJiZGIxNTVl'   -H 'Host: a.b.c' -H 'X-Forwarded-Proto: SomeProto' | jq .toc
[
  {
    "title": "Cover",
    "href": "SomeProto://a.b.c/api/v1/books/0AWDD2375F685/resource/OEBPS/cover.xhtml"
  }
]

The issue turned out to be using cloudflare to provide the SSL in front of an nginx reverse proxy without SSL to forward to komga without SSL. Cloudflare was providing the correct X-Forwarded-Proto header but nginx was not preserving that X-Forwarded-Proto in $scheme. Some possible solutions:

1. hard code the nginx header to https if you are certain you will only ever be using https and never accessing locally without ssl

proxy_set_header X-Forwarded-Proto https;

2. add ssl to the nginx proxy so that $scheme would be set correctly
3. set the nginx X-Forwarded-Proto header to $http_x_forwarded_proto if you are always going to be coming through both layers of proxies and the first proxy will be setting X-Forwarded-Proto and you just want nginx to preserve it.

proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

4. use a map that preserves the X-Forwarded-Proto in nginx that was provided by the first proxy, but fallback to $scheme if that header is not provided (e.g. when accessing directly locally)

map $http_x_forwarded_proto $forwarded_proto {
    default $http_x_forwarded_proto;
    '' $scheme;
}
server {
...
    location / {
...
      proxy_set_header X-Forwarded-Proto $forwarded_proto;
}}

[gotson]

glad you sorted this out. Note that it's a good practice to use SSL from CF to your RP, and you can also consider using Caddy instead, which does everything correctly in just one line of config ;-)

[briandking]

Note that it's a good practice to use SSL from CF to your RP, and you can also consider using Caddy instead, which does everything correctly in just one line of config ;-)

Traffic is encrypted from CF to RP, but using cloudflared tunnel so no holes are required to be punched in the firewall. So the unencrypted traffic into nginx is all localhost to localhost.
Caddy is nice but nginx gives me the flexibility to shoot myself in the foot like I just did with this one 😉

[gotson]

Closing as no feedback from OP