One document matched: draft-reschke-http-cice-00.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-00" 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="2014" month="May" day="10"/>
  
  <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, latest edits, and the issues list for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-http-cice"/>.
    </t>
  </note>


  </front>

  <middle>




<section title="Introduction" anchor="introduction">
    <t>
      In HTTP, "Content Codings" allow for payload encodings such as for
      compression or integrity checks (<xref target="HTTPSEM"/>, 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="HTTPSEM"/>, Section 5.3.4) for use in responses.
    </t>
</section>  

<section title="Notational Conventions" anchor="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="HTTPMSG"/> and
   Section 3.1.2 of <xref target="HTTPSEM"/>.
</t>
</section>

<section title="Extensions to 'Accept-Encoding' Header Field" anchor="accept-encoding">
<t>
  Section 5.3.4 of <xref target="HTTPSEM"/> defines
  "Accept-Encoding" as a request header field only.
</t>
<t>
  This specification extends that definition to allow "Accept-Encoding" as
  response header field as well. When present, it indicates what content codings
  a server is willing to accept in requests. In particular, a field value
  that contains "identity" only implies that no content codings are supported
  at all.
</t>
<t>
  Note that this information applies to the resource to which the request
  was addressed. The set of supported encodings might vary for different 
  resources on the same server, and could also vary depending on other
  aspects of the request (such as the request method).
</t>
<t>
  Section 6.5.13 of <xref target="HTTPSEM"/> 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 in
  that response, allowing clients to distinguish between content coding
  related issues and media type related issues.
</t>
</section>

<section title="Example" anchor="example">
<t>
  Client submits a POST request using Content-Encoding "compress"
  (<xref target="HTTPSEM"/>, 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 title="Security Considerations" anchor="security.considerations">
<t>
  This specification does not introduce any new security considerations
  beyond those discussed in Section 9 of <xref target="HTTPSEM"/>.
</t>
</section>

<section title="IANA Considerations" anchor="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="HTTPSEM"/>, Section 5.3.4,
      extended by  <xref target="accept-encoding"/> of this document
   </c>
</texttable>
</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="HTTPMSG">
  <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="February" year="2014"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-26"/>
  
</reference>

<reference anchor="HTTPSEM">
  <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="February" year="2014"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-26"/>
  
</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 title="Open issues (to be removed by RFC Editor prior to publication)"><section title="edit"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2011-04-15): 
    Umbrella issue for editorial fixes/enhancements.
  </t></section></section></back>

</rfc>