codeconsole commented on PR #16149: URL: https://github.com/apache/grails-core/pull/16149#issuecomment-5482593380
Thanks — worked through all eight. **1. `request.method` reports POST — intended; the docs were wrong.** The override is resolved after the filter chain, so POST is the method on the wire, the one Spring Security saw, and the one the access log records. Routing and `allowedMethods` use the effective method. The `FileUploadSpec` expectation you cite was already updated in `7ea7ab4`. The dispatcher comment and upgrade note still claimed the request agreed — corrected in `246c96f`. **2. Multipart text fields — valid, fixed.** `GrailsParameterMap` now merges the multipart wrapper's parameter map as well as its files, without displacing the request's own values. Test covers the outer-request/native-map shape. `246c96f` **3. Forward/include — valid, fixed.** `resolveHttpMethod` applies the dispatcher's guard. Error dispatches never reach it (matched by status code first), so it doesn't mention them. Tests for both. `246c96f` **4. Generic PUT/PATCH forms — valid, fixed.** `<g:form>` emits `_method` for any non-GET/non-POST again. Two cases beyond the one you listed were also broken: PATCH resource forms (the POST route reaches `update`, but PATCH maps to the separate `patch` action) and singular `resource` mappings (no POST route is generated). `8092298` **5. Bare member POST — valid as a docs gap, fixed.** The route is intentional (#9926), but the note described it as a fix without saying it is a route that did not exist. It now says so, and to review rules granting POST by prefix. `246c96f` **6. `isAjax()` — valid, fixed.** Tolerant read. Pre-existing upstream, but this PR changes when it is first hit. `246c96f` **7. `HttpMethodOverrideDetector` — not valid.** No call site, as you note. Dead code; removing it is its own change. **8. Interceptor reversal — not valid.** Upstream reversed into a copy and wrote that copy back to the attribute, so a second `postHandle` re-reverses either way. I ran the same order-asserting test against both implementations — identical. Nothing else holds the list: the attribute is private to the adapter, and the only other reader is a benchmark. You were right that the spec asserted nothing about order, so it does now: `286ed28`. Separately, on the Grails 7 plugin interceptor error — which plugin? That reads like binary compatibility against a 7-compiled artifact rather than these changes, but I would like to reproduce it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
