Skip to content

docs(middleware): correct CORS AllowMethods and AllowHeaders defaults - #3181

Open
ZainnQureshii wants to merge 1 commit into
labstack:masterfrom
ZainnQureshii:docs/cors-config-defaults
Open

ZainnQureshii wants to merge 1 commit into
labstack:masterfrom
ZainnQureshii:docs/cors-config-defaults

Conversation

@ZainnQureshii

Copy link
Copy Markdown

Corrects two CORSConfig field comments in middleware/cors.go that no longer match what the middleware does in v5.

AllowHeaders. The comment said Defaults to empty list. No domains allowed for CORS. With an empty list, ToMiddleware actually copies the request's Access-Control-Request-Headers value into Access-Control-Allow-Headers on the preflight response (the allowHeaders != "" else branch in the preflight handler). That allows every requested header, the opposite of what the comment says. The comment now says so.

AllowMethods. The comment said Default value DefaultCORSConfig.AllowMethods, but DefaultCORSConfig was removed in v5 (listed under "Also removed defaults" in API_CHANGES_V5.md). The fallback is now named directly: the router's Allow value, or GET, HEAD, PUT, PATCH, POST, DELETE (the list ToMiddleware sets when AllowMethods is empty) when the router sets none.

Comment-only change. Ran go vet ./middleware/ and go test ./middleware/ -run CORS (pass).

Prepared with AI assistance (Claude Code) and reviewed with GitHub Copilot.

🤖 Generated with Claude Code

AllowHeaders said an empty list allows no domains; an empty list makes
the preflight response reflect Access-Control-Request-Headers.
AllowMethods pointed at DefaultCORSConfig, which v5 removed; it now
names the fallback methods used when the router sets no Allow header.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant