search

loris-imageserver / loris

Loris IIIF Image Server
Other
209 stars 87 forks source link

Base URI redirection #32

Closed regisrob closed 11 years ago

regisrob commented 11 years ago

Hi Jon,

When I request "http://interne.biblissima-condorcet.fr/loris/T0000009.jp2", it makes a 303 redirect to this URI "http://interne.biblissima-condorcet.fr/T0000009.jp2/info.json", which throws a 404 error (I have "redirect_base_uri=1" in loris.conf). The "/loris" prefix is removed. Is it a normal behaviour ?

Thx Regis

jpstroop commented 11 years ago

Nope. That would be a bug! I'll try to get on it today.

jpstroop commented 11 years ago

Regis, This is fixed on the development branch--thanks for catching it. I'll be away for a couple of weeks now, but please let me know if you run into problems. -Jon

regisrob commented 11 years ago

Thanks! I'll be away too for two weeks, but I'll proceed to test as soon as I come back. I still have a problem with OSD when requesting info.json through Ajax, as your Loris/OSD demo does with a former Loris version. I posted an issue here : https://github.com/jpstroop/Loris_OpenSeadragon/issues/1 We'll see that later. Thx again Regis

regisrob commented 11 years ago

Hi Jon, I just redeployed dev branch and it seems that the bug is not fixed for me. Now the request "http://interne.biblissima-condorcet.fr/loris/T0000009.jp2" redirects to "http://interne.biblissima-condorcet.fr/loris/%2FT0000009.jp2/info.json" (percent-encoded slash is appended) and ends with a 404. Thanks for your help. Regis

jpstroop commented 11 years ago

Rob, Thanks for catching this! I think it's a simple fix. Could you switch to the branch issue32 and see if that solves it for you?

This is on the development branch now. -Jon

regisrob commented 11 years ago

Bug fixed ! Redirection is ok now. Thanks. I thought for a short while it could have solved this issue https://github.com/jpstroop/Loris_OpenSeadragon/issues/1, but I was wrong! I have to proceed. -Regis

jpstroop commented 11 years ago

I does seem like the callback would still be useful. I will try to work on it this week, but it may need to wait until the following when I have some airplane time :-)

jpstroop commented 11 years ago

Regis, FYI, I've added back the callback feature, and tests are passing, but I haven't yet tried to run open seadragon; in theory it should work.... -Jon

regisrob commented 11 years ago

Thanks for the callback, it' working fine. Unfortunately it still doesn't work in practice with openseadragon. The returned error is : "$TileSource is undefined" l.3755 : options = $TileSource.prototype.configure.apply( _this, [ tileSource ]);

It seems that openseadragon is not able to determine the TileSource Implementation it should use, in this case IIIFTileSource... But at this time I don't understand how it determines that. Do you have an idea of what could be involved on the Loris side ?

-Regis

jpstroop commented 11 years ago

I've got it figured out. I'm going to fork OSD, add an IIIF 1.1 TileSource, and submit a pull request to them. I'll keep you posted!

jpstroop commented 11 years ago

Regis,

Try this: https://github.com/jpstroop/openseadragon

