Indicating Character Encoding and Language for HTTP Header Field Parameters
RFC 8187
Document | Type |
RFC - Proposed Standard
(September 2017; No errata)
Obsoletes RFC 5987
|
|
---|---|---|---|
Author | Julian Reschke | ||
Last updated | 2018-12-20 | ||
Replaces | draft-reschke-rfc5987bis | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Mark Nottingham | ||
Shepherd write-up | Show (last changed 2017-02-01) | ||
IESG | IESG state | RFC 8187 (Proposed Standard) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Alexey Melnikov | ||
Send notices to | mnot@mnot.net | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) J. Reschke Request for Comments: 8187 greenbytes Obsoletes: 5987 September 2017 Category: Standards Track ISSN: 2070-1721 Indicating Character Encoding and Language for HTTP Header Field Parameters Abstract By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231. This document obsoletes RFC 5987. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8187. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Reschke Standards Track [Page 1] RFC 8187 Charset/Language Encoding in HTTP September 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 3. Comparison to RFC 2231 and Definition of the Encoding . . . . 3 3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 4 3.2. Parameter Value Character Encoding and Language Information . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . 6 3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Language Specification in Encoded Words . . . . . . . . . 7 4. Guidelines for Usage in HTTP Header Field Definitions . . . . 7 4.1. When to Use the Extension . . . . . . . . . . . . . . . . 8 4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . 12 Appendix B. Implementation Report . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Use of characters outside the US-ASCII coded character set ([RFC0020]) in HTTP header fields ([RFC7230]) is non-trivial: o The HTTP specification discourages use of non-US-ASCII characters in field values, placing them into the "obs-text" Augmented Backus-Naur Form (ABNF) production ([RFC7230], Section 3.2). o Furthermore, it stays silent about default character encoding schemes for field values, so any use of non-US-ASCII characters would need to be specific to the field definition or would require some other kind of out-of-band information. o Finally, some APIs assume a default character encoding scheme in order to map from the octet sequences (obtained from the HTTP message) to character sequences: for instance, the XMLHttpRequest API ([XMLHttpRequest]) uses the Interface Definition Language type "ByteString", effectively resulting in the ISO-8859-1 character encoding scheme ([ISO-8859-1]) being used. Reschke Standards Track [Page 2]Show full document text