draft-ietf-httpbis-jfv-01.txt   draft-ietf-httpbis-jfv-02.txt 
HTTP Working Group J. Reschke HTTP Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Standards Track July 8, 2016 Intended status: Standards Track October 24, 2016
Expires: January 9, 2017 Expires: April 27, 2017
A JSON Encoding for HTTP Header Field Values A JSON Encoding for HTTP Header Field Values
draft-ietf-httpbis-jfv-01 draft-ietf-httpbis-jfv-02
Abstract Abstract
This document establishes a convention for use of JSON-encoded field This document establishes a convention for use of JSON-encoded field
values in HTTP header fields. values in HTTP header fields.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on April 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 4 3. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 4
4. Recipient Requirements . . . . . . . . . . . . . . . . . . . . 5 4. Recipient Requirements . . . . . . . . . . . . . . . . . . . . 5
5. Using this Format in Header Field Definitions . . . . . . . . 5 5. Using this Format in Header Field Definitions . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Content-Length . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Content-Length . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 6 6.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 6
6.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 6.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7
6.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8 6.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
9. Internationalization Considerations . . . . . . . . . . . . . 9 9. Interoperability Considerations . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9.1. Encoding and Characters . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.3. Object Constraints . . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11 10. Internationalization Considerations . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 11 publication) . . . . . . . . . . . . . . . . . . . . 12
A.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 11 A.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 12
A.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12 A.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 12
A.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 12 A.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 12
A.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 12 A.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 13
A.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 12 A.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 13
A.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 12 A.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 A.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Defining syntax for new HTTP header fields ([RFC7230], Section 3.2) Defining syntax for new HTTP header fields ([RFC7230], Section 3.2)
is non-trivial. Among the commonly encountered problems are: is non-trivial. Among the commonly encountered problems are:
o There is no common syntax for complex field values. Several well- o There is no common syntax for complex field values. Several well-
known header fields do use a similarly looking syntax, but it is known header fields do use a similarly looking syntax, but it is
hard to write generic parsing code that will both correctly handle hard to write generic parsing code that will both correctly handle
valid field values but also reject invalid ones. valid field values but also reject invalid ones.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
[[anchor8: Mention potential "Key" header field extension ([KEY]).]] [[anchor8: Mention potential "Key" header field extension ([KEY]).]]
8. Deployment Considerations 8. Deployment Considerations
This JSON-based syntax will only apply to newly introduced header This JSON-based syntax will only apply to newly introduced header
fields, thus backwards compatibility is not a problem. That being fields, thus backwards compatibility is not a problem. That being
said, it is conceivable that there is existing code that might trip said, it is conceivable that there is existing code that might trip
over double quotes not being used for HTTP's quoted-string syntax over double quotes not being used for HTTP's quoted-string syntax
(Section 3.2.6 of [RFC7230]). (Section 3.2.6 of [RFC7230]).
9. Internationalization Considerations 9. Interoperability Considerations
The "I-JSON Message Format" specification ([RFC7493]) addresses known
JSON interoperability pain points. This specification borrows from
the requirements made over there:
9.1. Encoding and Characters
This specification requires that field values use only US-ASCII
characters, and thus by definition use a subset of UTF-8 (Section 2.1
of [RFC7493]).
9.2. Numbers
Be aware of the issues around number precision, as discussed in
Section 2.2 of [RFC7493].
9.3. Object Constraints
As described in Section 4 of [RFC7159], JSON parser implementations
differ in the handling of duplicate object names. Therefore, senders
MUST NOT use duplicate object names, and recipients SHOULD either
treat field values with duplicate names as invalid (consistent with
[RFC7493], Section 2.3) or use the lexically last value (consistent
with [ECMA-262], Section 24.3.1.1).
Furthermore, ordering of object members is not significant and can
not be relied upon.
10. Internationalization Considerations
In HTTP/1.1, header field values are represented by octet sequences, In HTTP/1.1, header field values are represented by octet sequences,
usually used to transmit ASCII characters, with restrictions on the usually used to transmit ASCII characters, with restrictions on the
use of certain control characters, and no associated default use of certain control characters, and no associated default
character encoding, nor a way to describe it ([RFC7230], Section character encoding, nor a way to describe it ([RFC7230], Section
3.2). HTTP/2 does not change this. 3.2). HTTP/2 does not change this.
This specification maps all characters which can cause problems to This specification maps all characters which can cause problems to
JSON escape sequences, thereby solving the HTTP header field JSON escape sequences, thereby solving the HTTP header field
internationalization problem. internationalization problem.
Future specifications of HTTP might change to allow non-ASCII Future specifications of HTTP might change to allow non-ASCII
characters natively. In that case, header fields using the syntax characters natively. In that case, header fields using the syntax
defined by this specification would have a simple migration path (by defined by this specification would have a simple migration path (by
just stopping to require escaping of non-ASCII characters). just stopping to require escaping of non-ASCII characters).
10. Security Considerations 11. Security Considerations
Using JSON-shaped field values is believed to not introduce any new Using JSON-shaped field values is believed to not introduce any new
threads beyond those described in Section 12 of [RFC7159], namely the threads beyond those described in Section 12 of [RFC7159], namely the
risk of recipients using the wrong tools to parse them. risk of recipients using the wrong tools to parse them.
Other than that, any syntax that makes extensions easy can be used to Other than that, any syntax that makes extensions easy can be used to
smuggle information through field values; however, this concern is smuggle information through field values; however, this concern is
shared with other widely used formats, such as those using parameters shared with other widely used formats, such as those using parameters
in the form of name/value pairs. in the form of name/value pairs.
11. References 12. References
12.1. Normative References
11.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", [RFC0020] Cerf, V., "ASCII format for network interchange",
STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>. <http://www.rfc-editor.org/info/rfc20>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, Syntax Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 11, line 5 skipping to change at page 11, line 32
Routing", RFC 7230, DOI 10.17487/RFC7230, Routing", RFC 7230, DOI 10.17487/RFC7230,
June 2014, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Transfer Protocol (HTTP/1.1): Semantics and
Content", RFC 7231, DOI 10.17487/RFC7231, Content", RFC 7231, DOI 10.17487/RFC7231,
June 2014, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
11.2. Informative References [RFC7493] Bray, T., Ed., "The I-JSON Message Format",
RFC 7493, DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
12.2. Informative References
[ECMA-262] Ecma International, "ECMA-262 6th Edition, The
ECMAScript 2015 Language Specification",
Standard ECMA-262, June 2015,
<http://www.ecma-international.org/ecma-262/6.0/>.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet graphic character sets -- Part 1: Latin alphabet
No. 1", ISO/IEC 8859-1:1998, 1998. No. 1", ISO/IEC 8859-1:1998, 1998.
[KEY] Fielding, R. and M. Nottingham, "The Key HTTP [KEY] Fielding, R. and M. Nottingham, "The Key HTTP
Response Header Field", draft-ietf-httpbis-key-01 Response Header Field", draft-ietf-httpbis-key-01
(work in progress), March 2016. (work in progress), March 2016.
skipping to change at page 12, line 33 skipping to change at page 13, line 21
A.5. Since draft-reschke-http-jfv-04 A.5. Since draft-reschke-http-jfv-04
Change to HTTP Working Group draft. Change to HTTP Working Group draft.
A.6. Since draft-ietf-httpbis-jfv-00 A.6. Since draft-ietf-httpbis-jfv-00
Added example for "Accept-Encoding" (inspired by Kazuho's feedback), Added example for "Accept-Encoding" (inspired by Kazuho's feedback),
showing a potential way to optimize the format when default values showing a potential way to optimize the format when default values
apply. apply.
A.7. Since draft-ietf-httpbis-jfv-01
Add interop discussion, building on I-JSON and ECMA-262 (see
<https://github.com/httpwg/http-extensions/issues/225>).
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks go to the Hypertext Transfer Protocol Working Group Thanks go to the Hypertext Transfer Protocol Working Group
participants. participants.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
 End of changes. 11 change blocks. 
21 lines changed or deleted 68 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/