Related/continuation of: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785#c11 When using Plack Koha anwer a "cooler" (bug 18410) but invalid baseURL, /opac/oai.pl instead of given URI. As Tomas said on bug #17785: > Our fix for the XSLT masked the underlying bug (our code doesn't know > about the proxypass we do, and then Plack answers what he knows, > /opac/oai.pl). Originally deteced with official validator: https://www.openarchives.org/Register/ValidateSite Tested with: curl -s "baseURL?verb=Identify" | xpath -q -e "/OAI-PMH/Identify/baseURL"
I tested a 21.05 demo site here [1] and this is not one of the problems that persist. Not sure what fixed it between now and 2018. [1] https://validator.oaipmh.com/
It looks like this has been reported again on the mailing list: https://lists.katipo.co.nz/pipermail/koha/2024-April/060599.html
I can confirm that this is an issue in koha-testing-docker and in production. If you enable OAI-PMH and look at the XML response, you'll get a URL with a path like /opac/oai.pl instead of /cgi-bin/koha/oai.pl I swore this used to work correctly, but maybe it was in the pre-Plack days. In 2017, I wrote a patch to use OpacBaseURL instead of the proxied hostname, and I still use that locally. But it looks like we need to fix the path as well. Overall, I think the typical way to get automatically correct self-referential URLs is for the proxy to use the same path that the backend app is mounted on (like we do with /api). But here instead of using CGI::self_url() for the requestURL in Koha/OAI/Server/Repository.pm, I think we'll need to rewrite the path for that URI to /cgi-bin/koha/oai.pl.
One day, I think we'll replace "/cgi-bin/koha" with something like "/admin" (for staff interface) and "/" or something (for the OPAC). But today is not that day... So I think we fix the requestURL and leave it at that.
(In reply to David Cook from comment #4) > One day, I think we'll replace "/cgi-bin/koha" with something like "/admin" > (for staff interface) and "/" or something (for the OPAC). > > But today is not that day... > > So I think we fix the requestURL and leave it at that. We need to track this to middleware changes. This shouldn’t be happening, and we obviously don’t have regression tests for this.
(In reply to Tomás Cohen Arazi from comment #5) > We need to track this to middleware changes. This shouldn’t be happening, > and we obviously don’t have regression tests for this. I'm not sure I follow. What do you mean "track this to middleware changes"? It makes sense that this is happening since we're using Starman like we are. Looking back at this, it's been happening for many years. But it would be good to have selenium tests for this.