One document matched: draft-reschke-http-cice-02.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-reschke-http-cice-02" category="std">

  

	<front>
  <title abbrev="HTTP CICE">Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>	
      <uri>http://greenbytes.de/tech/webdav/</uri>	
    </address>
  </author>

  <date year="2015" month="March" day="9"/>
  
  <area>Applications</area>
  <keyword>HTTP</keyword>
  <keyword>content-encoding</keyword>

  <abstract>
    <t>
      In HTTP, "Content Codings" allow for payload encodings such as for
      compression or integrity checks. In particular, the "gzip" content
      coding is widely used for payload data sent in response messages.
    </t>
    <t>
      Content Codings can be used in request messages as well, however
      discoverability is not on par with response messages. This document
      extends the HTTP "Accept-Encoding" header field for use in responses.
    </t>
  </abstract>
  

  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPbis Working Group, comments should be sent to the 
      Hypertext Transfer Protocol (HTTP) mailing list at <eref target="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</eref>,
      which may be joined by sending a message with subject 
      "subscribe" to <eref target="mailto:ietf-http-wg-request@w3.org?subject=subscribe">ietf-http-wg-request@w3.org</eref>.
    </t>
    <t>
      Discussions of the HTTPbis Working Group are archived at
      <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.               
    </t> 
    <t>
      XML versions and latest edits for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-http-cice"/>.
    </t>
    <t>
      The changes in this draft are summarized in <xref target="changes.since.01"/>.
    </t>
  </note>


  </front>

  <middle>

<section anchor="introduction" title="Introduction">
    <t>
      In HTTP, "Content Codings" allow for payload encodings such as for
      compression or integrity checks (<xref target="RFC7231"/>, Section 3.1.2). In particular, the "gzip" content
      coding is widely used for payload data sent in response messages.
    </t>
    <t>
      Content Codings can be used in request messages as well, however
      discoverability is not on par with response messages. This document
      extends the HTTP "Accept-Encoding" header field (<xref target="RFC7231"/>, Section 5.3.4) for use in responses.
    </t>
</section>  

<section anchor="notational.conventions" title="Notational Conventions">
<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
   This document reuses terminology used in the base HTTP specifications,
   namely Section 2 of <xref target="RFC7230"/> and
   Section 3.1.2 of <xref target="RFC7231"/>.
</t>
</section>

<section anchor="accept-encoding" title="Extensions to 'Accept-Encoding' Header Field">
<t>
  Section 5.3.4 of <xref target="RFC7231"/> defines
  "Accept-Encoding" as a request header field only.
</t>
<t>
  This specification extends that definition to allow "Accept-Encoding"
  as a response header field as well.  When present, it indicates what
  content codings a resource was willing to accept at the time of the
  response.
  A field value that only contains "identity" implies that no 
  content codings are supported.
</t>
<t>
  Note that this information is specific to the specific request. The
  set of supported encodings might be different for other resources on the 
  same server, could also change depending on other aspects of the 
  request (such as the request method), or might change in the future.
</t>
<t>
  Section 6.5.13 of <xref target="RFC7231"/> defines status code
  415 (Unsupported Media Type) to apply to both media type and content coding
  related problems.
</t>
<t>
  Servers that fail a request due to an unsupported content coding SHOULD
  respond with a 415 status and SHOULD include an "Accept-Encoding" header field in
  that response, allowing clients to distinguish between content coding
  related issues and media type related issues. In order
  to avoid confusion with media type related problems, servers that fail a request
  with a 415 status for reasons unrelated to content codings SHOULD NOT
  include the "Accept-Encoding" header field.
</t>
<t>
  While sending "Accept-Encoding" in a 415 (Unsupported Media Type) response will be the most common use case,
  it is not restricted to this particular status code. For instance, a server
  might include it in a 2xx response when a request payload was
  big enough to justity use of a compression coding, but the client failed to do so.
</t>
</section>

<section anchor="example" title="Example">
<t>
  Client submits a POST request using Content-Encoding "compress"
  (<xref target="RFC7231"/>, Section 3.1.2.1):
</t>
<figure><artwork type="message/http; msgtype="request""><![CDATA[
  POST /edit/ HTTP/1.1
  Host: example.org
  Content-Type: application/atom+xml;type=entry
  Content-Encoding: compress
  
  ...compressed payload...
  ]]></artwork></figure>
<t>
  Server rejects request because it only allows the "gzip" content coding:
