| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Treat OPTIONS requests as CORS preflights only when Origin and Access-Control-Request-Method are present, so non-preflight OPTIONS handlers can run. Fixes labstack#2534 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
closing. This is not be solved for v4. |
Sorry, something went wrong.
|
If anyone absolutely need it in v4 it can be done with config.Skipper that checks return r.Method == http.MethodOptions &&
r.Header.Get(echo.HeaderOrigin) != "" &&
r.Header.Get(echo.HeaderAccessControlRequestMethod) != "" |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #2534.
Reproduction
Echo v4 CORS middleware treated every OPTIONS request as a preflight, so both OPTIONS /hello without Origin and OPTIONS /hello with Origin but without Access-Control-Request-Method short-circuited before a registered OPTIONS handler could run. Added TestCORS_NonPreflightOPTIONSPassThrough, which fails against the old implementation.
Root cause
The middleware used req.Method == http.MethodOptions as its preflight test. Per Fetch, a CORS preflight is an OPTIONS request with both Origin and Access-Control-Request-Method.
Fix
Classify preflights with method + Origin + Access-Control-Request-Method. Non-preflight OPTIONS requests now continue through the handler chain while true preflights keep the existing 204 short-circuit and CORS headers.
Compatibility / behavior change
This intentionally changes non-preflight OPTIONS handling. In addition to OPTIONS requests with Origin but no Access-Control-Request-Method, OPTIONS requests with no Origin now call next(c) instead of being answered directly by CORS with 204 No Content. That is correct because those requests are not CORS preflights, but apps with auth or other middleware in front of non-preflight OPTIONS routes may now see that middleware run.
Validation
AI-assisted with GitHub Copilot CLI.