`/manifest/{id}/manifest.json` returns 200 with an empty body
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
Research direction
The bug is in the switch in ProjectServlet.doGet (src/java/edu/slu/tpen/servlet/ProjectServlet.java, around lines 99-103), which handles only segment counts 1 and 3, so /manifest/7066/manifest.json falls through with an empty 200. Start by reproducing with a request to that URL, then add a case 2 that falls through to the existing case 1 after checking for manifest.json, plus a default 404. Done means the five URLs in the report return the expected results, and the missing break after the 404 in case 3 is also fixed.
Written by the indexing model from the issue text.
Description
Requests for a manifest at its /manifest.json URL return 200 OK with an empty body.
This is the URL T-PEN puts in every manifest's own @id / id, so IIIF viewers and anyone following that link get nothing back.
GET https://t-pen.org/TPEN/manifest/7066/manifest.json?version=3 -> 200, Content-Length: 0
GET https://t-pen.org/TPEN/manifest/7066/manifest.json -> 200, Content-Length: 0
GET https://t-pen.org/TPEN/project/7066/manifest.json -> 200, Content-Length: 0
GET https://t-pen.org/TPEN/manifest/99999999/manifest.json -> 200, Content-Length: 0 (project does not exist)
GET https://t-pen.org/TPEN/manifest/7066/foo.txt -> 200, Content-Length: 0
GET https://t-pen.org/TPEN/manifest/7066 -> 200, Presentation 2.1 manifest
GET https://t-pen.org/TPEN/manifest/7066?version=3 -> 200, Presentation 3 manifest
GET https://t-pen.org/TPEN/manifest/99999999 -> 404
Cause
ProjectServlet.doGet splits the path info on / and switches on the segment count, but only handles case 1 and case 3.
7066/manifest.json is two segments, so it matches no case, nothing is written, and the container's default 200 goes out with an empty body.
There is no default, so any other unhandled segment count does the same.
The case 1 body still has .replace("manifest.json",""), which was written to handle this URL (#14), but the switch introduced in #698 means a /manifest.json request never reaches it.
The manifest @id / id that points at this URL:
- https://github.com/CenterForDigitalHumanities/TPEN28/blob/fb3c7d3ecd439e0e8a722fbbc1c25e62de9a7d6b/src/java/edu/slu/tpen/transfer/JsonLDExporter.java#L67
- https://github.com/CenterForDigitalHumanities/TPEN28/blob/fb3c7d3ecd439e0e8a722fbbc1c25e62de9a7d6b/src/java/edu/slu/tpen/transfer/JsonLDExporter.java#L124
Suggested fix
Fix the servlet rather than the @id, since existing manifests and annotations already reference the /manifest.json URLs.
switch (urlData.length) {
case 2:
// project/*/manifest.json - Project
if (!urlData[1].equals("manifest.json")) {
resp.sendError(SC_NOT_FOUND);
break;
}
// fall through
case 1:
// project/* - Project
... existing case 1 body, unchanged ...
break;
case 3:
... existing case 3 body, unchanged ...
break;
default:
resp.sendError(SC_NOT_FOUND);
}
case 2falls through into the existingcase 1code, whosereplacealready turns7066/manifest.jsoninto7066.- Any other two-segment path gets a 404. A plain fall-through would hit
parseInt("7066foo.txt")and return a 500. defaultgives a 404 for other segment counts instead of an empty 200.
Related
In case 3, sendError(SC_NOT_FOUND) is not followed by a break, so an empty list still reaches listArray.get(0) and throws after the 404 is sent.
- Dominant language
- Java
- Stars
- 4
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CenterForDigitalHumanities/TPEN28
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
-
interoperability
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
interoperability
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
interoperability
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
servicesOpeninteroperability
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
All issues in CenterForDigitalHumanities/TPEN28
Similar issues
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
protobuf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
FasterXML/jackson-dataformats-binary#874 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
HexaHexes/infinite-dungeon-spawn-safety#17 ·
Maintainers usually reply within 1 day