405 Responses And Allow Header #296

Activity

1. thehabes commented on Sep 24, 2026

   

   thehabes

   on Sep 24, 2026

   Last edited by thehabes

   MemberAuthor

   More actions

   Resolved by #295 (fix: include accurate Allow headers on 405 responses), merged to main as 5702087. The branch was named for #287 and the merge body did not reference this issue, so it stayed open.

   Verified against a running instance. All 20 405 fallbacks emit an Allow header whose value matches the verbs actually registered on that route:

   Path	Allow
   /v1/api/query	POST,HEAD
   /v1/api/search, /v1/api/search/phrase	POST
   /v1/id/:_id	GET,HEAD
   /v1/id/:_id/expanded	GET,POST,HEAD
   /v1/since/:_id, /v1/history/:_id	GET,HEAD
   /v1/api/create, /v1/api/bulkCreate	POST
   /v1/api/update, /v1/api/overwrite, /v1/api/bulkUpdate	PUT
   /v1/api/patch, /v1/api/set, /v1/api/unset	PATCH,POST
   /v1/api/release/:_id	PATCH
   /v1/api/delete/:_id	DELETE
   /gog/id/:_id	GET,HEAD
   /gog/fragmentsInManuscript, /gog/glossesInManuscript	POST

   No method is advertised that the route rejects. Every HEAD in the table above returns a 200 against a real object, including HEAD /v1/api/query via controller.queryHeadRequest. POST on the patch routes is genuinely supported through X-HTTP-Method-Override.

   The 200-path concern is handled too: configureWebAnnoHeadersFor() in utils.js no longer emits Allow. The only remaining writes of that header in non-test code are the two 405 emitters in rest.js.

   Regression coverage is in routes/__tests__/route_wrappers.test.js, which table-drives all 20 routes and derives the expected Allow from each router's own route.methods rather than hard-coding strings, so a route that gains or loses a verb without updating its fallback will fail. Full suite passes at 240/240.

   Two smaller Allow accuracy gaps that fall outside the scope of this issue are tracked in #318.
2. thehabes

   closed this as completedon Sep 24, 2026