Question about ViewHandler.calculateCharacterEncoding(FacesContext)
I'm hoping one of the JSF experts will answer the questions in this post, because they're questions about the intent behind a new method in the 1.2 version of the JSF API.
In JSF 1.2 the method calculateCharacterEncoding(FacesContext) was added to ViewHandler. When I first saw the Javadocs I thought that the purpose of this method would be to specify the character encoding used in responses to a client. However after examining the code, the usage appears to be more subtle than that.
In fact, calculateCharacterEncoding(FacesContext) appears primarily intended to determine the character encoding of the incoming request. In the initView(FacesContext) implementation in ViewHandler the request's character encoding is explicitly set to the result of calculateCharacterEncoding if the method returns a non-null result.
In the JSF-RI concrete implementation of ViewHandler (and in implementations such as FaceletViewHandler) this is the last time calculateCharacterEncoding is called. The character encoding specified in the response is copied from the one set on the incoming request in initView.
i) My first question is - is this how it's supposed to work? It seems a little indirect, and I haven't found any actual documentation that specifies how the response encoding is supposed be set.
ii) Second, doesn't this behavior exclude a number of possible cases? Imagine that I have an incoming request that has an explicitly set value for charset in the Content-Type header. Now, there's also an Accept-Encoding header with a number of different values. Now, I'd prefer to send my responses in a character encoding listed in the Accept-Encoding header other than the one specified in Content-Type. As I understand it, this should be legal in HTTP. But I don't see how to do it inside JSF.
If calculateCharacterEncoding returns the original request encoding (the default behavior) then the response will automatically be set to the original request encoding. Not the desired result.
If instead I write calculateCharacterEncoding to return the new, preferred character encoding then there's a different problem. The request encoding will be set incorrectly. I'm not going to be able to properly parse any String values that might come in with the request. This seems like a problem. If the values have already been read in and parsed by this point (and hence are accessible) does it really make sense to set the character encoding on the request? I'm not sure what the intention is.
Have I missed something here? Is the case I'm describing excluded by some standard or another? Is there a way to differentiate between the response and request encoding in JSF 1.2?
Any clarification on these questions would be helpful. Ideally I'd like to have an app that parsed incoming requests correctly but sent responses in a preferred encoding (UTF-8) assuming it's listed in the Accept-Encoding header. I don't see how to do that within the confines of JSF today, without resorting to Filters and such.
Regards,
Peter
