Summary: | oai.pl error response did not contain error code 'badResumptionToken' when it should | ||
---|---|---|---|
Product: | Koha | Reporter: | Pablo AB <pablo.bianchi> |
Component: | Web services | Assignee: | Bugs List <koha-bugs> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P4 | CC: | tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 21102 |
Description
Pablo AB
2018-07-24 00:16:06 UTC
I've been briefly poking at this. My findings are that the resumption token itself doesn't need to have a specific structure and is up to the implementation to defined how that token should look like. Koha uses this structure: "$metadata_prefix/$cursor/$from/$until/$set/$deleted/0/$next_id" This is an extreme reasoning, but things can be underspecified so they fallback to some default. I'm not sure if 'junk' couldn't be some valid resumption token if we decided to encode/compress the resumption token... That is, somehow, a weakness on the validation tool. They picked 'junk' meaning 'some random word'. That said, though: we know the structure of our resumption tokens (as pasted above) and we could be returning 'badResumptionToken' when the request doesn't comform to that structure. Do we agree? |