Hi Fernando,

Having a look at a record where I can download the PDF where you have not had to do the trick with setting as a word document [1], i looks like you may be using the coversheets plugin.  This does some clever (maybe not so clever) mod rewrites so that although you request the original uncoversheeted PDF URL, EPrints can see that he document has a coversheeted version and uses mod rewrite to do an invisible redirect (i.e. the URL does not change in your browser address bar) to the coversheeted version.  I can quite believe that for some reason this coversheeted PDF is not generated and the mod rewrite sends you in an infinite loop and that is why your browser just sits there and nothing ever seems to happen.  This would explain why you can get the PDF when you switch it to a word document as it will know this cannot have a coversheet generate version and therefore will not get stuck in a redirect loop.

I have had a look at your counter URL [2] that you are running a very old version of EPrints (3.1.3).  I am not even sure you can run the coversheets plugin on this version of EPrints. (Although files.eprints.org suggest you can but maybe it works differently to more modern versions of EPrints).  Normally coversheeting tasks get added to the event queue.  The size of this queue does not get reported in your counter URL either, so I can tell whether the indexer has got stuck and caused this coversheet issue.  You really need to look at you Apache access and error logs whilst making these requests to see what log messages you get.  Also you should look at you Apache config files in:

EPRINTS_PATH/cfg/apache.conf

EPRINTS_PATH/cfg/apache/*.conf

EPRINTS_PATH/cfg/apache_ssl.conf

EPRINTS_PATH/cfg/apache_ssl/*.conf

EPRINTS_PATH/archives/ARCHIVE_NAME/cfg/apachevhost.conf (possibly some variation of this name)

EPRINTS_PATH/archives/ARCHIVE_NAME/ssl/securevhost.conf

(EPRINTS_PATH typicallyis /opt/eprints3/ or /usr/share/eprints/ and ARCHIVE_NAME is whatever you chose, possibly etheses).

There may be something in one of this files that explain why there is a mod rewrite that causes an infinite redirect.  Unfortunately, without having any access to look at these things it is very difficult to suggest what is going wrong.

Regards

David Newman

[1] http://etheses.dur.ac.uk/13138/1/I_E_Diriyai_electronic_copy_of_thesis_05.06.2019.pdf?DDD29+

[2] http://etheses.dur.ac.uk/cgi/counter

Hello,

In the last year or so we have found that some of the PDFs uploaded to our ePrints server etheses.dur.ac.uk cannot be downloaded. One can go as far as the web page with the details of the document but when clicking on the link the browser times out.

Examples are

http://etheses.dur.ac.uk/13171/

and

http://etheses.dur.ac.uk/13174/

 

We found a work around that is manually changing the document type to “Microsoft Word.” Then the PDF can be downloaded without any problems. E.g.:

http://etheses.dur.ac.uk/13127/

 

I searched for information on this issue in the Google group and also checked miscellaneous log files from ePrints but found nothing. I was wonder if this issue has been either mentioned or experienced by anyone in the past. We are running version 3.1.3

 

Regards,

 

Fernando

 

 

 

 

 

Fernando Andreu BSc (Hons) MSc MBCS AMEI

Metadata and Systems Librarian

Library and Heritage Collections

 

University of Durham

Bill Bryson Library

Stockton Road

Durham

DH1 3LY

United Kingdom

 

+44 (0)1913341587

 

*** 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/
*** EPrints developers Forum: http://forum.eprints.org/

Virus-free. www.avg.com