draft-reschke-http-jfv-09.txt   draft-reschke-http-jfv-latest.txt 
Network Working Group J. Reschke Network Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Intended status: Standards Track July 2, 2018 Intended status: Informational October 17, 2019
Expires: January 3, 2019 Expires: April 19, 2020
A JSON Encoding for HTTP Header Field Values A JSON Encoding for HTTP Header Field Values
draft-reschke-http-jfv-09 draft-reschke-http-jfv-latest
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
This note is to be removed before publishing as an RFC.
Distribution of this document is unlimited. Although this is not a Distribution of this document is unlimited. Although this is not a
work item of the HTTPbis Working Group, comments should be sent to work item of the HTTPbis Working Group, comments should be sent to
the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http- the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-
wg@w3.org [1], which may be joined by sending a message with subject wg@w3.org [1], which may be joined by sending a message with subject
"subscribe" to ietf-http-wg-request@w3.org [2]. "subscribe" to ietf-http-wg-request@w3.org [2].
Discussions of the HTTPbis Working Group are archived at Discussions of the HTTPbis Working Group are archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
XML versions and latest edits for this document are available from XML versions and latest edits for this document are available from
<http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>. <http://greenbytes.de/tech/webdav/#draft-reschke-http-jfv>.
The changes in this draft are summarized in Appendix E.12. The changes in this draft are summarized in Appendix E.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 3, 2019. This Internet-Draft will expire on April 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 49 skipping to change at page 2, line 49
A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 10 A.1. Content-Length . . . . . . . . . . . . . . . . . . . . . 10
A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 10 A.2. Content-Disposition . . . . . . . . . . . . . . . . . . . 10
A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 11 A.3. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 11
A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 12 A.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 13 Appendix B. Use of JSON Field Value Encoding in the Wild . . . . 13
B.1. W3C Reporting API Specification . . . . . . . . . . . . . 14 B.1. W3C Reporting API Specification . . . . . . . . . . . . . 14
B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 14 B.2. W3C Clear Site Data Specification . . . . . . . . . . . . 14
B.3. W3C Feature Policy Specification . . . . . . . . . . . . 14 B.3. W3C Feature Policy Specification . . . . . . . . . . . . 14
Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 14 Appendix C. Relation to HTTP 'Key' Header Field . . . . . . . . 14
Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 14 Appendix D. Discussion . . . . . . . . . . . . . . . . . . . . . 14
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 15
publication) . . . . . . . . . . . . . . . . . . . . 14
E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 15 E.1. Since draft-reschke-http-jfv-00 . . . . . . . . . . . . . 15
E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 15 E.2. Since draft-reschke-http-jfv-01 . . . . . . . . . . . . . 15
E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 15 E.3. Since draft-reschke-http-jfv-02 . . . . . . . . . . . . . 15
E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 15 E.4. Since draft-reschke-http-jfv-03 . . . . . . . . . . . . . 15
E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 15 E.5. Since draft-reschke-http-jfv-04 . . . . . . . . . . . . . 15
E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 15 E.6. Since draft-ietf-httpbis-jfv-00 . . . . . . . . . . . . . 15
E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 15 E.7. Since draft-ietf-httpbis-jfv-01 . . . . . . . . . . . . . 15
E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 15 E.8. Since draft-ietf-httpbis-jfv-02 . . . . . . . . . . . . . 16
E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 16 E.9. Since draft-reschke-http-jfv-05 . . . . . . . . . . . . . 16
E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 16 E.10. Since draft-reschke-http-jfv-06 . . . . . . . . . . . . . 16
E.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 16 E.11. Since draft-reschke-http-jfv-07 . . . . . . . . . . . . . 16
E.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 16 E.12. Since draft-reschke-http-jfv-08 . . . . . . . . . . . . . 16
E.13. Since draft-reschke-http-jfv-09 . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 8, line 45 skipping to change at page 8, line 45
Latest version available at <https://www.w3.org/TR/clear- Latest version available at <https://www.w3.org/TR/clear-
site-data/>. site-data/>.
[ECMA-262] [ECMA-262]
Ecma International, "ECMA-262 6th Edition, The ECMAScript Ecma International, "ECMA-262 6th Edition, The ECMAScript
2015 Language Specification", Standard ECMA-262, June 2015 Language Specification", Standard ECMA-262, June
2015, <http://www.ecma-international.org/ecma-262/6.0/>. 2015, <http://www.ecma-international.org/ecma-262/6.0/>.
[FEATUREPOL] [FEATUREPOL]
Clelland, I., "Feature Policy", W3C Draft Community Group Clelland, I., "Feature Policy", W3C Draft Community Group
Report , June 2018, Report , October 2019,
<https://wicg.github.io/feature-policy/>. <https://wicg.github.io/feature-policy/>.
[HSTRUCT] Nottingham, M. and P-H. Kamp, "Structured Headers for [HSTRUCT] Nottingham, M. and P-H. Kamp, "Structured Headers for
HTTP", draft-ietf-httpbis-header-structure-07 (work in HTTP", draft-ietf-httpbis-header-structure-13 (work in
progress), July 2018. progress), August 2019.
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response [KEY] Fielding, R. and M. Nottingham, "The Key HTTP Response
Header Field", draft-ietf-httpbis-key-01 (work in Header Field", draft-ietf-httpbis-key-01 (work in
progress), March 2016. progress), March 2016.
[REPORTING] [REPORTING]
Grigorik, I. and M. West, "Reporting API 1", W3C Group Creager, D., Grigorik, I., Meyer, P., and M. West,
Note NOTE-reporting-1-20160607, June 2016, "Reporting API", W3C Working Draft WD-reporting-
<http://www.w3.org/TR/2016/NOTE-reporting-1-20160607/>. 1-20180925, September 2018,
<https://www.w3.org/TR/2018/WD-reporting-1-20180925/>.
Latest version available at <http://www.w3.org/TR/ Latest version available at <https://www.w3.org/TR/
reporting-1/>. reporting-1/>.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
DOI 10.17487/RFC6266, June 2011, DOI 10.17487/RFC6266, June 2011,
<https://www.rfc-editor.org/info/rfc6266>. <https://www.rfc-editor.org/info/rfc6266>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
skipping to change at page 11, line 22 skipping to change at page 11, line 22
{ "Attachment": { "filename" : "example.html" } } { "Attachment": { "filename" : "example.html" } }
The third example in Section 5 of [RFC6266] uses a filename parameter The third example in Section 5 of [RFC6266] uses a filename parameter
containing non-US-ASCII characters: containing non-US-ASCII characters:
attachment; filename*=UTF-8''%e2%82%ac%20rates attachment; filename*=UTF-8''%e2%82%ac%20rates
Note that in this case, the "filename*" parameter uses the encoding Note that in this case, the "filename*" parameter uses the encoding
defined in [RFC8187], representing a filename starting with the defined in [RFC8187], representing a filename starting with the
Unicode character U+20AC (EURO SIGN), followed by " rates". If the Unicode character "EUR" (EURO SIGN, U+20AC), followed by " rates".
definition of Content-Disposition would have used the format proposed If the definition of Content-Disposition would have used the format
here, the workaround involving the "parameter*" syntax would not have proposed here, the workaround involving the "parameter*" syntax would
been needed at all. not have been needed at all.
The JSON representation of this value could then be: The JSON representation of this value could then be:
{ "attachment": { "filename" : "\u20AC rates" } } { "attachment": { "filename" : "\u20AC rates" } }
A.3. WWW-Authenticate A.3. WWW-Authenticate
The WWW-Authenticate header field value is defined in Section 4.1 of The WWW-Authenticate header field value is defined in Section 4.1 of
[RFC7235] as a list of "challenges": [RFC7235] as a list of "challenges":
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Since work started on this document, various specifications have Since work started on this document, various specifications have
adopted this format. At least one of these moved away after the HTTP adopted this format. At least one of these moved away after the HTTP
Working Group decided to focus on [HSTRUCT] (see thread starting at Working Group decided to focus on [HSTRUCT] (see thread starting at
<https://lists.w3.org/Archives/Public/ietf-http- <https://lists.w3.org/Archives/Public/ietf-http-
wg/2016OctDec/0505.html>). wg/2016OctDec/0505.html>).
The sections below summarize the current usage of this format. The sections below summarize the current usage of this format.
B.1. W3C Reporting API Specification B.1. W3C Reporting API Specification
Defined in W3C Note "Reporting API 1" (Section 3.1 of [REPORTING]). Defined in W3C Working Draft "Reporting API" (Section 3.1 of
Still in use in latest editor copy as of June 2017. [REPORTING]). Still in use in latest working draft dated September
2018.
B.2. W3C Clear Site Data Specification B.2. W3C Clear Site Data Specification
Used in earlier versions of "Clear Site Data". The current version Used in earlier versions of "Clear Site Data". The current version
replaces the use of JSON with a custom syntax that happens to be replaces the use of JSON with a custom syntax that happens to be
somewhat compatible with an array of JSON strings (see Section 3.1 of somewhat compatible with an array of JSON strings (see Section 3.1 of
[CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http- [CLEARSITE] and <https://lists.w3.org/Archives/Public/ietf-http-
wg/2017AprJun/0214.html> for feedback). wg/2017AprJun/0214.html> for feedback).
B.3. W3C Feature Policy Specification B.3. W3C Feature Policy Specification
skipping to change at page 14, line 48 skipping to change at page 15, line 5
the benefits of having the same data model for both types of header the benefits of having the same data model for both types of header
fields would be gone. A hybrid approach might make sense, as long as fields would be gone. A hybrid approach might make sense, as long as
it doesn't require any heuristics on the recipient's side. it doesn't require any heuristics on the recipient's side.
Note: a concrete proposal was made by Kazuho Oku in Note: a concrete proposal was made by Kazuho Oku in
<https://lists.w3.org/Archives/Public/ietf-http- <https://lists.w3.org/Archives/Public/ietf-http-
wg/2016JanMar/0155.html>. wg/2016JanMar/0155.html>.
[[CREF1: Use of generic libs vs compactness of field values..]] [[CREF1: Use of generic libs vs compactness of field values..]]
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log
This section is to be removed before publishing as an RFC.
E.1. Since draft-reschke-http-jfv-00 E.1. Since draft-reschke-http-jfv-00
Editorial fixes + working on the TODOs. Editorial fixes + working on the TODOs.
E.2. Since draft-reschke-http-jfv-01 E.2. Since draft-reschke-http-jfv-01
Mention slightly increased risk of smuggling information in header Mention slightly increased risk of smuggling information in header
field values. field values.
E.3. Since draft-reschke-http-jfv-02 E.3. Since draft-reschke-http-jfv-02
skipping to change at page 16, line 31 skipping to change at page 16, line 37
Update JSON and HSTRUCT references. Update JSON and HSTRUCT references.
FEATUREPOL doesn't use JSON syntax anymore. FEATUREPOL doesn't use JSON syntax anymore.
E.12. Since draft-reschke-http-jfv-08 E.12. Since draft-reschke-http-jfv-08
Update HSTRUCT reference. Update HSTRUCT reference.
Update notes about CLEARSITE and FEATUREPOL. Update notes about CLEARSITE and FEATUREPOL.
E.13. Since draft-reschke-http-jfv-09
Update HSTRUCT and FEATUREPOL references.
Update note about REPORTING.
Changed category to "informational".
Acknowledgements 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
Muenster, NW 48155 Muenster 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 19 change blocks. 
26 lines changed or deleted 41 lines changed or added

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