CDI conversation activation conflicts with the Servlet spec

The Servlet specification says:

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, a new method setCharacterEncoding(String enc) has been
added to the ServletRequest interface. Developers can override the character
encoding supplied by the container by calling this method. It must be called prior to
parsing any post data or reading any input from the request. Calling this method
once data has been read will not affect the encoding.

The CDI specification says:

The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
application and before the container calls any ServletRequestListener or AsyncListener in the web application.

and

The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
parameter named cid containing the unique identifier of the conversation.

This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.

This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.