codeconsole commented on code in PR #16760:
URL: https://github.com/apache/grails-core/pull/16760#discussion_r4414133748
##########
grails-doc/src/en/guide/upgrading/upgrading90x.adoc:
##########
@@ -1229,3 +1229,15 @@ See <<asyncPromises,Promises>> and <<events,Events>>.
`grails-async-rxjava3` carries a `null` value as the RxJava 1 factory and
every other promise factory do: `createPromise()` and `createPromise(Class)`
give a promise whose `get()` returns `null`, a task that returns `null`
resolves to `null`, and a `null` value keeps its place in the list that
`onComplete`, `onError` and `waitAll` deliver.
`grails-async-rxjava2` does not: there `createPromise()` and `onComplete` over
a list holding a bound promise of `null` fail with a `NullPointerException`,
and a task that returns `null` resolves to the `java.lang.Void` class.
+
+==== 20. Spring Boot Registers the Character Encoding Filter
+
+Grails no longer registers a character encoding filter of its own. It used to,
and Spring Boot's backed off, so `spring.servlet.encoding` had no effect in a
Grails application. Spring Boot's filter now decodes requests: it runs at
`Ordered.HIGHEST_PRECEDENCE`, ahead of every other filter, and
`spring.servlet.encoding` configures it.
+
+* The request encoding is now overridden by default, as in any Spring Boot
application, so a request that declares a charset of its own is still decoded
as UTF-8: its parameters, a body read through `getReader()`, `request.JSON` and
`request.XML`, and a JSON or XML body bound to a command object or domain
class. The parameters of a PUT, PATCH or DELETE form are the exception, as in
Grails 8: the `FormContentFilter` that parses them decodes them with the
declared charset, forced or not. To keep the charset a request declares, as
Grails 8 did, set `spring.servlet.encoding.force-request: false`.
+* Filters ordered between `Ordered.HIGHEST_PRECEDENCE + 1` and -181, which
used to run before Grails' encoding filter, now run after Spring Boot's, with
the request encoding set. asset-pipeline's filter at -190 is one: in a packaged
application (a WAR or an executable jar) it copies the request's encoding to
the precompiled assets it serves, so every asset response now declares a
charset, for example `text/css;charset=UTF-8`, and browsers use it for
stylesheets and scripts instead of detecting their encoding. A filter among
them that reads a request body sent without a charset through `getReader()` now
decodes it as UTF-8 instead of ISO-8859-1.
+* `grails.filter.encoding` and `grails.filter.forceEncoding` are deprecated.
Grails 9 translates them into `spring.servlet.encoding.charset` and
`spring.servlet.encoding.force` and logs a warning, and a
`spring.servlet.encoding` setting of the application wins over them. Use the
Spring Boot properties instead.
+* `GrailsFilters.CHARACTER_ENCODING_FILTER` is deprecated, and its order is
now `Ordered.HIGHEST_PRECEDENCE`, the order of Spring Boot's encoding filter,
where Grails 8.0 had -180. A filter ordered at
`GrailsFilters.CHARACTER_ENCODING_FILTER.order + 1` therefore runs right after
the encoding filter. Order it at `Ordered.HIGHEST_PRECEDENCE + 1` instead.
Review Comment:
Taken as you wrote it, in 1392891667, for §20 and the skill's bullet. The
8.1 notes had the same gap, so #16792 adds the same paragraph to §5 of the 8.1
guide, its required actions and the `grails-8-upgrade` skill, with
`ASSET_PIPELINE_FILTER.order + 1` as the way to keep the 8.0 place.
##########
grails-doc/src/en/guide/plugins/hookingIntoRuntimeConfiguration.adoc:
##########
@@ -384,11 +384,11 @@ However, if you want to control the order of filter
registrations you will need
myFilter(FilterRegistrationBean) {
filter = bean(MyFilter)
urlPatterns = ['/*']
- order = Ordered.HIGHEST_PRECEDENCE
+ order = Ordered.HIGHEST_PRECEDENCE + 1
}
----
-NOTE: Grails' internal registered filters (`GrailsWebRequestFilter`,
`HiddenHttpMethodFilter` etc.) are defined by incrementing `HIGHEST_PRECEDENCE`
by 10 thus allowing several filters to be inserted before or between Grails'
filters.
+NOTE: Spring Boot registers the character encoding filter at
`Ordered.HIGHEST_PRECEDENCE`, ahead of every other filter. Once any filter
reads a request parameter, the servlet container has decoded the request body,
so a filter that reads parameters needs a later order than the encoding filter,
or form input arrives decoded as ISO-8859-1. A filter registered at exactly
`Ordered.HIGHEST_PRECEDENCE` through a `FilterRegistrationBean` runs before it.
Grails' own filters (`HiddenHttpMethodFilter`, `GrailsWebRequestFilter` etc.)
have orders from -200 to -150, ten apart, and `GrailsFilters.LAST` is at -110,
ahead of the Spring Security filter chain at -100, which leaves room to insert
filters before or between them.
Review Comment:
Changed to "at least ten apart" in 8eb3cb3941. #16792 makes the same change
on 8.1.x, with the same wording, so the note resolves cleanly at the merge-up.
--
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]
