Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Allow header accuracy: advertise OPTIONS, and 405 instead of 404 on single-verb routes

Open
  • Is something wrong?
#318 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
74/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript
Domain
api, backend, testing

Research direction

Start with rest.sendMethodNotAllowed(), rest.createPatchOverrideMiddleware(), and getAllowedMethods() in routes/tests/route_wrappers.test.js to understand the current Allow derivation. Then inspect the route definitions in routes/api-routes.js, routes/compatability.js, and routes/static.js, including the static middleware ordering. Done means OPTIONS is included in emitted Allow values and the listed wrong-method requests return 405 with the expected headers, with the /v1/ decision resolved.

Written by the indexing model from the issue text.

Description

Follow-up to #296, which was resolved by #295. Two small Allow accuracy gaps remain. Both sit outside the scope of #296, which covered only routes that already return a 405.

OPTIONS is never listed in Allow

rest.sendMethodNotAllowed() emits only the verbs registered on the route, so no 405 response advertises OPTIONS. The cors middleware in app.js answers OPTIONS at every path with a 204, even with no Origin header present:

OPTIONS /v1/api/create  ->  HTTP/1.1 204 No Content
OPTIONS /v1/api/query   ->  HTTP/1.1 204 No Content
OPTIONS /v1/id/:_id     ->  HTTP/1.1 204 No Content

RFC 9110 §10.2.1 defines Allow as the set of methods supported by the target resource, so OPTIONS belongs in every value we emit.

Suggested approach: append OPTIONS inside rest.sendMethodNotAllowed() and rest.createPatchOverrideMiddleware() rather than editing all 20 call sites, then update getAllowedMethods() in routes/__tests__/route_wrappers.test.js so the derived expectation still matches.

Single-verb routes 404 where a 405 fits better

These routes register one verb with no .all() fallback, so a wrong method falls through to the app's 404 handler with no Allow header at all.

Request Current Expected
POST /v1/api 404 405 with Allow: GET,HEAD,OPTIONS
GET /v1/api/accessToken 404 405 with Allow: POST,OPTIONS
GET /v1/api/refreshToken 404 405 with Allow: POST,OPTIONS
POST /v1/ 404 405 with Allow: GET,HEAD,OPTIONS

Sources: router.get('/api', ...) in routes/api-routes.js, /accessToken and /refreshToken in routes/compatability.js, and router.get('/', ...) in routes/static.js.

Worth deciding whether /v1/ is wanted here. That router also serves the static public directory, so an .all() fallback has to sit after the static middleware or it will shadow real files.

Dominant language
JavaScript
Stars
3
Forks
6
Avg merge
3d 12h
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CenterForDigitalHumanities/rerum_server_nodejs

All issues in CenterForDigitalHumanities/rerum_server_nodejs

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.