Indicating Character Encoding and Language for HTTP Header Field Parameters
obsoletes
- rfc-5987 — Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
Extracted elements (23)
Quoted-string notation is explicitly disallowed in ext-value for backwards compatibility with RFC 2231, even though some generic parser components may silently accept it. The specification deviates from common HTTP parameter syntax to maintain this compatibility.
RFC 2047 encoded-word language extensions (RFC 2231 Section 5) are excluded because RFC 7230 Section 3.2.4 deprecated the use of RFC 2047 encoding forms in HTTP header fields.
RFC 2231 parameter continuations (for splitting long values across multiple parameters) are not included because HTTP does not have the header-length limitations that apply to MIME; RFC 7231 Appendix A.6 confirms this.
The requirement to support ISO-8859-1 (present in RFC 5987) was removed because UTF-8 is sufficient to express all Unicode code points; implementations like Internet Explorer 9 already omitted ISO-8859-1 support.
UTF-8 was made mandatory-to-implement because RFC 2231 left the character encoding unspecified, creating ambiguity for senders. Mandating UTF-8 eliminates that ambiguity and covers all Unicode code points.
For backwards compatibility with RFC 5987, recipients are encouraged (though not required) to support ISO-8859-1 decoding of ext-value, as legacy code may produce it.
Parameter names ending in an asterisk should not be used for non-extended-syntax purposes because some existing implementations automatically switch to ext-value notation when a name ends with asterisk, causing interoperability problems.
Specifications using this extension should disallow multiple instances of extended parameters with identical names, since the RFC 2231 continuation mechanism makes processing of such duplicates ambiguous.
The attr-char production excludes curly braces "{" and "}" because the RFC 7230 token production (unlike the RFC 2045 production used in RFC 2231) excludes them; this differs from the original RFC 2231 definition.
Producers MUST use the UTF-8 character encoding when generating ext-value tokens. Extension character encodings (mime-charset) are reserved for future use only.
Recipients implementing this specification MUST support the UTF-8 character encoding. RFC 2231 did not specify a mandatory-to-implement character encoding, making it hard for senders to choose; this specification closes that gap.
The character encoding name (charset) is REQUIRED inside an ext-value; the encoding defined here does not allow it to be omitted, unlike RFC 2231.
The ext-value production ought to always be used when the parameter value is textual and its language is known, per RFC 2277's requirement that human-readable protocol elements carry language information.
The mime-charset production SHOULD be registered in the IANA charset registry. Single-quote characters are excluded from mime-charset names.
When both a plain and an extended parameter with identical names are present, the extended syntax takes precedence. This allows producers to supply both formats for compatibility with legacy recipients.
An ext-value is a three-part token: (1) REQUIRED charset name, (2) OPTIONAL BCP 47 language tag, and (3) the percent-encoded character sequence (value-chars), separated by single-quote characters. Both charset names and language tags are US-ASCII and matched case-insensitively.
Known attack scenarios exist related to decoding UTF-8, including malformed sequences. The specification does not mandate specific error-handling behavior but lists acceptable strategies: ignoring the parameter, stripping non-decodable octets, or substituting U+FFFD.
The extension permits transporting multiple language variants of a single parameter, which may enable spoofing attacks if different language versions are not semantically equivalent. Whether this is an effective attack depends on the specific parameter.
Transporting non-ASCII characters enables character spoofing scenarios where a displayed value appears to be something other than it is. See RFC 3629 Section 10 for details on known UTF-8 spoofing and decoding attacks.
attr-char covers ALPHA, DIGIT, and the characters "!#$&+-.^_`|~"; it explicitly excludes "*", "'", "%", and curly braces "{}". Characters outside attr-char must be percent-encoded using the specified charset.
Extended parameters are conventionally indicated by a parameter name ending in an asterisk (e.g., title*), but this is a convention only; the header field definition must explicitly opt in to the ext-value syntax.
pct-encoded is defined as "%" HEXDIG HEXDIG (case-insensitive hex digits), following RFC 3986 Section 2.1. Recipients must accept both uppercase and lowercase hex digits.
The ext-value ABNF is: ext-value = charset "'" [ language ] "'" value-chars, where charset is "UTF-8" or a mime-charset token, language is an RFC 5646 Language-Tag, and value-chars is a sequence of pct-encoded or attr-char characters.