EPrints Technical Mailing List Archive

Message: #08520

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

Re: [EP-tech] Elements-EPrints Odd Characters stopping upload

CAUTION: This e-mail originated outside the University of Southampton.
Thank you David, that is quite helpful knowing that I'm not totally barking up the wrong tree.

If i'm honest, on both issues I'm not against trying to sort it myself, but it's going to be a huge pain and quite a large investment of time and effort on my part to fix something that will [hopefully] be replaced within the next year (something I have been saying for two years now).

The best course of action may be to use these two occurrences to try to hurry up our installation of RT2. At the moment it's been pushed back until after we upgrade to Elements version 6. Yet Elements version 6 is not a requirement for RT2 so far as I'm aware. The previous reason to delay was the impending REF, but that is both ongoing and over now. I may try to exaggerate the difficulties these problems are causing at our next relevant meeting...

Anyway, thank you once more for your help and advice. Very much appreciated.

James

On Wed, Feb 17, 2021 at 1:06 PM David R Newman <drn@ecs.soton.ac.uk> wrote:

Hi James,

Yes, that does look like a bit if a complex issue.  The URL it is pointing to on EPrints seems to be its representation of the record through Symplectic's RT1 rt4eprints handler.  Thay URL looks ok once you decode it but it is not the same URL as the file URL for EPrints, although I would expect it to return the same things.  However, the rt4eprints handler may then parse the file parameter in the get header is some interestingw ay.  Semi-colons are often used as a separator in various different ways so it may think you have specified two files:

Induction with Thymoglobulin in High-Risk Renal Transplant Patients

Beauty and the Beast.pdf

What is does in this situation is uncertain without reviewing their code.  It may just try to recover one or other of the potential files neither of which exists, so it fails.  I think you are probably right that RT2 will fix this as there will no longer be an rt4eprints handler to which the URL is refering.

Regards

David Newman

On 17/02/2021 12:52, James Kerwin wrote:
CAUTION: This e-mail originated outside the University of Southampton.
Right it did not take long to refamiliarise myself. The following EPrints record has one file with a semicolon in the file name (";" for the avoidance of doubt). I can access the file on EPrints, but in Elements via Chrome and FireFox I get quite similar errors.


In Elements when I go to the record and click the file icon I would expect it to download or open in the browser, instead I get an error:


Going through this with another file on another record that has no ";" in the filename it works as expected.

Looking at the links from both EPrints and Elements there's some sort of difference in the link to the file:

https://livrepository.liverpool.ac.uk/3008387/1/Induction%20with%20Thymoglobulin%20in%20High-Risk%20Renal%20Transplant%20Patients%3B%20Beauty%20and%20the%20Beast.pdf

https%3A%2F%2Flivrepository.liverpool.ac.uk%2Frt4eprints%2Ffile%2F106106%2FInduction%2520with%2520Thymoglobulin%2520in%2520High-Risk%2520Renal%2520Transplant%2520Patients%253B%2520Beauty%2520and%2520the%2520Beast.pdf

This is an example of what we get for a working record:

EPrints File Link:
Elements File Link:

The only consistent difference is the presence of these characters, but I can't really understand where it's going wrong. I had wanted to take a proper look at it and get in touch with Symplectic, but people have the audacity to keep finding new problems and giving me more work... We are due to upgrade to RT2 soonish (2nd half of this year probably) and I am hoping all of this goes away with that.

Thanks,
James

On Wed, Feb 17, 2021 at 12:18 PM James Kerwin <jkerwin2101@gmail.com> wrote:
Hi David,

Thank you for your reply. Unfortunately I don't have access to the Elements database(s) but I've explained this issue to our Elements people and hopefully should get a response. Meanwhile, some time ago Mr Salter gave me the means to extract the Elements xml and transform it via the crosswalks outside of EPrints, so I may do that with the different records and see what we get. Doing this has only just now occurred to me now so I'll give it a go.

On the subject of the character in question... The error code comes from (I think!):

eprints3/perl_lib/URI/Escape.pm

Specifically here in the _fail_hi sub:

"sub uri_escape {
    my($text, $patn) = @_;
    return undef unless defined $text;
    if (defined $patn){
        unless (exists  $subst{$patn}) {
            # Because we can't compile the regex we fake it with a cached sub
            (my $tmp = $patn) =~ s,/,\\/,g;
            eval "\$subst{\$patn} = sub {\$_[0] =~ s/([$tmp])/\$escapes{\$1} || _fail_hi(\$1)/ge; }";
            Carp::croak("uri_escape: $@") if $@;
        }
        &{$subst{$patn}}($text);
    } else {
        $text =~ s/($Unsafe{RFC3986})/$escapes{$1} || _fail_hi($1)/ge;
    }
    $text;
}