(You'll need to build; follow the instructions in the README).

This ''should'' support IIIF 1.1. I'm no javascript hacker, but It's working on my dev machine when I do, e.g.:


    <body>
        <div id="container">
            <div id="viewer" class="openseadragon"></div>
        </div>

        <script>

        var osd_config = {
            id: "viewer",
            prefixUrl: "images/",
            preserveViewport: true,
            visibilityRatio: 1,
            minZoomLevel: 1,
            tileSources: []
        }

        function update_tileSources(data) {
            osd_config.tileSources.push(data);
        }

        $.when (
            $.getJSON('http://localhost:5004/01%2F02%2F0001.jp2/info.json?callback=?',
                function(data) {
                    update_tileSources(data);
                }
            ),
            $.getJSON('http://localhost:5004/01%2F02%2Fgrey.jp2/info.json?callback=?',
                function(data) {
                    update_tileSources(data);
                }
            )
        ).then( function() {
            OpenSeadragon(osd_config)
        })

        </script>
    </body>

I'd like to wait to send a pull request to the OSD folks until the 1.1 spec is finalized and released.

Let me know what you think. -Jon

regisrob commented 11 years ago

Great! It works with IIIF1.1 TileSource! I just had to redeploy Loris dev branch to make it works. But there is still a weird bug for me : Ajax requests fail when using percent-encoded URI in getJSON method.

\ With percent-encoded URI in getJSON : => 404 Not Found for http://interne.biblissima-condorcet.fr/loris/01%2F02%2F0001.jp2/info.json?callback=jQuery190011149640029201213_1378067653514&_=1378067653515

\ With normal slashes in getJSON : http://interne.biblissima-condorcet.fr/loris/01/02/0001.jp2/info.json?callback=jQuery19008382387820522695_1378068073785&_=1378068073786 => info.json request is ok => but there are errors on every image request, for each image I have : "NetworkError: 404 Not Found - http://interne.biblissima-condorcet.fr/loris/01%2F02%2F0001.jp2/full/pct:3.125/0/native.jpg" "NetworkError: 404 Not Found - http://interne.biblissima-condorcet.fr/loris/01%2F02%2F0001.jp2/0,0,2048,2048/pct:12.5/0/native.jpg" ...etc.

I tried with another sub-folder in "/usr/local/share/images" and other images but the errors are the same. I don't understand why, given that I have the same environment as you, I suppose (your forked OSD and the latest Loris dev branch). Do you have an idea for that ?

You're right about the pull request for OSD, let's wait for a stable IIIF 1.1 spec. For IIIF < 1.1, I also noticed a little bug in iiiftilesource.js when the "image_host" url ends with a "/".

Thanks for your help.

-Regis

jpstroop commented 11 years ago

The one difference between our environments is that you're working behind a production web server (Apache, presumably?) and I'm still just working on the dev server that's built into Werkzeug. Do you have AllowEncodedSlashes set? I just checked my local copies of the repos and everything is in sync w/ github.

Unfortunately I'm out of town this week; I'll put it behind Apache next week and see what I see. I suppose it could also be browser specific...which would stink! It hadn't occurred to me before, but I've been working against Chrome the whole time. Might be another thing to check....

regisrob commented 11 years ago

Yes you're right, Loris is behind Apache on a production server. I have AllowEncodedSlashes set to On in my Virtualhost. It doesn't seem to be a browser specific bug (but I'm not really sure at this time). I'll keep on investigating and we'll see next week if you face the same problem or not...

-Regis

jpstroop commented 11 years ago

Regis, Any luck with this? My production server is not ready yet, but I just put this behind apache on my dev box and everything is working. My Apache config looks like this:

        AllowEncodedSlashes On
        WSGIDaemonProcess loris user=loris group=loris processes=5 threads=5 maximum-requests=10000
        WSGIScriptAlias /loris /var/www/loris/loris.wsgi
        WSGIProcessGroup loris

Nothing special as far as I can tell, and it's all working fine. However, I can exactly replicate your problem if I comment out "AllowEncodedSlashes On". Are you sure it's "On", and that no additional comments follow it? -Jon

regisrob commented 11 years ago

Hi Jon, No luck, I have the same directives as you in my virtualhost :(

AllowEncodedSlashes On
WSGIDaemonProcess loris user=loris group=loris processes=10 threads=25 maximum-requests=10000
WSGIScriptAlias /loris /var/www/loris/loris.wsgi
WSGIProcessGroup loris

I read some forum threads and tried a few things, without success :

There is nothing interesting in Apache error logs (even in debug mode), and nothing in Loris .err files. I can see this in "loris.webapp.out"... :

DEBUG: Re-encoded identifier: test%2FT0000009.jp2 DEBUG: uri_from_request: http://interne.biblissima-condorcet.fr/loris/test%2FT0000009.jp2 DEBUG: Format: jp2 DEBUG: File Path: /usr/local/share/images/test/T0000009.jp2 DEBUG: Identifier: test/T0000009.jp2

I'm not sure if you could be able to help me more than you did before (thank you for that !) and I wonder if it's not a reverse proxy problem (my Apache is running behind and I have no control over it). Do you think it could be the reason? What would you advise me to do? I was thinking about deploying Loris on a local test server with the same config...

Thx -Regis

jpstroop commented 11 years ago

Hmm...I wish I were an Apache expert.... At this point, if I were you, I would set up a separate instance of Apache somewhere else and see if you can get it running...at least that will isolate Apache as the problem. Everything in your logs looks the same as mine; it's weird!

Keep me posted!

regisrob commented 11 years ago

So I set up a separate instance of Apache and Loris on a local dev server and... it works! Requests with %2F are ok! The config is almost the same as the prod server. The only things that differ are :

I'll keep you posted.

jpstroop commented 11 years ago

Excellent! (that is, at least you've isolated it)

jpstroop commented 11 years ago

Regis, I've made some tweaks to the routing. Specifically, the region slice of the URI is now matched by a regex, rather than simply assuming that the second path slice is the region. This makes it easier to know where the identifier ends and the rest of the URI begins. You might do pull and see if this solves your problem. There's always a chance...

In the meantime, though, I'm going to close this issue. Best, Js

regisrob commented 11 years ago

Hi Jon, I tested with the latest changes you made, but unfortunately it didn't solve my problem (404 with %2F still happen). I think I will give up the idea of using sub-folders in my repository (which is a testing one). Since I don't know how to configure a smart resolver, I will merely put all the images in one folder and prepend a unique identifier to filenames (in order to distinguish images of manuscript A from those of manuscript B). Right now it's just for testing purpose and basic demos so it's not a big issue (but it will...).

-Regis