Re: [xwiki-devs] [xwiki-notifications] r10662 - xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF
Sergiu, I think it would be beneficial to document below that the filters must be run on this order and explain why. WDYT? Thanks -Vincent On Jun 24, 2008, at 2:00 PM, sdumitriu (SVN) wrote:
Author: sdumitriu Date: 2008-06-24 14:00:10 +0200 (Tue, 24 Jun 2008) New Revision: 10662
Modified: xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml Log: XWIKI-891 and XWIKI-1771: Fix regression caused by wrong filter order (non-ASCII chars in ISO-8859-1 are lost).
Modified: xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml =================================================================== --- xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml 2008-06-24 10:52:43 UTC (rev 10661) +++ xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml 2008-06-24 12:00:10 UTC (rev 10662) @@ -9,15 +9,6 @@ <display-name>xwiki</display-name> <description>XWiki Application</description>
- <!-- A filter that allows requests to be saved and reused later. For example when the current request contains an expired - authentication token, and the authorization module redirects to the login page, all the information sent by the - client would be lost; this filter allows to save all that information, and after a successful login, injects the - saved data in the new request. --> - <filter> - <filter-name>RequestRestorer</filter-name> - <filter-class>com.xpn.xwiki.web.SavedRequestRestorerFilter</ filter-class> - </filter> - <!-- Filter that sets a custom encoding to all requests, since usually clients don't specificy the encoding used for submitting the request, so by default containers fall back to the encoding globally configured in their settings. This allows XWiki to use a custom encoding, @@ -41,12 +32,21 @@ </init-param> </filter>
+ <!-- A filter that allows requests to be saved and reused later. For example when the current request contains an expired + authentication token, and the authorization module redirects to the login page, all the information sent by the + client would be lost; this filter allows to save all that information, and after a successful login, injects the + saved data in the new request. --> + <filter> + <filter-name>RequestRestorer</filter-name> + <filter-class>com.xpn.xwiki.web.SavedRequestRestorerFilter</ filter-class> + </filter> + <filter-mapping> - <filter-name>RequestRestorer</filter-name> + <filter-name>Set Character Encoding</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> - <filter-name>Set Character Encoding</filter-name> + <filter-name>RequestRestorer</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Vincent Massol wrote:
Sergiu,
I think it would be beneficial to document below that the filters must be run on this order and explain why. WDYT?
Yes, but sincerely I don't understand why it must be in this order. In theory the setCharacterEncoding call should be forwarded through the first filter, so it shouldn't matter in what order the two filters are used. I'll investigate further.
On Jun 24, 2008, at 2:00 PM, sdumitriu (SVN) wrote:
Author: sdumitriu Date: 2008-06-24 14:00:10 +0200 (Tue, 24 Jun 2008) New Revision: 10662
Modified: xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml Log: XWIKI-891 and XWIKI-1771: Fix regression caused by wrong filter order (non-ASCII chars in ISO-8859-1 are lost).
Modified: xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml =================================================================== --- xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml 2008-06-24 10:52:43 UTC (rev 10661) +++ xwiki-platform/web/trunk/standard/src/main/webapp/WEB-INF/ web.xml 2008-06-24 12:00:10 UTC (rev 10662) @@ -9,15 +9,6 @@ <display-name>xwiki</display-name> <description>XWiki Application</description>
- <!-- A filter that allows requests to be saved and reused later. For example when the current request contains an expired - authentication token, and the authorization module redirects to the login page, all the information sent by the - client would be lost; this filter allows to save all that information, and after a successful login, injects the - saved data in the new request. --> - <filter> - <filter-name>RequestRestorer</filter-name> - <filter-class>com.xpn.xwiki.web.SavedRequestRestorerFilter</ filter-class> - </filter> - <!-- Filter that sets a custom encoding to all requests, since usually clients don't specificy the encoding used for submitting the request, so by default containers fall back to the encoding globally configured in their settings. This allows XWiki to use a custom encoding, @@ -41,12 +32,21 @@ </init-param> </filter>
+ <!-- A filter that allows requests to be saved and reused later. For example when the current request contains an expired + authentication token, and the authorization module redirects to the login page, all the information sent by the + client would be lost; this filter allows to save all that information, and after a successful login, injects the + saved data in the new request. --> + <filter> + <filter-name>RequestRestorer</filter-name> + <filter-class>com.xpn.xwiki.web.SavedRequestRestorerFilter</ filter-class> + </filter> + <filter-mapping> - <filter-name>RequestRestorer</filter-name> + <filter-name>Set Character Encoding</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> - <filter-name>Set Character Encoding</filter-name> + <filter-name>RequestRestorer</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (2)
-
Sergiu Dumitriu -
Vincent Massol