Problem with https for iiifviewer

[ghost]

FROM:c.fleet@nls.uk Chris Fleet We have moved to https for the NLS iiifviewer, ie.

https://maps.nls.uk/view/00000207

However, we have not managed to get IIPImage to deliver the .JPG images using https - we get the message:

Mixed Content: The page at 'https://maps.nls.uk/view/00000207' was loaded over HTTPS, but requested an insecure image 'http://maps.nls.uk/imgsrv/iipsrv.fcgi?iiif=/207.jp2/0,0,4096,4096/pct:6.25/0/native.jpg'. This content should also be served over HTTPS.

This seems to be the same problem at:

http://labs.klokantech.com/nls/viewer/

Please could you advise on whether we can fix this, so that we can get our iiifviewer working under https ?

Many thanks,

Chris

Link to the Clientportal: https://clientportal.klokantech.com/iiifviewer/issues/22

[petrsloup]

I think the problem is inside https://maps.nls.uk/imgsrv/iipsrv.fcgi?iiif=/207.jp2/info.json: @id: "http://maps.nls.uk/imgsrv/iipsrv.fcgi?iiif=/207.jp2", the viewer uses this to generate the URLs of tiles.

[ghost]

FROM:c.fleet@nls.uk Chris Fleet Many thanks for your quick reply, Petr - this is helpful.

However, the real question is how this info.json gets created and how we can fix it so it creates the @id: line with "https://maps....?

Presumably there is something in the iifviewer Javascript - maybe within http://labs.klokantech.com/nls/viewer/js/ol-iiifviewer.js ?? creating the info in the info.json ??

[petrsloup]

The problem is in the IIPImage server running at your end. I don't know it's set up, but it creates the .json files with incorrect URLs (http instead of https).

Maybe it's possible to configure this? How did you enable the HTTPS? Is there some proxy? It's possible the IIPImage server does not know about the HTTPS and therefore incorrectly puts http inside.

[ghost]

FROM:c.fleet@nls.uk Chris Fleet Hello Petr,

Your answer makes sense, and I forwarded it to Tony. He has tried various things, but feels that there is something in the iiifviewer Javascript that is causing this.

We first of all looked at the IIPImage server configuration at: http://iipimage.sourceforge.net/documentation/server/ where there is a BASE_URL parameter.

Tony tried many things - https://maps.nls.uk https://maps.nls.uk/ https://maps.nls.uk/imgsrv/ and https://maps.nls.uk/imgsrv/iipsrv.fcgi but none of these made any difference.

I also suggested he looked at the Apache URL Rewriting http://iipimage.sourceforge.net/2014/12/iiif/ http://httpd.apache.org/docs/current/mod/mod_rewrite.html

This did not help either.

Tony said that he implemented https: on the server side with these rewrite rules

The first rule says - if the URL starts with geo or videos, then force request to use http protocol if its currently https.

The second rule says, redirect ALL http requests to https, unless the URL starts with geo or videos.

He said "I know what I’m doing here, these took a while to craft properly…!"

 <rule name="conditional HTTPS to HTTP redirect" stopProcessing="true">
  <match url="^(geo|videos)(/|$)(.*)" />
  <conditions>
   <add input="{HTTPS}" pattern="on" ignoreCase="true" />
  </conditions>
  <action type="Redirect" redirectType="Found" url="http://{HTTP_HOST}/{R:0}" />
</rule> 

 <rule name="HTTP to HTTPS redirect" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{R:0}" pattern="^(geo|videos)(/|$)(.*)" negate="true" />
    <add input="{HTTPS}" pattern="off" ignoreCase="true" />
  </conditions>
  <action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />
</rule>  

These are working okay for standard URLs reverting from http:// to https://

So Tony says he has tried everything on the server side here.

You will know whether there is anything in the iiifviewer javascript that is creating the .json with the @id with http:

Very grateful for any further ideas.

Thanks,

Chris

[petrsloup]

Chris, I'm not questioning the correctness of the redirects :-)

The info.json is not created by the javascript, it is created by the server (iipsrv). The issue is that the Apache is handling the HTTPS and the iipserver is behind the Apache and does not know about the HTTPS, so it incorrectly puts "http://" to the @id field. (I even found the line where this happends in the code: https://github.com/ruven/iipsrv/blob/master/src/IIIF.cc#L155 and https://github.com/ruven/iipsrv/blob/master/src/Main.cc#L611).

Looks like you just need to make sure the "HTTPS" parameter is set when the Apache passes the request to the iipsrv.

[ghost]

FROM:c.fleet@nls.uk Chris Fleet Petr, thanks so much for your message which was very helpful in confirming that the problem needs to be fixed at the server end, and there is nothing in the Javascript.

Tony has tried many, many things, but unfortunately still not fixed it, and I wondered if I could ask a further question, even though it is related to IIPImage and not to the client viewer Javascript. I realise IIPImage is other software and if you don't support it or know, its no problem, please close the ticket and we can maybe move maps to use IIIFServer.

We do not use Apache but IIS, and Tony has compared the FastCGI settings in our two IIPImage installs and said they are the same. We also have the same Environment Variables - the ones listed at http://iipimage.sourceforge.net/documentation/server/

The odd thing is that the other IIPImage at https://digital.nls.uk/aberdeen-breviary/archive/102826957?mode=zoom works fine in https: using IIPImage 0.9.9 .

The JSON does not have a @id or @context, ie.

https://digital.nls.uk/imageserver/iipsrv.fcgi?iiif=/1028/7824/102878248.5.jp2/info.json

However, the maps IIPImage is version 1.0 and generates an @id with http: - maybe they handle the https parameter differently? If you can think of something else we should try, we'd be very grateful, but no worries at all if this is out-of-scope - its something in IIPImage or FastCGI or on the server...

Chris

[petrsloup]

Chris, sorry for getting back to this email with such a delay.

Unfortunately, I don't know if there were any changes to the handling of https between different IIPImage versions.

The missing @id and @context parameters indicate, that these IIPImage versions use a different version of IIIF Image API specification -- see http://iiif.io/api/image/1.0/#5-image-informationrequest (older without @id) vs. http://iiif.io/api/image/1.1/#5-image-information-request (newer with @id).

Other than this small piece of information, I'm afraid I can't help you with analysis of this issue at the moment.