fix for double-url-encoded ":" in "hdl:". #9797

[landreev]

What this PR does / why we need it:

Copy-and-pasting the explanation of what's going on that I left in the issue earlier:

Here's what appears to be taking place:

• It never happens, or doesn't appear to be easy to reproduce when going through apache via https; as in https://dataverse-internal.iq.harvard.edu/api/datasets/export?exporter=schema.org&persistentId=doi%3A10.70122/FK2/WPCTZB.
• It only happens if you try to go through apache, but via plain http:, as in http://dataverse-internal.iq.harvard.edu/api/datasets/export?exporter=schema.org&persistentId=doi%3A10.70122/FK2/WPCTZB. It is that extra http: -> https: redirect that somehow results in the doi%3A getting encoded as doi%253A. @kcondon stumbled on this while explicitly experimenting with changing the port and/or protocol in the url (see the description). This makes it a little less of a problem, because real life users are unlikely to encounter this under normal operations on an instance configured to sit behind apache w/ https.
  However,
• It's not just the secondary links, like the metadata urls on the dataset page. The url-encoded doi%3A and hdl%3A in persistent ids are failing in all urls then. I.e., http://dataverse-internal.iq.harvard.edu/dataset.xhtml?persistentId=doi%3A10.70122/FK2/WPCTZB isn't working either.

Rather than trying to figure out why this has started happening under p6, I feel like we should just add a defensive '%3A' -> ':' substitution to the persistent id check. Hence this one line pr. It looks like this has already been happening once in a while - I see an occasional doi%253A resulting in a 404 in the prod. access logs (probably on account of bookmarked or harvested urls? - idk). So, would be a reasonable fix to add regardless.

The fact that this is happening because of the extra http: -> https: redirect is by itself weird; because that's done entirely under apache... so not immediately clear how the p6 upgrade would even affect that... But, once again, I'm not sure we want to spend much time figuring out the why part.

Which issue(s) this PR closes:

Closes #9797 maybe?

Special notes for your reviewer:

Suggestions on how to test this:

The obvious test is to make sure that urls like http://dataverse-internal.iq.harvard.edu/dataset.xhtml?persistentId=doi%3A10.70122/FK2/WPCTZB and http://dataverse-internal.iq.harvard.edu/api/datasets/export?exporter=schema.org&persistentId=doi%3A10.70122/FK2/WPCTZB are working. And maybe a more general check that there are no other links that may not be working depending on what port/protocol is used to get to the site. (?)

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

Additional documentation:

[landreev]

BTW, there's a chance that this is not unique to p6, but rather something uniquely misconfigured on dataverse-internal: It is running 5.14 under payara5/jdk11 at the moment, and the ids with %3A are bombing the same exact way when going through port 80: http://dataverse-internal.iq.harvard.edu/api/datasets/export?exporter=schema.org&persistentId=doi%3A10.70122/FK2/WPCTZB
... just something nobody noticed before. (does not happen in either prod. or on demo).

Just one extra reason to add this defensive line to the code and forget about it.

[pdurbin]

@landreev do you think any of these test failures are related to your pull request? https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/job/PR-9835/1/testReport/

I sort of doubt it. I was otherwise about to approve this PR...

[landreev]

Sorry for the delay. I can't imagine the one line in this PR being responsible for these failures either.
The actual test failures appear to be along the lines of

... Restricting files is not permitted on a public installation.

- so, something to do with the "public install" flag maybe?

[landreev]

I synced the branch with develop, should fix the failing tests.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:9797-double-encoded-colon

ghcr.io/gdcc/configbaker:9797-double-encoded-colon

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.