confusion in "3.12 Request data encoding"

Nobody has claimed this yet.

"Currently, many browsers do not send a char encoding qualifier with the Content-Type
header, leaving open the determination of the character encoding for reading HTTP requests.
The default encoding of a request the container uses to create the request reader and parse
POST data must be “ISO-8859-1” if none has been specified by the client request, web
application or container vendor specific configuration (for all web applications in the
container). However, in order to indicate to the developer, in this case, the failure of the
client to send a character encoding, the container returns null from the
getCharacterEncoding method."

That is very misleading.

From an HTTP payload point of view, the actual character encoding for "application/x-www-form-urlencoded", as defined in <[https://www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm](https://www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm)> is **always** US-ASCII. Period.

The octet representation of non-US-ASCII characters is **always** percent-encoded - this means that whatever the HTTP payload header fields describes is totally irrelevant for this content type (as long as it is an USASCII-compatible encoding).

It may not be possible to change the ISO-8859-1 default, but note that the HTTP spec never ever said that this actually is the default (I believe earlier versions of the servlet spec pretended that this was the case).

Locate section 3.12, “Request data encoding,” and compare its quoted requirements with the linked HTML form encoding algorithm. Clarify the distinction between the payload encoding, the Content-Type charset, and getCharacterEncoding behavior; done means the section no longer implies an unsupported HTTP default.

Written by the indexing model from the issue text.