search

readium / r2-streamer-js

NodeJS Readium2 "streamer"
BSD 3-Clause "New" or "Revised" License
21 stars 10 forks source link

R1 - R2 mashup stuck in subsequent hit #4

Closed barbender closed 7 years ago

barbender commented 7 years ago

Noticed strange behavior when using R1 reader with Node JS R2 streamer. It looks like the subsequent hit of the same URL results in WebPub manifest being served from the cache is not correct.

Here is the environment:

First hit results in the book being open OK. Subsequent hit or refresh results in load indicator displayed indefinitely.

Here are the logs from R2 streamer:

And so on - one hit is a success, subsequent from "cache" failure.

danielweck commented 7 years ago

The cloud reader seem to request manifest.json/META-INF/container.xml, which implies that the URL pointing to manifest.json was detected with the wrong Content-Type (HTTP header). Perhaps the HEAD request that ReadiumJS uses to find out the Content-Type does not work with cached responses?

danielweck commented 7 years ago

I'm going to explicitly add the HEAD method in the HTTP CORS config, to see if it helps: https://github.com/edrlab/r2-streamer-js/blob/develop/src/server.ts#L90

    public setResponseCORS(res: express.Response) {
        res.setHeader("Access-Control-Allow-Origin",
            "*");

        res.setHeader("Access-Control-Allow-Methods",
            "GET, OPTIONS"); // POST, DELETE, PUT, PATCH

        res.setHeader("Access-Control-Allow-Headers",
            "Content-Type, Content-Length, Accept-Ranges, Link, Transfer-Encoding");
    }
danielweck commented 7 years ago

Actually I am getting timeout errors on the HEAD request:

2017-06-11T22:32:29.689481+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=HEAD path="/pub/L2FwcC9taXNjL2VwdWJzL2NoaWxkcmVucy1saXRlcmF0dXJlLmVwdWI=/manifest.json" host=readium2.herokuapp.com request_id=6b631ae5-2d79-45df-aec9-89f578d5a07e fwd="86.130.138.178" dyno=web.1 connect=0ms service=30001ms status=503 bytes=0 protocol=https
danielweck commented 7 years ago

This definitely seems related to cached HEAD requests, as I am not able to reproduce the bug on Chrome (OSX) with disabled HTTP cache (when the web inspector window is open).

danielweck commented 7 years ago

Fixed: https://github.com/edrlab/r2-streamer-js/commit/65dd3f95f46a0e67cef481df5d03e907d408a6fa

barbender commented 7 years ago

Hi Daniel, Indeed the problem is not happening when Chrome Dev Tools are open, but otherwise, it happens deterministically, i.e., out of 2 subsequent refreshes one is going through, the other gets stuck, thanks, Michael