EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10062


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Links dynamically generated lose the "/cgi" part


CAUTION: This e-mail originated outside the University of Southampton.

Hello David,

Thanks for the prompt reply! Let me walk through your answer:

David R Newman dijo [Mon, Mar 24, 2025 at 09:13:10AM +0000]:
Hi Gunnar,

There are various configuration settings in EPrints, which are mostly
auto-generated from other settings or defaults.  The ones that generate
URLs that should typical contain a /cgi/ are as follows:

$c->{http_cgiurl}
$c->{https_cgiurl}
$c->{perl_url}
$c->{rel_cgipath}
$c->{http_cgiroot}
$c->{https_cgiroot}
$c->{userhome}

Getting them all from the running configuration yields:

    'http_cgiurl' => bless( do{\(my $o = 'https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fru.iiec.unam.mx%2Fcgi&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C6a5252b2cd824f6b5acd08dd6af2d11e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638784313324053195%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ANR5fDDaLTdnp7fVM1PfvyDR%2FSET3B%2BTFoUOwMIYrYM%3D&reserved=0')}, 'URI::http' ),
    'https_cgiurl' => bless( do{\(my $o = 'https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fru.iiec.unam.mx%2Fcgi&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C6a5252b2cd824f6b5acd08dd6af2d11e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638784313324074318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LCM%2BSPoIZ7ndQIRekK7UFbHxlmGIK0fQk5Lb5w%2Bj%2FyY%3D&reserved=0')}, 'URI::https' ),
    'perl_url' => 'https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fru.iiec.unam.mx%3A80%2Fcgi&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C6a5252b2cd824f6b5acd08dd6af2d11e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638784313324086798%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wQEZlre0EPKwXRgVUUcDWg2yVOEr2sAwr7JEbPARMbQ%3D&reserved=0',
    'rel_cgipath' => bless( do{\(my $o = '/cgi')}, 'URI::http' ),
    'http_cgiroot' => '/cgi',
    'userhome' => '/cgi/users/home',

So, I se https_cgiroot is not defined. I added it to 10_core.pl. OK, things
don't _visibly_ break anymore. Good!

I also confirmed (and I think this is relevant for I write a bit further on)
that the weird redirect cycle I asked about some days ago only happens if I
declare $c->{securehost} in my configuration; I temporarily enabled it and got
the cycles; disabled it and they went away.

Based on your explanation, it looks like $c->{https_cgiurl} is the
configuration setting at issue.  I would check under you archive's
configuration (EPRINTS_PATH/archive/ARCHIVE_ID/cfg/cfg.d/) and see if this
setting is set anywhere else that where you set this.  It may be that this
configuration setting  is not in your archive, so if you cannot find the
configuration setting under you archive, if you go under your EPrints path
and then look under the following sub-paths for this configuration
setting. (N.B. use of the wildcard character under flavours and
ingredients as there may be multiple sub-directories):

lib/cfg.d/
flavours/*/cfg.d/
site_lib/cfg.d/
ingredients/*/cfg.d/

Thanks a lot for this explanation. I am still running EPrints 3.3, although one
of my projects for this year is to face a migration to 3.4 (is it going to hurt,
Doctor? 😉), so I don't have flavours nor ingredients... in fact, not even
site_lib. From my EPrints root:

    $ find . -name cfg.d
    ./archives/iiec/cfg/cfg.d
    ./lib/cfg.d
    ./lib/epm/irstats2/cfg/cfg.d
    ./lib/defaultcfg/cfg.d

None of them include the "https_cgiroot" or "https_cgiurl" strings. However, I
took a quick dive in the Perl source, and found some weird logic (even
comments!) looking for those strings in the comments.

in eprints/perl_lib/EPrints/Repository.pm's _add_http_paths
(https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feprints%2Feprints%2Fblob%2F3.3%2Fperl_lib%2FEPrints%2FRepository.pm%23L733&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C6a5252b2cd824f6b5acd08dd6af2d11e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638784313324100722%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YIcTFzx%2F0BtVqL9p81FpPxnMTBcXsjFos5kQDfEsSdY%3D&reserved=0),
there is a comment stating that "Backwards-compatibility: http is fairly simple,
https may go wrong" (which matches my experience 😕). But well, given I'm not
configuring $c->{securehost} as explained earlier, my code flow stays in the
"simple" path. Anyway, reading this function helps me understand why some
settings are repeated with differing names...

If you still cannot find the configuration setting, get back to me with
what you have found and I shall see if I can advise further.  I doubt that
any default configuration setting under any of these directories is
missing "cgi" but it is possible it was accidentally or deliberately
changed to fix another problem at some point.

Thank you very much for your help! There are many bits that make my head itch,
but at least the configuration seems now to be functional 😃

Also, I would not usually set the setting the way that you did, although I
think the way you did it should work.  I would set it like this:

$c->{https_cgiurl} = "https://"; . $c->{securehost} . "/cgi";

This assumes that $c->{securehost} is already set in an earlier
configuration file.  Configuration files load in alphanumeric order.  This
possibly explains why you configured $c->{https_cgiurl} but then a later
configuration file overwrote this.

OK -- as said, setting $c->{securehost} breaks my site, but I built this url
using $c->{host}, and at least it didn't break 😉

thanks again,

  – Gunnar.