nginx url rewrite for IIIIF about iipsrv HOT 10 CLOSED

Just saw this -- I've used the following nginx rule:

rewrite ^/iiif/image(?<iiif>.*)$ /iip/iipsrv.fcgi?IIIF=$iiif last;

The key is to capture the first slash after "image" so that the server doesn't try to match the location, but instead passes it on as part of the capture.

from iipsrv.

rewrite ^/iiif/image(?.*)$ /iip/iipsrv.fcgi?IIIF=$iiif last;

Do you need to use merge_slashes off; with this?

from iipsrv.

Not so far. It will parse urls like:

http://example.com/iiif/image/MS123/abcdefg.jpx/full/full/0/default.jpg

and turn them to:

http://example.com/iip/iipsrv.fcgi?IIIF=/MS123/abcdefg.jpx/full/full/0/default.jpg

Granted, I only figured this out a couple days ago, so it's not been through any rigorous testing. :)

from iipsrv.

When merge_slashes is on, it will resolve:

/iiif/%2Fdata%2Fpicture.jp2

from (rewrite decodes!)

   /iiif//data/picture.jp2

to:

  /iiif/data/picture.jp2

so the part after /iiif/ is only "data/picture.jp2" which is a relative path.
One can also add %2F to the capture in the rewrite:

    rewrite ^/iiif/(.*) /iip?IIIF=%2F$1 last;

from iipsrv.

IIIF expects the identifier to be url encoded between the prefix, and the rest of the parameters:

{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

In this case, the full path, starting with a slash is between /iiif/ and /info.json

from iipsrv.

Ah, I think I see what you're saying -- that the "/" of the identifier, and the "/" between the prefix and the identifier should be treated separately.

I just did some testing. I have merge slashes on in nginx (default), and all of the following work correctly with the above configuration:

http://example.com/iiif/image/%2fMS123%2fimage.jpx%2finfo.json
http://example.com/iiif/image//MS123/image.jpx/info.json
http://example.com/iiif/image/MS123%2fimage.jpx%2finfo.json

To me, this seems suitably compliant for an Image API server.

from iipsrv.

I know, it gets the result it wants. But the iipsrv cannot return a decent "@id"

vb.

http://localhost:8080/iiif/%2Fdata%2Ftest.jp2/info.json

{
  "@context" : "http://iiif.io/api/image/2/context.json",
  "@id" : "http://localhost:8080/iiif/data/test.jp2",
  "protocol" : "http://iiif.io/api/image",
  "width" : 2463,
  "height" : 3863,
  "tiles" : [
     { "width" : 256, "height" : 256, "scaleFactors" : [ 1, 2, 4, 8, 16 ] }
  ],
  "profile" : [
     "http://iiif.io/api/image/2/level1.json",
     { "formats" : [ "jpg" ],
       "qualities" : [ "native","color","gray" ],
       "supports" : ["regionByPct","sizeByForcedWh","sizeByWh","sizeAboveFull","rotationBy90s","mirroring","gray"] }
  ]
}

The id in "@id" is not url-encoded because the iipsrv receives it incorrect from nginx (i.e. already decoded).

The consequence is that iipsrv cannot redirect the default url to info.json correctly.

A request to:

http://localhost:8080/iiif/%2Fdata%2Ftest.jp2

iipsrv.log:

Full Request is IIIF=/data/test.jp2
[1/1]: Command / Argument is IIIF : /data/test.jp2
IIIF handler reached
IIIF :: URL decoded to /data/test.jp2
FIF handler reached
FIF :: URL decoding/filtering: /data => /data
FIF :: Image cache miss
/data is neither a file nor part of an image sequence
Sending HTTP 404 Not Found
Total Request Time: 373 microseconds
image closed and deleted
Server count is 22

iipsrv expects the identifier to be double-encoded (correctly).
so in that case a forward slash in the request means that there are arguments.
When not, it is the default url, that has to be redirected to info.json (see specification).

But because the id is already decoded, iipsrv starts treating the slashes in the id as
arguments (see above).

from iipsrv.

So, to update the online docs, is something like this (even if not ideal) the best we've got so far for NginX?

   merge_slashes off;
   rewrite ^/iiif/(.*) /iip?IIIF=%2F$1 last;

from iipsrv.

As far as I can see a request to http://localhost:8080/iiif/%2Fdata%2Ftest.jp2 should fail when forwarded to IIP, since IIP doesn't have enough information to handle the request. Its URL parser is fairly literal, so it's parsing the "test.jp2" as the command (similar to info.json and default.jpg and then treating /data as the identifier (which obviously fails).

The Image API says the following:

The combination of these parameters forms the image’s Base URI and identifies the underlying image content. It is constructed according to the following URI Template (RFC6570):
{scheme}://{server}{/prefix}/{identifier}
When the base URI is dereferenced, the interaction should result in the Image Information document. It is recommended that the response be a 303 status redirection to the Image Information document’s URI. Implementations may also exhibit other behavior for the base URI beyond the scope of this specification in response to HTTP request headers and methods.

I read that as saying that a request for the identifier should forward this type of request along, via a 303, to the info.json request. But that could be handled by the nginx configuration, not IIP (technically I suppose IIP could, but that's another issue).

I just mocked up a configuration in nginx and this seems to work as expected:

location ~ ^/iiif/image(?<iiif>.*)(?<ext>jpx|jp2|tif)$ {
  return 303 /iiif/image$iiif$ext/info.json;
}

rewrite ^/iiif/image(?<iiif>.*)(?<action>default.jpg|info.json)$ /iip/iipsrv.fcgi?IIIF=$iiif$action last;

Basically, if it sees an image extension that shouldn't be at the end (.jpx, .jp2, or .tif) it will redirect via a 303 to the info.json request. (I didn't bother with the case where it's not one of these, since IIP doesn't support them anyway; I also didn't bother with anything other than default.jpg or info.json requests, but you could easily add those too.)

I don't know if that's useful? I also didn't test how it works with merge slashes 'off', but I'm of the opinion that the "/" at the end of the prefix is part of the identifier anyway. That's my personal take on it, though, and I full concede there might be cases where this causes lots of headaches.

from iipsrv.

@ahankinson : I also added an nginx redirect to the info.json to solve the problem. I was merely trying figure out if there was a "proper" way to solve all this. Url-encoding is not something the writer of nginx wants to do, so maybe there was something I was missing.

Thanks anyway ;-)

from iipsrv.