Hi Scott, (I also answered this on Slack [1] as you asked there as well. But, I figured I'd copy the answer here in case others have similar questions)
It's my understanding that the HTTP requirement comes from the OAI-PMH protocol itself. See: https://www.openarchives.org/OAI/openarchivesprotocol.html#HTTPembedding As far as I'm aware, there's nothing in DSpace that requires you to run OAI under HTTP. So, I believe you can technically run it under HTTPS. But, since the OAI-PMH protocol hasn't been updated to list HTTPS as an option, I think some OAI harvesters still assume HTTP-only requests. That all said, if the harvester you are using allows for HTTPS + OAI, then I see no reason why you cannot switch to using HTTPS. As for the exact error you are seeing under HTTP, I'm not sure I have any good guesses. For our DSpaceDirect hosted service (dspacedirect.org), I know we do run sites under HTTPS with an exception for HTTP *just* for OAI. In our situation, we do not have load balancing in place, but simply have an Apache rewrite rule (from HTTP to HTTPS) that redirects everything except OAI. It looks similar to this: <VirtualHost *:80> ServerName [dspace-url-goes-here] # Redirect all HTTP requests to HTTPS (EXCEPT /oai/ path) RewriteEngine On RewriteCond %{REQUEST_URI} !^/oai/ RewriteRule ^(.*) https://%{SERVER_NAME}$1 [R=permanent,L] ...other configs... </VirtualHost> Hopefully that helps, - Tim [1] https://wiki.duraspace.org/display/DSPACE/Slack On Mon, Sep 11, 2017 at 9:09 AM Scott Renton <[email protected]> wrote: > Hi folks > > Just putting a speculative call out in case anyone has tried this. We make > our sites https, but, as is the general advice, certain webapps stay as > http (/oai, /dspace-oai, /solr, /sword, /lni, /rest). We're attempting to > move our sites into a load balancer, so the config to do this is being done > there rather than in httpd.conf (the admin has effectively set up two > sites: the fully https one, and another which just caters for these under > http. They are linked somehow, but I don't know quite how.). > > What I'm finding is that while, say, this works (as the site still covers > everything): > > https://openair-test.rgu.ac.uk/dspace-oai/request?verb=ListRecords&metadataPrefix=oai_dc > > this gives me an error (Http/1.1 Service Unavailable*)*: > > http://openair-test.rgu.ac.uk/dspace-oai/request?verb=ListRecords&metadataPrefix=oai_dc > > and this seems to do the work- meaning the oai webapp is being correctly > seen as oai, but can't render the stylesheet (see it in Firefox- gets a > 503, although this does not seem to report to localhost_access_xxxxx.txt, > so I'm just going by the browser there): > http://openair-test.rgu.ac.uk/dspace-oai/request?verb=Identify > > As our admin can see the processes correctly going through http, as far as > he is concerned, he's done what's needed. I wondered if anyone has tried > something similar and knows of any such things to look out for. > > Failing that, we are very much under the impression that oai should be > http in case any harvesters fail to cater for https in their code. Is this > likely to continue? > > Cheers again > Scott > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
