Indicating Character Encoding and Language for HTTP Header Field Parameters
RFC 8187

Document Type RFC - Proposed Standard (September 2017; No errata)
Obsoletes RFC 5987
Last updated 2017-09-14
Replaces draft-reschke-rfc5987bis
Stream IETF
Formats plain text pdf html bibtex
Reviews GENART will not review this version
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 IC
???

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
Show full document text