Done
Details
Reporter
Anastasiia ZakharovaAnastasiia ZakharovaBack End Estimate
Large < 10 daysRank: 5Colleges (Full Jul 2021)
R4Rank: Cornell (Full Sum 2021)
R4Rank: GBV (MVP Sum 2020)
R4Rank: TAMU (MVP Jan 2021)
R2Rank: Chicago (MVP Sum 2020)
R2TestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Reporter
Anastasiia Zakharova
Anastasiia ZakharovaBack End Estimate
Large < 10 days
Rank: 5Colleges (Full Jul 2021)
R4
Rank: Cornell (Full Sum 2021)
R4
Rank: GBV (MVP Sum 2020)
R4
Rank: TAMU (MVP Jan 2021)
R2
Rank: Chicago (MVP Sum 2020)
R2
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created March 11, 2020 at 1:30 PM
Updated September 16, 2021 at 5:17 PM
Resolved June 16, 2020 at 1:49 PM
In event of an error or exception condition, repositories must indicate OAI-PMH errors, distinguished from HTTP Status-Codes, by including one or more error elements in the response. While one error element is sufficient to indicate the presence of the error or exception condition, repositories should report all errors or exceptions that arise from processing the request. Each error element must have a code attribute that must be from the following table; each error element may also have a free text string value to provide information about the error that is useful to a human reader. These strings are not defined by the OAI-PMH.
Version 2 of the OAI-PMH recommends clear separation of OAI-PMH errors and HTTP statuses in a next way:
all OK at HTTP level? => 200 OK
something wrong at OAI-PMH level? => OAI-PMH error (e.g. badVerb)
HTTP codes 302, 503, etc. still available to implementers, but no longer represent OAI-PMH events