codeconsole commented on PR #16149: URL: https://github.com/apache/grails-core/pull/16149#issuecomment-5498623172
All three valid. Fixed in 2234fe9 — though one of them I fixed the other way round, and it is worth saying why. **Command object and request body binding — fixed.** Both read `effectiveMethod` now. The body case was the real one: a `POST` naming `DELETE` was having its body bound where the filter would have skipped it, since `ignoredRequestBodyMethods` is keyed on the method. Covered by two cases in `AbstractRequestBodyDataBindingSourceCreatorSpec`. The command object branch only diverges for a domain command object reached without an identifier, which needs a GORM-backed controller to exercise, so it rests on the rule and the upgrade table rather than a test of its own. **Stale override on a forward — real, but clearing it is the wrong repair.** Under the servlet filter the wrapper reports the overridden method for the whole request, forwards included. Clearing the attribute would make dispatcher mode disagree with filter mode, which is the one thing moving the override was meant not to do. The inconsistency was my forward/include guard from the last round being too broad: it discarded an override the dispatcher had already published, so routing said `POST` while the method-keyed reader, `RenderContext` and link generation all still said `PUT`. The mapping now honours a published override wherever it applies, and refuses only to *derive* a fresh one from inherited parameters on an internal dispatch — which is the case your earlier finding was actually about. Tests cover a forward and an include carrying a resolved override, asserting the route and the other readers agree. **`isAjax()` multipart read — fixed.** Tolerant on the wrapper too, which is the read likelier to force the failing parse. On coverage: agreed there is no single end-to-end request-path test, and that remains the honest gap. -- 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]