</t>
<figure><artwork type="message/http; msgtype="response""><![CDATA[
  HTTP/1.1 415 Unsupported Media Type
  Date: Fri, 09 May 2014 11:43:53 GMT
  Accept-Encoding: gzip
  Content-Length: 68
  Content-Type: text/plain
  
  This resource only supports the "gzip" content coding in requests.
  ]]></artwork></figure>
<t>
  ...at which point the client can retry the request with the supported
  "gzip" content coding.
</t>
<t>
  Alternatively, a server that does not support any content codings in
  requests could answer with:
</t>
<figure><artwork type="message/http; msgtype="response""><![CDATA[
  HTTP/1.1 415 Unsupported Media Type
  Date: Fri, 09 May 2014 11:43:53 GMT
  Accept-Encoding: identity
  Content-Length: 61
  Content-Type: text/plain
  
  This resource does not support content codings in requests.
  ]]></artwork></figure>
</section>

<section anchor="deployment.considerations" title="Deployment Considerations">
<t>
  Servers that do not support content codings in requests already are required
  to fail a request that does use a content coding. Section 6.5.13 of <xref target="RFC7231"/>
  recommends to use the status code 415 (Unsupported Media Type), so the only
  change needed is to include the "Accept-Encoding" header field with value
  "identity" in that response.
</t>
<t>
  Servers that do support some content codings are required to fail requests
  with unsupported content codings as well. To be compliant with this specification,
  servers will need to use the status code 415 (Unsupported Media Type) to
  signal the problem, and will have to include an "Accept-Encoding" header field
  that enumerates the content codings that are supported. As the set of
  supported content codings usually is
  static and small, adding the header field ought to be trivial.
</t>
</section>

<section anchor="security.considerations" title="Security Considerations">
<t>
  This specification does not introduce any new security considerations
  beyond those discussed in Section 9 of <xref target="RFC7231"/>.
</t>
</section>

<section anchor="iana.considerations" title="IANA Considerations">
<t>
   HTTP header fields are registered within the "Message Headers" registry
   located at <eref target="http://www.iana.org/assignments/message-headers"/>,
   as defined by <xref target="BCP90"/>.
</t>
<t>
   This document updates the definition of the "Accept-Encoding" header field,
   so the "Permanent Message Header Field Names" registry shall be updated
   accordingly:
</t>
<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
   <ttcol>Header Field Name</ttcol>
   <ttcol>Protocol</ttcol>
   <ttcol>Status</ttcol>
   <ttcol>Reference</ttcol>

   <c>Accept-Encoding</c>
   <c>http</c>
   <c>standard</c>
   <c>
      <xref target="RFC7231"/>, Section 5.3.4,
      extended by  <xref target="accept-encoding"/> of this document
   </c>
</texttable>
</section>

<section title="Acknowledgements">
<t>
  Thanks go to the members of the and HTTPbis Working Group, namely
  Amos Jeffries, Mark Nottingham, and Ted Hardie. 
</t>
</section>

  </middle>
  <back>
  
<references title="Normative References">

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner">
      <organization>Harvard University</organization>
      <address><email>sob@harvard.edu</email></address>
    </author>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>

<reference anchor="RFC7230">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7230"/>
  
</reference>

<reference anchor="RFC7231">
  <front>
    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="June" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="7231"/>
  
</reference>

</references>

<references title="Informative References">
<reference anchor="BCP90">
  <front>
    <title>Registration Procedures for Message Header Fields</title>
    <author initials="G." surname="Klyne" fullname="G. Klyne">
      <organization>Nine by Nine</organization>
      <address><email>GK-IETF@ninebynine.org</email></address>
    </author>
    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
      <organization>BEA Systems</organization>
      <address><email>mnot@pobox.com</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="J. Mogul">
      <organization>HP Labs</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <date year="2004" month="September"/>
  </front>
  <seriesInfo name="BCP" value="90"/>
  <seriesInfo name="RFC" value="3864"/>
</reference>
</references>

<section anchor="change.log" title="Change Log (to be removed by RFC Editor before publication)">

<section anchor="changes.since.00" title="draft-reschke-http-cice-00">
<t>
  Clarified that the information returned in Accept-Encoding is per resource, not per server.
</t>
<t>
  Added some deployment considerations.
</t>
<t>
  Updated HTTP/1.1 references.
</t>
</section>

<section anchor="changes.since.01" title="draft-reschke-http-cice-01">
<t>
  Restrict the scope of A-E from "future requests" to "at the time of this request".
</t>
<t>
  Mention use of A-E in responses other than 415.
</t>
<t>
  Recommend not to include A-E in a 415 response unless there was actually a problem related to content coding.
</t>
</section>
</section>
  </back>

</rfc>