draft-reschke-http-cice-02.txt | draft-reschke-http-cice-latest.txt | |||
---|---|---|---|---|
Network Working Group J. Reschke | Network Working Group J. Reschke | |||
Internet-Draft greenbytes | Internet-Draft greenbytes | |||
Intended status: Standards Track March 9, 2015 | Intended status: Standards Track April 11, 2024 | |||
Expires: September 10, 2015 | Expires: October 13, 2024 | |||
Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding | Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding | |||
draft-reschke-http-cice-02 | draft-reschke-http-cice-latest | |||
Abstract | Abstract | |||
In HTTP, "Content Codings" allow for payload encodings such as for | In HTTP, "Content Codings" allow for payload encodings such as for | |||
compression or integrity checks. In particular, the "gzip" content | compression or integrity checks. In particular, the "gzip" content | |||
coding is widely used for payload data sent in response messages. | coding is widely used for payload data sent in response messages. | |||
Content Codings can be used in request messages as well, however | Content Codings can be used in request messages as well, however | |||
discoverability is not on par with response messages. This document | discoverability is not on par with response messages. This document | |||
extends the HTTP "Accept-Encoding" header field for use in responses. | extends the HTTP "Accept-Encoding" header field for use in responses. | |||
Editorial Note (To be removed by RFC Editor before publication) | Editorial Note (To be removed by RFC Editor before publication) | |||
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 | the Hypertext Transfer Protocol (HTTP) mailing list at ietf-http- | |||
ietf-http-wg@w3.org [1], which may be joined by sending a message | wg@w3.org [1], which may be joined by sending a message with subject | |||
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-cice>. | <http://greenbytes.de/tech/webdav/#draft-reschke-http-cice>. | |||
The changes in this draft are summarized in Appendix A.2. | The changes in this draft are summarized in Appendix A.3. | |||
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 http://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 September 10, 2015. | This Internet-Draft will expire on October 13, 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2024 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 | (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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 | 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 | |||
3. Extensions to 'Accept-Encoding' Header Field . . . . . . . . . 3 | 3. Extensions to 'Accept-Encoding' Header Field . . . . . . . . 3 | |||
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 | 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 6 | 9.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
Appendix A. Change Log (to be removed by RFC Editor before | Appendix A. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . . 6 | publication) . . . . . . . . . . . . . . . . . . . . 7 | |||
A.1. draft-reschke-http-cice-00 . . . . . . . . . . . . . . . . 6 | A.1. draft-reschke-http-cice-00 . . . . . . . . . . . . . . . 7 | |||
A.2. draft-reschke-http-cice-01 . . . . . . . . . . . . . . . . 6 | A.2. draft-reschke-http-cice-01 . . . . . . . . . . . . . . . 7 | |||
A.3. draft-reschke-http-cice-02 . . . . . . . . . . . . . . . 7 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
1. Introduction | 1. Introduction | |||
In HTTP, "Content Codings" allow for payload encodings such as for | In HTTP, "Content Codings" allow for payload encodings such as for | |||
compression or integrity checks ([RFC7231], Section 3.1.2). In | compression or integrity checks ([RFC7231], Section 3.1.2). In | |||
particular, the "gzip" content coding is widely used for payload data | particular, the "gzip" content coding is widely used for payload data | |||
sent in response messages. | sent in response messages. | |||
Content Codings can be used in request messages as well, however | Content Codings can be used in request messages as well, however | |||
discoverability is not on par with response messages. This document | discoverability is not on par with response messages. This document | |||
extends the HTTP "Accept-Encoding" header field ([RFC7231], Section | extends the HTTP "Accept-Encoding" header field ([RFC7231], | |||
5.3.4) for use in responses. | Section 5.3.4) for use in responses. | |||
2. Notational Conventions | 2. Notational Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
This document reuses terminology used in the base HTTP | This document reuses terminology used in the base HTTP | |||
specifications, namely Section 2 of [RFC7230] and Section 3.1.2 of | specifications, namely Section 2 of [RFC7230] and Section 3.1.2 of | |||
[RFC7231]. | [RFC7231]. | |||
skipping to change at page 4, line 10 ¶ | skipping to change at page 4, line 4 ¶ | |||
Encoding" header field in that response, allowing clients to | Encoding" header field in that response, allowing clients to | |||
distinguish between content coding related issues and media type | distinguish between content coding related issues and media type | |||
related issues. In order to avoid confusion with media type related | related issues. In order to avoid confusion with media type related | |||
problems, servers that fail a request with a 415 status for reasons | problems, servers that fail a request with a 415 status for reasons | |||
unrelated to content codings SHOULD NOT include the "Accept-Encoding" | unrelated to content codings SHOULD NOT include the "Accept-Encoding" | |||
header field. | header field. | |||
While sending "Accept-Encoding" in a 415 (Unsupported Media Type) | While sending "Accept-Encoding" in a 415 (Unsupported Media Type) | |||
response will be the most common use case, it is not restricted to | response will be the most common use case, it is not restricted to | |||
this particular status code. For instance, a server might include it | this particular status code. For instance, a server might include it | |||
in a 2xx response when a request payload was big enough to justity | in a 2xx response when a request payload was big enough to justify | |||
use of a compression coding, but the client failed to do so. | use of a compression coding, but the client failed to do so. | |||
4. Example | 4. Example | |||
Client submits a POST request using Content-Encoding "compress" | Client submits a POST request using Content-Encoding "compress" | |||
([RFC7231], Section 3.1.2.1): | ([RFC7231], Section 3.1.2.1): | |||
POST /edit/ HTTP/1.1 | POST /edit/ HTTP/1.1 | |||
Host: example.org | Host: example.org | |||
Content-Type: application/atom+xml;type=entry | Content-Type: application/atom+xml;type=entry | |||
skipping to change at page 5, line 8 ¶ | skipping to change at page 4, line 47 ¶ | |||
Date: Fri, 09 May 2014 11:43:53 GMT | Date: Fri, 09 May 2014 11:43:53 GMT | |||
Accept-Encoding: identity | Accept-Encoding: identity | |||
Content-Length: 61 | Content-Length: 61 | |||
Content-Type: text/plain | Content-Type: text/plain | |||
This resource does not support content codings in requests. | This resource does not support content codings in requests. | |||
5. Deployment Considerations | 5. Deployment Considerations | |||
Servers that do not support content codings in requests already are | Servers that do not support content codings in requests already are | |||
required to fail a request that does use a content coding. Section | required to fail a request that does use a content coding. | |||
6.5.13 of [RFC7231] recommends to use the status code 415 | Section 6.5.13 of [RFC7231] recommends to use the status code 415 | |||
(Unsupported Media Type), so the only change needed is to include the | (Unsupported Media Type), so the only change needed is to include the | |||
"Accept-Encoding" header field with value "identity" in that | "Accept-Encoding" header field with value "identity" in that | |||
response. | response. | |||
Servers that do support some content codings are required to fail | Servers that do support some content codings are required to fail | |||
requests with unsupported content codings as well. To be compliant | requests with unsupported content codings as well. To be compliant | |||
with this specification, servers will need to use the status code 415 | with this specification, servers will need to use the status code 415 | |||
(Unsupported Media Type) to signal the problem, and will have to | (Unsupported Media Type) to signal the problem, and will have to | |||
include an "Accept-Encoding" header field that enumerates the content | include an "Accept-Encoding" header field that enumerates the content | |||
codings that are supported. As the set of supported content codings | codings that are supported. As the set of supported content codings | |||
skipping to change at page 5, line 31 ¶ | skipping to change at page 5, line 22 ¶ | |||
trivial. | trivial. | |||
6. Security Considerations | 6. Security Considerations | |||
This specification does not introduce any new security considerations | This specification does not introduce any new security considerations | |||
beyond those discussed in Section 9 of [RFC7231]. | beyond those discussed in Section 9 of [RFC7231]. | |||
7. IANA Considerations | 7. IANA Considerations | |||
HTTP header fields are registered within the "Message Headers" | HTTP header fields are registered within the "Message Headers" | |||
registry located at | registry located at <http://www.iana.org/assignments/message- | |||
<http://www.iana.org/assignments/message-headers>, as defined by | headers>, as defined by [BCP90]. | |||
[BCP90]. | ||||
This document updates the definition of the "Accept-Encoding" header | This document updates the definition of the "Accept-Encoding" header | |||
field, so the "Permanent Message Header Field Names" registry shall | field, so the "Permanent Message Header Field Names" registry shall | |||
be updated accordingly: | be updated accordingly: | |||
+-----------------+----------+----------+---------------------------+ | +-----------------+----------+----------+---------------------------+ | |||
| Header Field | Protocol | Status | Reference | | | Header Field | Protocol | Status | Reference | | |||
| Name | | | | | | Name | | | | | |||
+-----------------+----------+----------+---------------------------+ | +-----------------+----------+----------+---------------------------+ | |||
| Accept-Encoding | http | standard | [RFC7231], Section 5.3.4, | | | Accept-Encoding | http | standard | [RFC7231], Section 5.3.4, | | |||
| | | | extended by Section 3 of | | | | | | extended by Section 3 of | | |||
| | | | this document | | | | | | this document | | |||
+-----------------+----------+----------+---------------------------+ | +-----------------+----------+----------+---------------------------+ | |||
8. Acknowledgements | 8. Acknowledgements | |||
Thanks go to the members of the and HTTPbis Working Group, namely | Thanks go to the members of the and HTTPbis Working Group, namely | |||
Amos Jeffries, Mark Nottingham, and Ted Hardie. | Amos Jeffries, Mark Nottingham, and Ted Hardie. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997, | Requirement Levels", BCP 14, RFC 2119, | |||
<http://www.rfc-editor.org/info/rfc2119>. | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
RFC 7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7230>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, | |||
June 2014, <http://www.rfc-editor.org/info/rfc7231>. | DOI 10.17487/RFC7231, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7231>. | ||||
9.2. Informative References | 9.2. Informative References | |||
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004, <http://www.rfc-editor.org/info/bcp90>. | September 2004, <https://www.rfc-editor.org/info/bcp90>. | |||
URIs | 9.3. URIs | |||
[1] <mailto:ietf-http-wg@w3.org> | [1] mailto:ietf-http-wg@w3.org | |||
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | [2] mailto:ietf-http-wg-request@w3.org?subject=subscribe | |||
Appendix A. Change Log (to be removed by RFC Editor before publication) | Appendix A. Change Log (to be removed by RFC Editor before publication) | |||
A.1. draft-reschke-http-cice-00 | A.1. draft-reschke-http-cice-00 | |||
Clarified that the information returned in Accept-Encoding is per | Clarified that the information returned in Accept-Encoding is per | |||
resource, not per server. | resource, not per server. | |||
Added some deployment considerations. | Added some deployment considerations. | |||
skipping to change at page 7, line 6 ¶ | skipping to change at page 7, line 26 ¶ | |||
A.2. draft-reschke-http-cice-01 | A.2. draft-reschke-http-cice-01 | |||
Restrict the scope of A-E from "future requests" to "at the time of | Restrict the scope of A-E from "future requests" to "at the time of | |||
this request". | this request". | |||
Mention use of A-E in responses other than 415. | Mention use of A-E in responses other than 415. | |||
Recommend not to include A-E in a 415 response unless there was | Recommend not to include A-E in a 415 response unless there was | |||
actually a problem related to content coding. | actually a problem related to content coding. | |||
A.3. draft-reschke-http-cice-02 | ||||
None yet. | ||||
Author's Address | Author's Address | |||
Julian F. Reschke | Julian F. Reschke | |||
greenbytes GmbH | greenbytes GmbH | |||
Hafenweg 16 | Hafenweg 16 | |||
Muenster, NW 48155 | Muenster, NW 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. 23 change blocks. | ||||
43 lines changed or deleted | 51 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |