Base URI redirection #32

regisrob · 2013-07-24T15:16:01Z

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 · 2013-07-24T15:39:33Z

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

jpstroop · 2013-07-24T18:19:31Z

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 · 2013-07-24T19:16:43Z

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 : loris-imageserver/loris-openseadragon-demo#1
We'll see that later.
Thx again
Regis

regisrob · 2013-08-26T14:05:16Z

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 · 2013-08-26T17:32:52Z

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 · 2013-08-26T21:15:02Z

Bug fixed ! Redirection is ok now. Thanks.
I thought for a short while it could have solved this issue loris-imageserver/loris-openseadragon-demo#1, but I was wrong! I have to proceed.
-Regis

jpstroop · 2013-08-27T13:29:58Z

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 · 2013-08-29T16:27:09Z

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 · 2013-08-30T14:44:36Z

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 · 2013-08-30T18:54:23Z

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 · 2013-08-30T20:47:13Z

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 · 2013-09-02T13:01:08Z

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 · 2013-09-02T15:29:49Z

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 · 2013-09-02T20:27:19Z

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 · 2013-09-09T18:48:50Z

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 · 2013-09-11T15:20:17Z

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 :

http://stackoverflow.com/questions/4390436/need-to-allow-encoded-slashes-on-apache
http://httpd.apache.org/docs/2.0/mod/core.html#acceptpathinfo
http://serverfault.com/questions/211309/apache-allowencodedslashes-issue#comment188310_211777
When I call "http://interne.biblissima-condorcet.fr/loris/test/T0000009.jp2/info.json?callback=?" with getJSON, info.json request is ok but image tiles fail to load (long list of 404 for each tile) :
"NetworkError: 404 Not Found - http://interne.biblissima-condorcet.fr/loris/test%2FT0000009.jp2/full/pct:2.3283064365386963e-8/0/native.jpg"
Tile 0/0_0 failed to load: http://interne.biblissima-condorcet.fr/loris/test%2FT0000009.jp2/full/pct:2.3283064365386963e-8/0/native.jpg
etc…
And when I call "http://interne.biblissima-condorcet.fr/loris/test%2FT0000009.jp2/info.json?callback=?" (with %2F), info.json returns 404.

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 · 2013-09-11T15:29:15Z

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 · 2013-09-12T15:36:27Z

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 :

32 bit architecture (dev server) vs 64 bit (prod server)
Werkzeug-0.9.4-py2.7.egg (dev) vs Werkzeug-0.9.1-py2.7.egg-info (prod)
PIL : Freetype2 support available on prod but not on dev
... and reverse proxy set up in front of prod, but not on dev !
Apart from that, same Apache, same mod_wsgi, same Python, same PIL, same Loris...
I think I can legitimately send a request to the sysadmins.

I'll keep you posted.

Regis

jpstroop · 2013-09-12T15:44:18Z

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

jpstroop · 2013-09-13T14:27:26Z

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 · 2013-09-13T16:06:11Z

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

jpstroop closed this as completed in 8659f67 Jul 24, 2013

jpstroop reopened this Sep 2, 2013

jpstroop closed this as completed Sep 13, 2013

scherztc mentioned this issue Dec 7, 2015

Install Loris Image Server in our Hydra environment. uclibs/scholar_uc_legacy#509

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Base URI redirection #32

Base URI redirection #32

regisrob commented Jul 24, 2013

jpstroop commented Jul 24, 2013

jpstroop commented Jul 24, 2013

regisrob commented Jul 24, 2013

regisrob commented Aug 26, 2013

jpstroop commented Aug 26, 2013

regisrob commented Aug 26, 2013

jpstroop commented Aug 27, 2013

jpstroop commented Aug 29, 2013

regisrob commented Aug 30, 2013

jpstroop commented Aug 30, 2013

jpstroop commented Aug 30, 2013

regisrob commented Sep 2, 2013

jpstroop commented Sep 2, 2013

regisrob commented Sep 2, 2013

jpstroop commented Sep 9, 2013

regisrob commented Sep 11, 2013

jpstroop commented Sep 11, 2013

regisrob commented Sep 12, 2013

jpstroop commented Sep 12, 2013

jpstroop commented Sep 13, 2013

regisrob commented Sep 13, 2013

Base URI redirection #32

Base URI redirection #32

Comments

regisrob commented Jul 24, 2013

jpstroop commented Jul 24, 2013

jpstroop commented Jul 24, 2013

regisrob commented Jul 24, 2013

regisrob commented Aug 26, 2013

jpstroop commented Aug 26, 2013

regisrob commented Aug 26, 2013

jpstroop commented Aug 27, 2013

jpstroop commented Aug 29, 2013

regisrob commented Aug 30, 2013

jpstroop commented Aug 30, 2013

jpstroop commented Aug 30, 2013

regisrob commented Sep 2, 2013

jpstroop commented Sep 2, 2013

regisrob commented Sep 2, 2013

jpstroop commented Sep 9, 2013

regisrob commented Sep 11, 2013

jpstroop commented Sep 11, 2013

regisrob commented Sep 12, 2013

jpstroop commented Sep 12, 2013

jpstroop commented Sep 13, 2013

regisrob commented Sep 13, 2013