CharEncodingFilter and the Acegi security filter

[Anil Gangolli <an...@busybuddha.org>]

The Acegi security filter got placed before CharEncodingFilter (which 
sets the request encoding to UTF-8 and synchronizes the Struts and JSTL 
notions of locale).

Unless we're very sure that the security filter never triggers request 
parsing (which gets triggered by any reference to parameters or things 
beyond the header), I'd like to keep CharEncodingFilter first in the 
chain.  I believe its operations are safe to have in front of the 
security filter, and not having it in front threatens to break i18n on 
paths similar to ROL-670 (which hopefully Acegi resolves).

I'd like to do this before 2.1 but after Dave resolves the blank page 
issue; don't want to add any additional noise to that picture.

Objections?

--a.

Re: CharEncodingFilter and the Acegi security filter

[Allen Gilliland <Al...@Sun.COM>]

I agree.  I think we can go ahead and do this now, it should be affecting the blank page issue.

-- Allen


On Wed, 2005-12-07 at 08:00, Anil Gangolli wrote:
> The Acegi security filter got placed before CharEncodingFilter (which 
> sets the request encoding to UTF-8 and synchronizes the Struts and JSTL 
> notions of locale).
> 
> Unless we're very sure that the security filter never triggers request 
> parsing (which gets triggered by any reference to parameters or things 
> beyond the header), I'd like to keep CharEncodingFilter first in the 
> chain.  I believe its operations are safe to have in front of the 
> security filter, and not having it in front threatens to break i18n on 
> paths similar to ROL-670 (which hopefully Acegi resolves).
> 
> I'd like to do this before 2.1 but after Dave resolves the blank page 
> issue; don't want to add any additional noise to that picture.
> 
> Objections?
> 
> --a.
>