EPrints Technical Mailing List Archive

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

Message: #08290

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

Re: [EP-tech] WG: Antwort: Linkcheck: HEAD method ends up in 404

Hi all,

I can see this happens with EPrints 3.3.12+ (and maybe earlier) but is not a problem with 3.4.2. Also the HEAD request works with /1234/ but not /id/eprint/1234/ on 3.3.12+.  If the trailing slash is missing you get redirected (302) to the version with a trailing slash but this then fails with /id/eprint/1234 on 3.3.12+ (but otherwise works).  I can take a look through the CRUD.pm files for 3.3.16 and 3.4.2 and see if I can spot what has been fixed.  I know for 3.4.2 I did some work to support PATCH requests but I am not aware of any recent changes/fixes for HEAD requests. 

That said, for3.4 functionality was introduced to allow the default abstract/summary page URLs to be the /id/eprint/... version as Google Scholar said it would make it easier for them to discover and index these.  This is because they could tell from the URL that it was an EPrints repository, whereas the generic http://hostname.example.org/1234/ could be anything, so they would not know to priotize its analysis and indexing.  There is a good chance that whilst this work was being done either by chance this HEAD request issue was fixed or it was detected and fixed during adding this functionality.  I was not involved directly in this work, so cannot tell you exactly what happened, I am just going on the information I know.

Regards

David Newman

On 05/08/2020 08:51, John Salter via Eprints-tech wrote:
One quick thought - does the trailing slash make a difference?
In 3.3 /id/eprint/1234 redirected, but /id/eprint/1234/ was also a 404.

Cheers,
John
From: eprints-tech-bounces@ecs.soton.ac.uk <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of Martin Braendle via Eprints-tech <eprints-tech@ecs.soton.ac.uk>
Sent: 05 August 2020 08:43
To: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>
Subject: [EP-tech] WG: Antwort: Linkcheck: HEAD method ends up in 404
 

Any comment on this by one of the EPrints developers @Southampton ?

Kind regards,

Martin


----- Weitergeleitet von Martin Brändle/at/UZH am 05.08.2020 09:41 -----

Von: "Martin Braendle via Eprints-tech" <eprints-tech@ecs.soton.ac.uk>
An: <eprints-tech@ecs.soton.ac.uk>
Datum: 22.07.2020 07:57
Betreff: [EP-tech] Antwort:  Linkcheck: HEAD method ends up in 404
Gesendet von: <eprints-tech-bounces@ecs.soton.ac.uk>




Hi,

just to bring up that topic again: perl_lib/EPrints/Apache/CRUD.pm should allow HEAD requests for https://{repo}/id/eprint/{xy}/  - that is why we wonder that EPrints returns a 404 ?

We observe that not only with our repo, but with other EPrints repos as well, e.g.

curl  "https://madoc.bib.uni-mannheim.de/id/eprint/3147/"   yields the page
curl --head "https://madoc.bib.uni-mannheim.de/id/eprint/3147/"  yields HTTP status 404!

So this must be a general bug of EPrints and it is not working according to the specification in perl_lib/EPrints/Apache/CRUD.pm

Kind regards,

Martin

--
Dr. Martin Brändle
Zentrale Informatik
Universität Zürich
Stampfenbachstr. 73
CH-8006 Zürich

Inactive hide details for "Martin Braendle via Eprints-tech" ---14.07.2020 14:12:41---Hi out there we're working on a linkcheck"Martin Braendle via Eprints-tech" ---14.07.2020 14:12:41---Hi out there we're working on a linkchecker to remove all gone official and related

Von: "Martin Braendle via Eprints-tech" <eprints-tech@ecs.soton.ac.uk>
An: <eprints-tech@ecs.soton.ac.uk>
Datum: 14.07.2020 14:12
Betreff: [EP-tech] Linkcheck: HEAD method ends up in 404
Gesendet von: <eprints-tech-bounces@ecs.soton.ac.uk>



Hi out there

we're working on a linkchecker to remove all gone official and related links in our Repo. Some of the URLs return to our own Repo and lickchecker gets an ugly 404 although the publications exist.

So, what we're doing is some LWP::UserAgent  stuff, a simple get HEAD of the URL an then analyze the response. If there was a '$status_code == HTTP_METHOD_NOT_ALLOWED' we would try a GET and all together we're doing some delay/retry/timeout handling. But in the end we allways catch a 404 :-(

Additional information
- We use a 404 handler
- We're allowed to use Get, Put, Trace, Options - all fine, only HEAD method results in a 404 ?!?
- We use the redirect from https://www.zora.uzh.ch/1 => https://www.zora.uzh.ch/id/eprint/1/ and it only seems to concern this dynamic type of content; static pages work fine.

Let's show some examples via CURL:

[zora]$ curl -i -X HEAD -L "https://www.zora.uzh.ch/1" (https://www.zora.uzh.ch/1')
HTTP/1.1 303 See Other
Date: Tue, 14 Jul 2020 11:49:08 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.11 Perl/v5.16.3
Location: /id/eprint/1

HTTP/1.1 303 See Other
Date: Tue, 14 Jul 2020 11:49:13 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.11 Perl/v5.16.3
Allow: GET,HEAD,PUT,OPTIONS
Location: https://www.zora.uzh.ch/id/eprint/1/
Strict-Transport-Security: max-age=15780000

HTTP/1.1 404 Not Found
Date: Tue, 14 Jul 2020 11:49:18 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.11 Perl/v5.16.3
Cache-Control: no-store, no-cache, must-revalidate
Strict-Transport-Security: max-age=15780000
Content-Type: text/html; charset=utf-8



[zora]$ curl -i -X HEAD -L "https://www.zora.uzh.ch/" (https://www.zora.uzh.ch/')
HTTP/1.1 200 OK
Date: Tue, 14 Jul 2020 11:49:31 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.11 Perl/v5.16.3
Expires: Thu, 13 Aug 2020 11:49:31 GMT
Cache-Control: no-store, no-cache, must-revalidate
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15780000
Content-Type: text/html; charset=utf-8



[zora]$ curl -i -X HEAD -L "https://www.zora.uzh.ch/help/" (https://www.zora.uzh.ch/help/')
HTTP/1.1 200 OK
Date: Tue, 14 Jul 2020 11:49:53 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.11 Perl/v5.16.3
Expires: Thu, 13 Aug 2020 11:49:53 GMT
Cache-Control: no-store, no-cache, must-revalidate
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15780000
Content-Type: text/html; charset=utf-8


Does anybody has any suggestion, solution, hint?

Kind gerads from Zürich
Martin & Jens
*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/

Virus-free. www.avg.com