Regression in 2.8.0 Release - All Downloads Broken

[Chirishman]

Since updating to 2.8.0 all attempts to download ebooks fail and appear to try to download a file named fetch.php instead.

When performed in a browser this results in successfully downloading a file named fetch.php which appears, (upon manual renaming to *.epub) to be the desired book.

When attempted in an in OPDS reader apps the download fails entirely, throwing an error for unsupported MIME Type: application/x-php

[mikespub]

Hi @Chirishman

Sorry - I'm going to need a bit more details as I can't reproduce this with the latest 2.8.0 code or docker image

Let me describe what happens from my perspective, and then check how this is different for your configuration.

1. Test setup
   This docker-compose file

• takes my latest cops image (local build from docker-cops)
• copies its default config to /tmp
• maps my local test library to /books
• uses port 8080 on localhost

  cops:
    image: cops:latest
    container_name: cops
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /tmp:/config
      - /home/mikespub/seblucas-cops/test/BaseWithSomeBooks:/books
    ports:
      - 8080:80

2. in my browser, when I go to the book details on Alice's Adventures in Wonderland
   http://localhost:8080/index.php?page=13&id=17#cover
   the link to the EPUB file will show as
   http://localhost:8080/fetch.php?id=17&type=epub&data=20

3. when I click on that link, my browser will download the file as "Alice's Adventures in Wonderland - Lewis Carroll.epub"

Response Headers (raw) from Dev Tools in Chrome:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 02 Sep 2024 08:21:19 GMT
Content-Type: application/epub+zip
Content-Length: 1598906
Last-Modified: Thu, 02 May 2024 16:46:36 GMT
Connection: keep-alive
Cache-Control: max-age=1209600
Expires: Mon, 16 Sep 2024 08:21:19 GMT
Content-Disposition: attachment; filename="Alice's Adventures in Wonderland - Lewis Carroll.epub"
ETag: "6633c36c-1865ba"
Accept-Ranges: bytes

This basically shows the file was sent directly by nginx (extra ETag header and no X-Powered-By: PHP/8.3.10) with the correct content disposition set by COPS

Can you tell me what you see in the dev tools of your browser?
Hint: right-click on the page and choose Inspect before downloading, then go to Network and select the fetch.php?... line afterwards

My guess is that in your case, when you download the file you either have an X-Powered-By: PHP header showing it's sent by PHP instead, and/or the content disposition is somehow wrong or missing.

Once we know what happens, we can start figuring out "why" it happens to you and not to me ;-)

4. Code analysis
   In the code, with the latest changes the request should go from FetchHandler::handle() to FileRenderer::sendFile() and end with

header('Content-Type: ' . $mimetype);
header('Content-Disposition: attachment; filepath="' . basename($filename) . '"');
// ...
header(Config::get('x_accel_redirect') . ': ' . $filepath);

But even when I remove $config['cops_x_accel_redirect'] in config_local.php and go via readfile() instead of x_accel_redirect, I still get the right content disposition...

[mikespub]

Oops - my mistake. Those were the result with the old docker-cops image.

I just re-did the test with the latest image, and you're right - I'm getting the following headers instead:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 02 Sep 2024 09:23:27 GMT
Content-Type: application/epub+zip
Content-Length: 1598906
Last-Modified: Thu, 02 May 2024 16:46:36 GMT
Connection: keep-alive
Cache-Control: max-age=1209600
Expires: Mon, 16 Sep 2024 09:23:27 GMT
Content-Disposition: attachment; filepath="Alice's Adventures in Wonderland - Lewis Carroll.epub"
ETag: "6633c36c-1865ba"
Accept-Ranges: bytes

Spot the difference - filepath instead of filename in Content-Disposition :-(

[mikespub]

This should now be fixed in release 2.8.1 and the linuxserver/docker-cops image should be updated in the next 24 hours.

My apologies - that confirms I should never release a 2.x.0 version until further testing for a 2.x.1 release, but I guess I was eager to get the kepubify changes out there...