Fix Response encoding not stored in the ext context session #5543#5544
Fix Response encoding not stored in the ext context session #5543#5544
Conversation
| // Save encoding in UIViewRoot for faster consult when Util#getResponseEncoding() is invoked again elsewhere. | ||
| context.getViewRoot().getAttributes().put(FACELETS_ENCODING_KEY, encoding); | ||
|
|
||
| // Save encoding in Session for consult in subsequent postback request as per spec section "2.5.2.2. Determining the Character Encoding". |
There was a problem hiding this comment.
Why is this stored in the session? Please review this with Servlet 6.0 specification, section 5.6. Internationalization in mind.
There was a problem hiding this comment.
As stated in that comment, this is mandated by the JSF 2.3 specification chapter 2.5.2.2 Determining the Character Encoding, see:
"[P1-start-encoding]At the end of the render-response phase, the ViewHandler must store the response character encoding
used by the underlying response object (e.g., the servlet or portlet response) in the session (if and only if a session
already exists) under a well known, implementation-dependent key."
There was a problem hiding this comment.
As I stated before this needs to be reviewed with the specified Servlet 6.0 specification in mind. I do not object to setting it, but I do not see any logic that looks at the Servlet level. Note that JSF 2.3 is not supported and I assume you meant to refer to Faces specifications?
There was a problem hiding this comment.
Yes, my fault, sorry, I meant Faces 4.0...
Anyhow, the spec has not changed there, see Jakarta Faces 4.0 specification.
As of that I don't see how this is related to the Servlet 6.0 specification, as the Faces specification already requires storing the character encoding in the session.
There was a problem hiding this comment.
Why is this stored in the session?
Because last used form encoding is not sent back via headers/payload of a postback request per-se.
Please review this with Servlet 6.0 specification, section 5.6. Internationalization in mind.
It's indeed used for setRequestEncoding() as mentioned in that spec to remedy any breakages.
If the client hasn’t set character encoding and the request data is encoded with a different encoding than the default as described above, breakage can occur. To remedy this situation, setRequestCharacterEncoding(String enc) is available on ServletContext
arjantijms
changed the title
|
@arjantijms , is this one ok to merge? We have some users needing the fix. Thanks ! |
|
Hi @BalusC @arjantijms, Is there any plan to release a new 4.0.10 soon? |
5 participants
#5543