[OAI-implementers] Questions about wrong output due to terrible input

[Simeon Warner]

On Tue, 1 Apr 2003, Jozef Kruger wrote:
> Hi everyone,
>  
> just this week someone from my firm tested my OAI implementation and he
> sent me a report with the results.
> What he did was give my program some terrible input with things like
> set=non_existing_made_up_set or from=very_illegal_date
> The protocol isn't being very specific about the arguments that are
> returned in the header (in the request node I mean).
> What I did was just return the the arguments that mattered (for each
> verb) the way they came in, resulting in invalid output in these cases.
>  
> Should I check for each of these if they contain any illegal stuff? If
> so and I would skip any illegal ones, the output wouldn't match with the
> input anymore.

See section 3.2 in the protocol spec, bullet point 3.

You must include the arguments of the request as attributes of the
<request> element of the response if the request did not generate an
error.

You must NOT include the arguments of the request as attributes of the
<request> element of the response if the request generated a badVerb or
badArgument error.

(The spec does not appear to be specific on the case when there is an 
error or exception which is not badArgument/badVerb. However, that doesn't
matter for the present discussion because in that case the arguments will
be schema-valid.)

> You could for example get error code="noRecordsMatch" due to an illegal
> date, but in the output you wouldn't see that date anymore.
>  
> I think the solution to this kind of problem would be a check before
> sending the request to the repository. But than again, you just might
> still be left with illegal input.. so omitting those things in the
> output looks like the only right solution.

The harvester SHOULD only send sensible parameters but the repository must
be able to sensibly handle bad requests.

Cheers,
Simeon.

  
> Any thoughts on these matters?
>  
> cheers,
> Jozef Kruger (Adlib Information Systems B.V. the Netherlands)
>