Every route answers HEAD with its GET handler, through chi's GetHead; the Go server drops the body.
The /api/v1 and /ip groups answer an unmatched path with a JSON 404 Not found, and POST, PUT, PATCH, DELETE, OPTIONS, TRACE or CONNECT with a JSON 405 Method not allowed.
JSONValidationMiddleware gives a 4xx sent without a JSON body the status's standard text (such as Bad Request) instead of Internal server error.
What the diff does not show:
Mounting a route group registers its own path (/ip, /ip/) for every method, so GetHead passes HEAD there on unchanged. The /ip group therefore registers HEAD on / itself; a GET route added at a group's root needs the same.
chi's own 405 sets Allow; the new 405 handler sets Allow: GET, HEAD itself, true only while the two groups take nothing else.
A method chi does not know, such as PROPFIND, is turned away by the top-level router with chi's empty 405.
A HEAD runs the whole GET handler, database reads included.
The middleware's 4xx text is now only a fallback, in the standard library's title case.
Disclosures:
Judgement call: the 405 sets Allow, which the issue does not ask for, as chi does today and HTTP requires.
Pages and the other routes outside the two groups keep chi's plain-text 404 and empty 405, as the issue scopes it.
TODO.md is not updated, as with the other audit fixes.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/routewatch/issues/111.
What changed:
- Every route answers `HEAD` with its `GET` handler, through chi's `GetHead`; the Go server drops the body.
- The `/api/v1` and `/ip` groups answer an unmatched path with a JSON 404 `Not found`, and `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, `TRACE` or `CONNECT` with a JSON 405 `Method not allowed`.
- `JSONValidationMiddleware` gives a 4xx sent without a JSON body the status's standard text (such as `Bad Request`) instead of `Internal server error`.
What the diff does not show:
- Mounting a route group registers its own path (`/ip`, `/ip/`) for every method, so `GetHead` passes `HEAD` there on unchanged. The `/ip` group therefore registers `HEAD` on `/` itself; a `GET` route added at a group's root needs the same.
- chi's own 405 sets `Allow`; the new 405 handler sets `Allow: GET, HEAD` itself, true only while the two groups take nothing else.
- A method chi does not know, such as `PROPFIND`, is turned away by the top-level router with chi's empty 405.
- A `HEAD` runs the whole `GET` handler, database reads included.
- The middleware's 4xx text is now only a fallback, in the standard library's title case.
Disclosures:
- Judgement call: the 405 sets `Allow`, which the issue does not ask for, as chi does today and HTTP requires.
- Pages and the other routes outside the two groups keep chi's plain-text 404 and empty 405, as the issue scopes it.
- `TODO.md` is not updated, as with the other audit fixes.
Model: opus-5-5
README.md, section "HTTP Endpoints", the paragraph on error answers: it says that under /api/v1 and /ip/ "a method other than GET and HEAD answers 405 with Method not allowed". That holds only for the methods the router knows (POST, PUT, PATCH, DELETE, OPTIONS, TRACE, CONNECT). Any other method, for example PROPFIND /api/v1/stats or PROPFIND /ip/, is turned away by the top-level router that setupRoutes (internal/server/routes.go) builds, before the request reaches either group. That answer is a 405 with an empty body, no Content-Type and no Allow header. Acceptable: the README sentence claims only what the code does, for example "another standard HTTP method", or the code gives those requests the JSON 405 as well.
Model: opus-5-5
1. `README.md`, section "HTTP Endpoints", the paragraph on error answers: it says that under `/api/v1` and `/ip/` "a method other than `GET` and `HEAD` answers 405 with `Method not allowed`". That holds only for the methods the router knows (`POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, `TRACE`, `CONNECT`). Any other method, for example `PROPFIND /api/v1/stats` or `PROPFIND /ip/`, is turned away by the top-level router that `setupRoutes` (`internal/server/routes.go`) builds, before the request reaches either group. That answer is a 405 with an empty body, no `Content-Type` and no `Allow` header. Acceptable: the README sentence claims only what the code does, for example "another standard HTTP method", or the code gives those requests the JSON 405 as well.
Model: opus-5-5
The README sentence now names the methods that get the JSON 405 (POST, PUT, PATCH, DELETE, OPTIONS, TRACE, CONNECT) instead of "a method other than GET and HEAD"; the commit message and PR body say the same, and the PR body notes that a method the router does not know, such as PROPFIND, still gets chi's empty 405. No code changed.
Model: opus-5-5
1. The README sentence now names the methods that get the JSON 405 (`POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, `TRACE`, `CONNECT`) instead of "a method other than `GET` and `HEAD`"; the commit message and PR body say the same, and the PR body notes that a method the router does not know, such as `PROPFIND`, still gets chi's empty 405. No code changed.
Model: opus-5-5
internal/server/routes.go, setupRoutes: HEAD /ip and HEAD /ip/ (the lookup of the caller's own address) still answer 405, while GET on the same paths runs the lookup. The 405 even carries Allow: GET, HEAD. chi's GetHead first asks the router whether a HEAD route exists. r.Route("/ip", ...) registers /ip and /ip/ themselves for every method, so GetHead passes the request on as HEAD, and the group's / route refuses it. Other paths under /ip/ and /api/v1 are not affected. This misses the issue's first definition-of-done item (HEAD served for every GET route). It also makes two things in the PR untrue: the new README sentence "Every route answers HEAD as it answers GET" and the comment on jsonRoutesAllow. TestRoutesAnswerHEAD (internal/server/routes_internal_test.go) checks only / and /api/v1/stats, so it misses this. Acceptable: HEAD /ip and HEAD /ip/ answer as GET does, without the body, and TestRoutesAnswerHEAD covers /ip/.
Model: opus-5-5
1. `internal/server/routes.go`, `setupRoutes`: `HEAD /ip` and `HEAD /ip/` (the lookup of the caller's own address) still answer 405, while `GET` on the same paths runs the lookup. The 405 even carries `Allow: GET, HEAD`. chi's `GetHead` first asks the router whether a `HEAD` route exists. `r.Route("/ip", ...)` registers `/ip` and `/ip/` themselves for every method, so `GetHead` passes the request on as `HEAD`, and the group's `/` route refuses it. Other paths under `/ip/` and `/api/v1` are not affected. This misses the issue's first definition-of-done item (`HEAD` served for every `GET` route). It also makes two things in the PR untrue: the new README sentence "Every route answers `HEAD` as it answers `GET`" and the comment on `jsonRoutesAllow`. `TestRoutesAnswerHEAD` (`internal/server/routes_internal_test.go`) checks only `/` and `/api/v1/stats`, so it misses this. Acceptable: `HEAD /ip` and `HEAD /ip/` answer as `GET` does, without the body, and `TestRoutesAnswerHEAD` covers `/ip/`.
Model: opus-5-5
Every route was registered for GET only, so HEAD answered 405, and on
the JSON routes that 405 said "Internal server error". chi's GetHead
now serves HEAD with the GET handler; /ip and /ip/ register HEAD
themselves, as GetHead does not reach them. The /api/v1 and /ip route
groups answer a path they lack with a JSON 404 "Not found", and the
other methods the router knows (POST, PUT, PATCH, DELETE, OPTIONS,
TRACE, CONNECT) with a JSON 405 "Method not allowed" whose Allow header
names GET and HEAD. JSONValidationMiddleware gives a 4xx sent without a
JSON body the status's standard text instead of "Internal server error".
Model: opus-5-5
HEAD /ip and HEAD /ip/ now run the lookup of the caller's own address as GET does, and the Go server drops the body: the /ip group registers HEAD on its / route itself, since mounting the group registers those two paths for every method and GetHead passes HEAD there on unchanged. TestRoutesAnswerHEAD now covers /ip and /ip/. The comment on jsonRoutesAllow now says the routes take GET and HEAD, and the PR body and commit message say why /ip registers HEAD itself.
Model: opus-5-5
1. `HEAD /ip` and `HEAD /ip/` now run the lookup of the caller's own address as `GET` does, and the Go server drops the body: the `/ip` group registers `HEAD` on its `/` route itself, since mounting the group registers those two paths for every method and `GetHead` passes `HEAD` there on unchanged. `TestRoutesAnswerHEAD` now covers `/ip` and `/ip/`. The comment on `jsonRoutesAllow` now says the routes take `GET` and `HEAD`, and the PR body and commit message say why `/ip` registers `HEAD` itself.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements #111.
What changed:
HEADwith itsGEThandler, through chi'sGetHead; the Go server drops the body./api/v1and/ipgroups answer an unmatched path with a JSON 404Not found, andPOST,PUT,PATCH,DELETE,OPTIONS,TRACEorCONNECTwith a JSON 405Method not allowed.JSONValidationMiddlewaregives a 4xx sent without a JSON body the status's standard text (such asBad Request) instead ofInternal server error.What the diff does not show:
/ip,/ip/) for every method, soGetHeadpassesHEADthere on unchanged. The/ipgroup therefore registersHEADon/itself; aGETroute added at a group's root needs the same.Allow; the new 405 handler setsAllow: GET, HEADitself, true only while the two groups take nothing else.PROPFIND, is turned away by the top-level router with chi's empty 405.HEADruns the wholeGEThandler, database reads included.Disclosures:
Allow, which the issue does not ask for, as chi does today and HTTP requires.TODO.mdis not updated, as with the other audit fixes.Model: opus-5-5
README.md, section "HTTP Endpoints", the paragraph on error answers: it says that under/api/v1and/ip/"a method other thanGETandHEADanswers 405 withMethod not allowed". That holds only for the methods the router knows (POST,PUT,PATCH,DELETE,OPTIONS,TRACE,CONNECT). Any other method, for examplePROPFIND /api/v1/statsorPROPFIND /ip/, is turned away by the top-level router thatsetupRoutes(internal/server/routes.go) builds, before the request reaches either group. That answer is a 405 with an empty body, noContent-Typeand noAllowheader. Acceptable: the README sentence claims only what the code does, for example "another standard HTTP method", or the code gives those requests the JSON 405 as well.Model: opus-5-5
38a9383c24to6ce4ee255bPOST,PUT,PATCH,DELETE,OPTIONS,TRACE,CONNECT) instead of "a method other thanGETandHEAD"; the commit message and PR body say the same, and the PR body notes that a method the router does not know, such asPROPFIND, still gets chi's empty 405. No code changed.Model: opus-5-5
internal/server/routes.go,setupRoutes:HEAD /ipandHEAD /ip/(the lookup of the caller's own address) still answer 405, whileGETon the same paths runs the lookup. The 405 even carriesAllow: GET, HEAD. chi'sGetHeadfirst asks the router whether aHEADroute exists.r.Route("/ip", ...)registers/ipand/ip/themselves for every method, soGetHeadpasses the request on asHEAD, and the group's/route refuses it. Other paths under/ip/and/api/v1are not affected. This misses the issue's first definition-of-done item (HEADserved for everyGETroute). It also makes two things in the PR untrue: the new README sentence "Every route answersHEADas it answersGET" and the comment onjsonRoutesAllow.TestRoutesAnswerHEAD(internal/server/routes_internal_test.go) checks only/and/api/v1/stats, so it misses this. Acceptable:HEAD /ipandHEAD /ip/answer asGETdoes, without the body, andTestRoutesAnswerHEADcovers/ip/.Model: opus-5-5
6ce4ee255btodb4f58d737HEAD /ipandHEAD /ip/now run the lookup of the caller's own address asGETdoes, and the Go server drops the body: the/ipgroup registersHEADon its/route itself, since mounting the group registers those two paths for every method andGetHeadpassesHEADthere on unchanged.TestRoutesAnswerHEADnow covers/ipand/ip/. The comment onjsonRoutesAllownow says the routes takeGETandHEAD, and the PR body and commit message say why/ipregistersHEADitself.Model: opus-5-5
Review passed.
Model: opus-5-5