sub _fail_hi {
    my $chr = shift;
    Carp::croak(sprintf "Can't escape \\x{%04X}, try uri_escape_utf8() instead", ord($chr));"

The FULL error log line says:

Can't escape \\x{2019}, try uri_escape_utf8() instead at /opt/eprints3/perl_lib/URI/Escape.pm line 178.\n\tURI::Escape::_fail_hi('\xe2\x80\x99') called at /opt/eprints3/perl_lib/URI/Escape.pm line 171\n\tURI::Escape::uri_escape('Published by the American Physical Society under the terms of...') called at (eval 177) line 82\n\tEPrints::Config::uolrepo::__ANON__('dataset', 'EPrints::DataSet=HASH(0x7f21238f9358)', 'repository', 'Symplectic::Wrappers::EPrintsSession=HASH(0x7f2124610710)', 'dataobj', 'EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', 'changed', 'HASH(0x7f212d684f18)') called at /opt/eprints3/perl_lib/EPrints/DataSet.pm line 1517\n\tEPrints::DataSet::run_trigger('EPrints::DataSet=HASH(0x7f21238f9358)', 105, 'dataobj', 'EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', 'changed', 'HASH(0x7f212d684f18)') called at /opt/eprints3/perl_lib/EPrints/DataObj.pm line 669\n\tEPrints::DataObj::commit('EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', undef) called at /opt/eprints3/perl_lib/EPrints/DataObj/EPrint.pm line 1011\n\tEPrints::DataObj::EPrint::commit('EPrints::DataObj::EPrint=HASH(0x7f21285879b0)') called at /opt/eprints3/perl_lib/Symplectic/RepoProcess/MetadataManager.pm line 355\n\tSymplectic::RepoProcess::MetadataManager::add_preferred_bibliographic('Symplectic::RepoProcess::MetadataManager=HASH(0x7f2123858468)', 'eprint', 'EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', 'raw_record', 'XML::LibXML::Document=SCALAR(0x7f212858bb60)', 'types', 'ARRAY(0x7f21254315a0)', 'limit_to', 'ARRAY(0x7f21215fceb8)', ...) called at /opt/eprints3/perl_lib/Symplectic/RepoProcess/MetadataManager.pm line 240\n\tSymplectic::RepoProcess::MetadataManager::add_bibliographic('Symplectic::RepoProcess::MetadataManager=HASH(0x7f2123858468)', 'eprint', 'EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', 'publication', 'Symplectic::PubsModel::Publication=HASH(0x7f212d6b7fe8)') called at /opt/eprints3/perl_lib/Symplectic/RepoProcess/IngestWorkflow.pm line 203\n\tSymplectic::RepoProcess::IngestWorkflow::update_metadata('Symplectic::RepoProcess::IngestWorkflow=HASH(0x7f212858f348)', 'eprint', 'EPrints::DataObj::EPrint=HASH(0x7f21285879b0)', 'publication', 'Symplectic::PubsModel::Publication=HASH(0x7f212d6b7fe8)', 'auth_details', 'Symplectic::PubsModel::AuthDetails=HASH(0x7f212d785c38)', 'record', 'Symplectic::RepoModel::PublicationsRecord=HASH(0x7f212c73f510)', ...) called at /opt/eprints3/perl_lib/Symplectic/RepoProcess/PublicationManager.pm line 65\n\tSymplectic::RepoProcess::PublicationManager::get_deposit_representation('Symplectic::RepoProcess::PublicationManager=HASH(0x7f212d7ac290)', 'publication', 'Symplectic::PubsModel::Publication=HASH(0x7f212d6b7fe8)', 'auth_details', 'Symplectic::PubsModel::AuthDetails=HASH(0x7f212d785c38)') called at /opt/eprints3/perl_lib/Symplectic/Process/FileDepositProcessor.pm line 148\n\tSymplectic::Process::FileDepositProcessor::handle('Symplectic::Process::FileDepositProcessor=HASH(0x7f212d6d73b0)', 'pid', 485375, 'auth_details', 'Symplectic::PubsModel::AuthDetails=HASH(0x7f212d785c38)', 'deposit_props', 'Symplectic::PubsModel::DepositProperties=HASH(0x7f212e8a0440)', 'atom', 'CGI::File::Temp=GLOB(0x7f212d7fae08)', ...) called at /opt/eprints3/perl_lib/Symplectic/Handlers/RepositoryHandler.pm line 235\n\tSymplectic::Handlers::RepositoryHandler::post_handler('session', 'Symplectic::Wrappers::EPrintsSession=HASH(0x7f2124610710)', 'request', 'Apache2::RequestRec=SCALAR(0x7f212e8a77a8)', 'auth_details', 'Symplectic::PubsModel::AuthDetails=HASH(0x7f212d785c38)') called at /opt/eprints3/perl_lib/Symplectic/Handlers/RepositoryHandler.pm line 109\n\tSymplectic::Handlers::RepositoryHandler::handler_multi('Apache2::RequestRec=SCALAR(0x7f212e8a77a8)', undef) called at /opt/eprints3/perl_lib/Symplectic/Apache/Rewrite.pm line 98\n\tSymplectic::Apache::Rewrite::__ANON__('Apache2::RequestRec=SCALAR(0x7f212e8a77a8)') called at -e line 0\n\teval {...} called at -e line 0\n

I'm making some big assumptions, but I THINK the "\\x{%04X}" is saying "take 4 characters from the result of ord($chr) and put them here". I'm possibly very wrong. I think any solution for this needs to belong in the Symplectic code on the repo server. I don't fancy altering core EPrints code for the sake of this. I'll be in a whole world of hell before I know it. Yesterday when tracing this I ended up at:

eprints3/symplectic/perl_lib/Symplectic/RepoProcess/MetadataManager.pm

Reading through the code it appears to identify the preferred record and start processing it. Perhaps this is a good opportunity to intervene and either swap bad characters for good ones or encode/decode "properly" (as if I know what I'm talking about). Complicated slightly by not being able to thoroughly test it. I suppose another option would be to see what XSLT etc. can do with regard to this and so catch the problem within the crosswalks.

If we verify the manual record in Elements it gets a higher precedence than the Scopus record and so the problem disappears.

Regarding the other problem with the file link I will need to refamiliarise myself with it and I'll reply later. Plus this email is already wordy enough as it is!

Thanks,
James



On Wed, Feb 17, 2021 at 10:31 AM David R Newman <drn@ecs.soton.ac.uk> wrote:

Hi James,

I think you would need to look at this field in the Elements record in its database to look how it is being stored differently when there is an import compared to where there is manual entry.  As you said I think the problem is in part that text box entries get parsed and encoded before going into the database but imports do not (or at very least the process between input and output to the Elements database is different).  It would be useful to know how they look different in the Elements database as they may assist making EPrints more resilient to unexpected encodings in future. 

However "\\x{2019}" looks like an escaped version of something that is not particularly valid.  If this was "\\u{2019}" this would probably work better as \x I think can only be used to represent a standard ASCII character that can be only two hex digits like \x3a is a colon ":". \u is used for the extended character set (i.e. UTF-16).  \u{2019} in UTF-8 would be \xE2\x80\x99.

It would be interesting to get a bit more information about your other issue with regular quote marks and semi-colons that are part of the standard ASCII set rather than an extended characters.  These really should not be causing a problem.

Regards

David Newman

On 17/02/2021 09:44, James Kerwin via Eprints-tech wrote:
CAUTION: This e-mail originated outside the University of Southampton.
Hi All,

This is an Elements/EPrints question. Apologies that it isn't purely EPrints, but this is probably the best place to get an answer. I want to know if others experience this or it's some oddity to our setup.

We are using RT1 (for now) and EPrints 3.3.14 (also for now until upgrade). Occasionally we get an Elements record that is from Scopus, PubMed etc. that has an odd character in it that prevents upload. When I look in the Apache logs it tells me the problem. Yesterday's one was the presence of:

 "Unicode Character “’” (U+2019)"

Which showed in the logs as:

"Can't escape \\x{2019}, try uri_escape_utf8() instead at /opt/eprints3/perl_lib/URI/Escape.pm"

Importantly if I copy the problem characters to the manual elements record it doesn't pose a problem. There appears some processing to properly encode characters entered via text box, but not characters dragged in from other sources into Elements.

I've also had the issue with the files containing "'" or" ";" etc not being accessible via Elements (a very similar, but different problem).

I found where I COULD fix the former issue, but it involves changing EPrints code when I SHOULD be altering the Symplectic connector code on the repo server.

Anyway, I'm not specifically looking for a solution, but has anybody else experienced anything similar? If so, does it stop with RT2? I hope to raise a ticket with Symplectic over this eventually.

Thanks,
James



*** 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