Bug 21104 - oai.pl returns wrong baseURL
Summary: oai.pl returns wrong baseURL
Status: REOPENED
Alias: None
Product: Koha
Classification: Unclassified
Component: Web services (show other bugs)
Version: Main
Hardware: All All
: P4 normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 21102
  Show dependency treegraph
 
Reported: 2018-07-23 19:39 UTC by Pablo AB
Modified: 2024-04-17 06:39 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo AB 2018-07-23 19:39:57 UTC
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"
Comment 1 Tomás Cohen Arazi 2021-11-12 14:46:41 UTC
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/
Comment 2 Katrin Fischer 2024-04-14 20:53:45 UTC
It looks like this has been reported again on the mailing list:
https://lists.katipo.co.nz/pipermail/koha/2024-April/060599.html
Comment 3 David Cook 2024-04-15 00:51:09 UTC
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.
Comment 4 David Cook 2024-04-15 00:56:03 UTC
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.
Comment 5 Tomás Cohen Arazi 2024-04-17 02:37:13 UTC
(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.
Comment 6 David Cook 2024-04-17 06:39:22 UTC
(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.