EPrints Technical Mailing List Archive

Message: #07321

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

[EP-tech] Possible (small) error in oai2

Hi,
We passed our OAI PMH configuration through the compliance checker at http://re.cs.uct.ac.za/. 

The tests passed except for one :

   (8) Testing : ListIdentifiers (resumptionToken, oai_dc)
   URL : https://agritrop.cirad.fr/cgi/oai2?verb=ListIdentifiers&resumptionToken=metadataPrefix%3Doai_dc%26offset%3D553946&metadataPrefix=oai_dc
   ------ Start of XML Response ------
   <?xml version='1.0' encoding='UTF-8'?>
   <?xml-stylesheet type='text/xsl' href='/oai2.xsl' ?>
   <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd";>
      <responseDate>2018-06-05T08:57:12Z</responseDate>
      <request verb="ListIdentifiers" resumptionToken="metadataPrefix=oai_dc&amp;offset=553946" metadataPrefix="oai_dc">https://agritrop.cirad.fr/cgi/oai2</request>
      <ListIdentifiers>
        [...]
      </ListIdentifiers>
   </OAI-PMH>
   ------- End of XML Response -------
   Test Result : FAIL!
   **** [ERROR] Error tag expected but not found : badArgument,badResumptionToken
As we understand, this test checks a bad combination of parameters and expects to get an error from the server. But, instead, the server returns data... 

We looked at cgi/oai2 and found something odd :

 * at line 74, %arguments is defined
 * at line 131, the number of elements in %arguments is checked to
   check if it is > 1... but it is still empty
 * at line 165, the array is populated...
(https://github.com/eprints/eprints3.4/blob/master/cgi/oai2 -- We work on a 3.3.12 version, but the file is the same as the 3.4 one).
We changed the code at line 131, replacing %arguments by %params and the test #8 passed... 

-----
I'm not sure this error can cause problems for a harvester since the server returns data even if the harvester request does not strictly follow the protocol. I suppose harvesters don't complain when they get data even if they shouldn't...
Anyway, if you think that our modification is not the right one, please let us know... Thanks. 

Regards,
GF