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.
