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