Changeset 2725


Ignore:
Timestamp:
Jun 6, 2014, 12:19:46 PM (6 years ago)
Author:
julian.reschke@…
Message:

remove editorial notes (#553)

Location:
specs
Files:
16 edited

Legend:

Unmodified
Added
Removed
  • specs/rfc7230.html

    r2722 r2725  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Architecture" href="#rfc.section.2"><link rel="Chapter" title="3 Message Format" href="#rfc.section.3"><link rel="Chapter" title="4 Transfer Codings" href="#rfc.section.4"><link rel="Chapter" title="5 Message Routing" href="#rfc.section.5"><link rel="Chapter" title="6 Connection Management" href="#rfc.section.6"><link rel="Chapter" title="7 ABNF List Extension: #rule" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A HTTP Version History" href="#rfc.section.A"><link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"><link href="rfc7231.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7230.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7230"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7230"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP message format"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7230"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2145"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations."></head><body onload="getMeta(7230,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7230</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2145">2145</a>, <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a>, <a href="https://tools.ietf.org/html/rfc2818">2818</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements Notation</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li><li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li><li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul><li><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI Scheme</a></li><li><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI Scheme</a></li><li><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li></ul></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#http.message">Message Format</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#start.line">Start Line</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.line">Request Line</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.line">Status Line</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul><li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#field.extensibility">Field Extensibility</a></li><li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.order">Field Order</a></li><li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li><li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li><li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#field.limits">Field Limits</a></li><li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field Value Components</a></li></ul></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a><ul><li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li><li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li><li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body.length">Message Body Length</a></li></ul></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a><ul><li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.extension">Chunk Extensions</a></li><li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.trailer.part">Chunked Trailer Part</a></li><li><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#decoding.chunked">Decoding Chunked</a></li></ul></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#target-resource">Identifying a Target Resource</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#origin-form">origin-form</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#absolute-form">absolute-form</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#authority-form">authority-form</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#asterisk-form">asterisk-form</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li><li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li><li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul><li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li><li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformations">Transformations</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Timeouts</a></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li><li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#abnf.extension">ABNF List Extension: #rule</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Registration</a></li></ul></li><li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registration</a></li><li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a><ul><li><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#establishing.authority">Establishing Authority</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.splitting">Response Splitting</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.smuggling">Request Smuggling</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></li><li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul><li><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multihomed.web.servers.and.conserve.ip.addresses">Multihomed Web Servers</a></li><li><a href="#rfc.section.A.1.2">A.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li><li><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li></ul></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document is the first in a series of documents that collectively form the HTTP/1.1 specification: </p><ol><li>"Message Syntax and Routing" (this document)</li><li>"Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a></li><li>"Conditional Requests" <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></li><li>"Range Requests" <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li><li>"Caching" <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></li><li>"Authentication" <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></li></ol><p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>.</p><p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.</p><p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.</p><p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.</p><p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.</p><div id="intro.requirements"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#intro.requirements">Requirements Notation</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.</p></div><div id="notation"><div id="rfc.iref.g.1"></div><div id="rfc.iref.g.2"></div><div id="rfc.iref.g.3"></div><div id="rfc.iref.g.4"></div><div id="rfc.iref.g.5"></div><div id="rfc.iref.g.6"></div><div id="rfc.iref.g.7"></div><div id="rfc.iref.g.8"></div><div id="rfc.iref.g.9"></div><div id="rfc.iref.g.10"></div><div id="rfc.iref.g.11"></div><div id="rfc.iref.g.12"></div><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="#abnf.extension" title="ABNF List Extension: #rule">Section&nbsp;7</a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="core.rules"><p id="rfc.section.1.2.p.2">            The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character).</p></div><p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p></div></div><div id="architecture"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1><p id="rfc.section.2.p.1">HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.</p><div id="operation"><div id="rfc.iref.c.1"></div><div id="rfc.iref.s.1"></div><div id="rfc.iref.c.2"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#operation">Client/Server Messaging</a></h2><p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) across a reliable transport- or session-layer "<dfn>connection</dfn>" (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>). An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.</p><div id="rfc.iref.u.1"></div><div id="rfc.iref.o.1"></div><div id="rfc.iref.b.1"></div><div id="rfc.iref.s.2"></div><div id="rfc.iref.s.3"></div><div id="rfc.iref.r.1"></div><p id="rfc.section.2.1.p.2">The terms "client" and "server" refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others. The term "<dfn>user agent</dfn>" refers to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.</p><p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="rfc7231.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for the differences between HTTP and MIME messages).</p><p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).</p><div id="rfc.figure.u.1"></div><pre class="drawing">         request   &gt;
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Architecture" href="#rfc.section.2"><link rel="Chapter" title="3 Message Format" href="#rfc.section.3"><link rel="Chapter" title="4 Transfer Codings" href="#rfc.section.4"><link rel="Chapter" title="5 Message Routing" href="#rfc.section.5"><link rel="Chapter" title="6 Connection Management" href="#rfc.section.6"><link rel="Chapter" title="7 ABNF List Extension: #rule" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A HTTP Version History" href="#rfc.section.A"><link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"><link href="rfc7231.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7230.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7230"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7230"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP message format"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7230"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2145"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations."></head><body onload="getMeta(7230,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7230</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2145">2145</a>, <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a>, <a href="https://tools.ietf.org/html/rfc2818">2818</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements Notation</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#architecture">Architecture</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#operation">Client/Server Messaging</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#implementation-diversity">Implementation Diversity</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#intermediaries">Intermediaries</a></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#caches">Caches</a></li><li><a href="#rfc.section.2.5">2.5</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.2.6">2.6</a>&nbsp;&nbsp;&nbsp;<a href="#http.version">Protocol Versioning</a></li><li><a href="#rfc.section.2.7">2.7</a>&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul><li><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI Scheme</a></li><li><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#https.uri">https URI Scheme</a></li><li><a href="#rfc.section.2.7.3">2.7.3</a>&nbsp;&nbsp;&nbsp;<a href="#uri.comparison">http and https URI Normalization and Comparison</a></li></ul></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#http.message">Message Format</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#start.line">Start Line</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.line">Request Line</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.line">Status Line</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul><li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#field.extensibility">Field Extensibility</a></li><li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.order">Field Order</a></li><li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li><li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li><li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#field.limits">Field Limits</a></li><li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field Value Components</a></li></ul></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a><ul><li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></li><li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-length">Content-Length</a></li><li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#message.body.length">Message Body Length</a></li></ul></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Handling Incomplete Messages</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#message.robustness">Message Parsing Robustness</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.codings">Transfer Codings</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.encoding">Chunked Transfer Coding</a><ul><li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.extension">Chunk Extensions</a></li><li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#chunked.trailer.part">Chunked Trailer Part</a></li><li><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#decoding.chunked">Decoding Chunked</a></li></ul></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#compression.codings">Compression Codings</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#compress.coding">Compress Coding</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#deflate.coding">Deflate Coding</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#gzip.coding">Gzip Coding</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#message.routing">Message Routing</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#target-resource">Identifying a Target Resource</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#connecting.inbound">Connecting Inbound</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request-target">Request Target</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#origin-form">origin-form</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#absolute-form">absolute-form</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#authority-form">authority-form</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#asterisk-form">asterisk-form</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li><li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#associating.response.to.request">Associating a Response to a Request</a></li><li><a href="#rfc.section.5.7">5.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul><li><a href="#rfc.section.5.7.1">5.7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.via">Via</a></li><li><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;&nbsp;&nbsp;<a href="#message.transformations">Transformations</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#connection.management">Connection Management</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.connection">Connection</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.concurrency">Concurrency</a></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.failures">Failures and Timeouts</a></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.tear-down">Tear-down</a></li><li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#abnf.extension">ABNF List Extension: #rule</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#uri.scheme.registration">URI Scheme Registration</a></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.message.http">Internet Media Type message/http</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.application.http">Internet Media Type application/http</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Registration</a></li></ul></li><li><a href="#rfc.section.8.5">8.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registration</a></li><li><a href="#rfc.section.8.6">8.6</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a><ul><li><a href="#rfc.section.8.6.1">8.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.6.2">8.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#establishing.authority">Establishing Authority</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#risks.intermediaries">Risks of Intermediaries</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#attack.protocol.element.length">Attacks via Protocol Element Length</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.splitting">Response Splitting</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.smuggling">Request Smuggling</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.integrity">Message Integrity</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#message.confidentiality">Message Confidentiality</a></li><li><a href="#rfc.section.9.8">9.8</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.of.server.log.information">Privacy of Server Log Information</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul><li><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multihomed.web.servers.and.conserve.ip.addresses">Multihomed Web Servers</a></li><li><a href="#rfc.section.A.1.2">A.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li><li><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li></ul></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems. This document is the first in a series of documents that collectively form the HTTP/1.1 specification: </p><ol><li>"Message Syntax and Routing" (this document)</li><li>"Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a></li><li>"Conditional Requests" <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></li><li>"Range Requests" <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li><li>"Caching" <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></li><li>"Authentication" <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></li></ol><p id="rfc.section.1.p.2">This HTTP/1.1 specification obsoletes <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> and <cite title="Use and Interpretation of HTTP Version Numbers" id="rfc.xref.RFC2145.1">RFC 2145</cite> (on HTTP versioning). This specification also updates the use of CONNECT to establish a tunnel, previously defined in <cite title="Upgrading to TLS Within HTTP/1.1" id="rfc.xref.RFC2817.1">RFC 2817</cite>, and defines the "https" URI scheme that was described informally in <cite title="HTTP Over TLS" id="rfc.xref.RFC2818.1">RFC 2818</cite>.</p><p id="rfc.section.1.p.3">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.</p><p id="rfc.section.1.p.4">HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.</p><p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.</p><p id="rfc.section.1.p.6">This document describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes, describes overall network operation and connection management, and defines HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.</p><div id="intro.requirements"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#intro.requirements">Requirements Notation</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.</p></div><div id="notation"><div id="rfc.iref.g.1"></div><div id="rfc.iref.g.2"></div><div id="rfc.iref.g.3"></div><div id="rfc.iref.g.4"></div><div id="rfc.iref.g.5"></div><div id="rfc.iref.g.6"></div><div id="rfc.iref.g.7"></div><div id="rfc.iref.g.8"></div><div id="rfc.iref.g.9"></div><div id="rfc.iref.g.10"></div><div id="rfc.iref.g.11"></div><div id="rfc.iref.g.12"></div><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="#abnf.extension" title="ABNF List Extension: #rule">Section&nbsp;7</a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="core.rules"><p id="rfc.section.1.2.p.2">            The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character).</p></div><p id="rfc.section.1.2.p.3">As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.</p></div></div><div id="architecture"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1><p id="rfc.section.2.p.1">HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used to define HTTP.</p><div id="operation"><div id="rfc.iref.c.1"></div><div id="rfc.iref.s.1"></div><div id="rfc.iref.c.2"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#operation">Client/Server Messaging</a></h2><p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging <dfn>messages</dfn> (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) across a reliable transport- or session-layer "<dfn>connection</dfn>" (<a href="#connection.management" title="Connection Management">Section&nbsp;6</a>). An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.</p><div id="rfc.iref.u.1"></div><div id="rfc.iref.o.1"></div><div id="rfc.iref.b.1"></div><div id="rfc.iref.s.2"></div><div id="rfc.iref.s.3"></div><div id="rfc.iref.r.1"></div><p id="rfc.section.2.1.p.2">The terms "client" and "server" refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others. The term "<dfn>user agent</dfn>" refers to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.</p><p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="rfc7231.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> for the differences between HTTP and MIME messages).</p><p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).</p><div id="rfc.figure.u.1"></div><pre class="drawing">         request   &gt;
    505505    <b>UA</b> ======================================= <b>O</b>
    506506                                &lt;   response
  • specs/rfc7230.xml

    r2722 r2725  
    132132</t>   
    133133</abstract>
    134 
    135 <note title="Editorial Note (To be removed by RFC Editor)">
    136   <t>
    137     Discussion of this draft takes place on the HTTPBIS working group
    138     mailing list (ietf-http-wg@w3.org), which is archived at
    139     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    140   </t>
    141   <t>
    142     The current issues list is at
    143     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    144     documents (including fancy diffs) can be found at
    145     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    146   </t>
    147   <t>
    148     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    149   </t>
    150 </note>
    151134</front>
    152135<middle>
  • specs/rfc7231.html

    r2722 r2725  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Resources" href="#rfc.section.2"><link rel="Chapter" title="3 Representations" href="#rfc.section.3"><link rel="Chapter" title="4 Request Methods" href="#rfc.section.4"><link rel="Chapter" title="5 Request Header Fields" href="#rfc.section.5"><link rel="Chapter" title="6 Response Status Codes" href="#rfc.section.6"><link rel="Chapter" title="7 Response Header Fields" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7230.html" rel="prev"><link href="rfc7232.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7231.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7231"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7231"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7231"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."></head><body onload="getMeta(7231,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7231</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resources">Resources</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representations">Representations</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.metadata">Representation Metadata</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing Representation Data</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#data.encoding">Encoding for Compression or Integrity</a></li><li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#audience.language">Audience Language</a></li><li><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#identification">Identification</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Payload Semantics</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul><li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li><li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li></ul></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#methods">Request Methods</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.overview">Overview</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.properties">Common Method Properties</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li><li><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li><li><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li><li><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li></ul></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#request.header.fields">Request Header Fields</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#request.conditionals">Conditionals</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request.conneg">Content Negotiation</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li><li><a href="#rfc.section.5.3.5">5.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#request.auth">Authentication Credentials</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.context">Request Context</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#status.codes">Response Status Codes</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.1xx">Informational 1xx</a><ul><li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.100">100 Continue</a></li><li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.101">101 Switching Protocols</a></li></ul></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.2xx">Successful 2xx</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.200">200 OK</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.201">201 Created</a></li><li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.202">202 Accepted</a></li><li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></li><li><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.204">204 No Content</a></li><li><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.205">205 Reset Content</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.3xx">Redirection 3xx</a><ul><li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.300">300 Multiple Choices</a></li><li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.301">301 Moved Permanently</a></li><li><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.302">302 Found</a></li><li><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.303">303 See Other</a></li><li><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.305">305 Use Proxy</a></li><li><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.306">306 (Unused)</a></li><li><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.307">307 Temporary Redirect</a></li></ul></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.4xx">Client Error 4xx</a><ul><li><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.400">400 Bad Request</a></li><li><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.402">402 Payment Required</a></li><li><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.403">403 Forbidden</a></li><li><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.404">404 Not Found</a></li><li><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.405">405 Method Not Allowed</a></li><li><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.406">406 Not Acceptable</a></li><li><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.408">408 Request Timeout</a></li><li><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#status.409">409 Conflict</a></li><li><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;&nbsp;&nbsp;<a href="#status.410">410 Gone</a></li><li><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;&nbsp;&nbsp;<a href="#status.411">411 Length Required</a></li><li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Payload Too Large</a></li><li><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li><li><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li><li><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;&nbsp;&nbsp;<a href="#status.417">417 Expectation Failed</a></li><li><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;&nbsp;&nbsp;<a href="#status.426">426 Upgrade Required</a></li></ul></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.5xx">Server Error 5xx</a><ul><li><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.500">500 Internal Server Error</a></li><li><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.501">501 Not Implemented</a></li><li><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.502">502 Bad Gateway</a></li><li><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.503">503 Service Unavailable</a></li><li><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.504">504 Gateway Timeout</a></li><li><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#response.control.data">Control Data</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#origination.date">Origination Date</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li><li><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#response.validator">Validator Header Fields</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#response.auth">Authentication Challenges</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.context">Response Context</a><ul><li><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li><li><a href="#rfc.section.7.4.2">7.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li></ul></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul><li><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li><li><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry">Status Code Registry</a><ul><li><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li><li><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registry">Header Field Registry</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Registrations</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based on File and Path Names</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.injection">Attacks Based on Command, Code, or Query Injection</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Disclosure of Personal Information</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#disclosure.product.information">Disclosure of Product Information</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#fingerprinting">Browser Fingerprinting</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li><li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-encoding">Conversion of Content-Encoding</a></li><li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></li><li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).</p><p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;7</a>).</p><p id="rfc.section.1.p.4"><span id="rfc.iref.c.1"></span> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "<dfn>content negotiation</dfn>" (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><p id="rfc.section.1.2.p.2">This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in <a href="#RFC6365" id="rfc.xref.RFC6365.1"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.</p></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><p id="rfc.section.2.p.1">The target of an HTTP request is called a "<dfn>resource</dfn>". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in <a href="rfc7230.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the <a href="rfc7230.html#target-resource" class="smpl">target URI</a> in one of various forms, as defined in (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). When a request is received, the server reconstructs an <a href="rfc7230.html#effective.request.uri" class="smpl">effective request URI</a> for the target resource (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, the method semantics take precedence.</p></div><div id="representations"><div id="rfc.iref.r.1"></div><div id="rfc.iref.s.1"></div><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.</p><p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.</p><p id="rfc.section.3.p.3">An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).</p><div id="representation.metadata"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#representation.metadata">Representation Metadata</a></h2><p id="rfc.section.3.1.p.1">Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.</p><p id="rfc.section.3.1.p.2">The following header fields convey representation metadata:</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">Content-Type</td><td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.1.1.5</a></td></tr><tr><td class="left">Content-Encoding</td><td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.1.2.2</a></td></tr><tr><td class="left">Content-Language</td><td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.1.3.2</a></td></tr><tr><td class="left">Content-Location</td><td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.1.4.2</a></td></tr></tbody></table></div><div id="data.type"><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a href="#data.type">Processing Representation Data</a></h3><div id="media.type"><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a href="#media.type">Media Type</a></h4><p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet media types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#media.type" class="smpl">media-type</a> = <a href="#media.type" class="smpl">type</a> "/" <a href="#media.type" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Resources" href="#rfc.section.2"><link rel="Chapter" title="3 Representations" href="#rfc.section.3"><link rel="Chapter" title="4 Request Methods" href="#rfc.section.4"><link rel="Chapter" title="5 Request Header Fields" href="#rfc.section.5"><link rel="Chapter" title="6 Response Status Codes" href="#rfc.section.6"><link rel="Chapter" title="7 Response Header Fields" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7230.html" rel="prev"><link href="rfc7232.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7231.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7231"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7231"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7231"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."></head><body onload="getMeta(7231,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7231</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resources">Resources</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representations">Representations</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.metadata">Representation Metadata</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing Representation Data</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#data.encoding">Encoding for Compression or Integrity</a></li><li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#audience.language">Audience Language</a></li><li><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#identification">Identification</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Payload Semantics</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul><li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li><li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li></ul></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#methods">Request Methods</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.overview">Overview</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.properties">Common Method Properties</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li><li><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li><li><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li><li><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li></ul></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#request.header.fields">Request Header Fields</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#request.conditionals">Conditionals</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request.conneg">Content Negotiation</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li><li><a href="#rfc.section.5.3.5">5.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#request.auth">Authentication Credentials</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.context">Request Context</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#status.codes">Response Status Codes</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.1xx">Informational 1xx</a><ul><li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.100">100 Continue</a></li><li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.101">101 Switching Protocols</a></li></ul></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.2xx">Successful 2xx</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.200">200 OK</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.201">201 Created</a></li><li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.202">202 Accepted</a></li><li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></li><li><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.204">204 No Content</a></li><li><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.205">205 Reset Content</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.3xx">Redirection 3xx</a><ul><li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.300">300 Multiple Choices</a></li><li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.301">301 Moved Permanently</a></li><li><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.302">302 Found</a></li><li><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.303">303 See Other</a></li><li><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.305">305 Use Proxy</a></li><li><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.306">306 (Unused)</a></li><li><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.307">307 Temporary Redirect</a></li></ul></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.4xx">Client Error 4xx</a><ul><li><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.400">400 Bad Request</a></li><li><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.402">402 Payment Required</a></li><li><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.403">403 Forbidden</a></li><li><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.404">404 Not Found</a></li><li><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.405">405 Method Not Allowed</a></li><li><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.406">406 Not Acceptable</a></li><li><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.408">408 Request Timeout</a></li><li><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#status.409">409 Conflict</a></li><li><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;&nbsp;&nbsp;<a href="#status.410">410 Gone</a></li><li><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;&nbsp;&nbsp;<a href="#status.411">411 Length Required</a></li><li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Payload Too Large</a></li><li><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li><li><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li><li><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;&nbsp;&nbsp;<a href="#status.417">417 Expectation Failed</a></li><li><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;&nbsp;&nbsp;<a href="#status.426">426 Upgrade Required</a></li></ul></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.5xx">Server Error 5xx</a><ul><li><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.500">500 Internal Server Error</a></li><li><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.501">501 Not Implemented</a></li><li><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.502">502 Bad Gateway</a></li><li><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.503">503 Service Unavailable</a></li><li><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.504">504 Gateway Timeout</a></li><li><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#response.control.data">Control Data</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#origination.date">Origination Date</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li><li><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#response.validator">Validator Header Fields</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#response.auth">Authentication Challenges</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.context">Response Context</a><ul><li><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li><li><a href="#rfc.section.7.4.2">7.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li></ul></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul><li><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li><li><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry">Status Code Registry</a><ul><li><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li><li><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registry">Header Field Registry</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Registrations</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based on File and Path Names</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.injection">Attacks Based on Command, Code, or Query Injection</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Disclosure of Personal Information</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#disclosure.product.information">Disclosure of Product Information</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#fingerprinting">Browser Fingerprinting</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li><li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-encoding">Conversion of Content-Encoding</a></li><li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></li><li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).</p><p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;7</a>).</p><p id="rfc.section.1.p.4"><span id="rfc.iref.c.1"></span> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "<dfn>content negotiation</dfn>" (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><p id="rfc.section.1.2.p.2">This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in <a href="#RFC6365" id="rfc.xref.RFC6365.1"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.</p></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><p id="rfc.section.2.p.1">The target of an HTTP request is called a "<dfn>resource</dfn>". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in <a href="rfc7230.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the <a href="rfc7230.html#target-resource" class="smpl">target URI</a> in one of various forms, as defined in (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). When a request is received, the server reconstructs an <a href="rfc7230.html#effective.request.uri" class="smpl">effective request URI</a> for the target resource (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, the method semantics take precedence.</p></div><div id="representations"><div id="rfc.iref.r.1"></div><div id="rfc.iref.s.1"></div><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.</p><p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.</p><p id="rfc.section.3.p.3">An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).</p><div id="representation.metadata"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#representation.metadata">Representation Metadata</a></h2><p id="rfc.section.3.1.p.1">Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.</p><p id="rfc.section.3.1.p.2">The following header fields convey representation metadata:</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">Content-Type</td><td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.1.1.5</a></td></tr><tr><td class="left">Content-Encoding</td><td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.1.2.2</a></td></tr><tr><td class="left">Content-Language</td><td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.1.3.2</a></td></tr><tr><td class="left">Content-Location</td><td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.1.4.2</a></td></tr></tbody></table></div><div id="data.type"><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a href="#data.type">Processing Representation Data</a></h3><div id="media.type"><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a href="#media.type">Media Type</a></h4><p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet media types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#media.type" class="smpl">media-type</a> = <a href="#media.type" class="smpl">type</a> "/" <a href="#media.type" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
    505505  <a href="#media.type" class="smpl">type</a>       = <a href="#imported.abnf" class="smpl">token</a>
    506506  <a href="#media.type" class="smpl">subtype</a>    = <a href="#imported.abnf" class="smpl">token</a>
  • specs/rfc7231.xml

    r2722 r2725  
    184184</t>
    185185</abstract>
    186 
    187 <note title="Editorial Note (To be removed by RFC Editor)">
    188   <t>
    189     Discussion of this draft takes place on the HTTPBIS working group
    190     mailing list (ietf-http-wg@w3.org), which is archived at
    191     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    192   </t>
    193   <t>
    194     The current issues list is at
    195     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    196     documents (including fancy diffs) can be found at
    197     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    198   </t>
    199   <t>
    200     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    201   </t>
    202 </note>
    203186</front>
    204187
  • specs/rfc7232.html

    r2722 r2725  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Validators" href="#rfc.section.2"><link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"><link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 Evaluation" href="#rfc.section.5"><link rel="Chapter" title="6 Precedence" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7231.html" rel="prev"><link href="rfc7233.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7232.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7232"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7232"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP conditional requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7232"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."></head><body onload="getMeta(7232,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7232</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">greenbytes</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7232">http://www.rfc-editor.org/info/rfc7232</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#validators">Validators</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.last-modified">Last-Modified</a><ul><li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.generation">Generation</a></li><li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.comparison">Comparison</a></li></ul></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.etag">ETag</a><ul><li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li><li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li><li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li></ul></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#preconditions">Precondition Header Fields</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-match">If-Match</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-none-match">If-None-Match</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-modified-since">If-Modified-Since</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-unmodified-since">If-Unmodified-Since</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.304">304 Not Modified</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#evaluation">Evaluation</a></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.</p><p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.</p><p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification (<a href="#preconditions" title="Precondition Header Fields">Section&nbsp;3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section&nbsp;6</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="validators"><div id="rfc.iref.m.1"></div><div id="rfc.iref.v.1"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.</p><div id="weak.and.strong.validators"><div id="rfc.iref.v.2"></div><div id="rfc.iref.v.3"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></h2><p id="rfc.section.2.1.p.1">Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.</p><p id="rfc.section.2.1.p.2">A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to GET.</p><p id="rfc.section.2.1.p.3">A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="rfc7231.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.</p><p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).</p><p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.</p><p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.</p><p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.</p><p id="rfc.section.2.1.p.8">Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.</p><p id="rfc.section.2.1.p.9">Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.</p></div><div id="header.last-modified"><div id="rfc.iref.l.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#header.last-modified">Last-Modified</a></h2><p id="rfc.section.2.2.p.1">The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Validators" href="#rfc.section.2"><link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"><link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 Evaluation" href="#rfc.section.5"><link rel="Chapter" title="6 Precedence" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7231.html" rel="prev"><link href="rfc7233.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7232.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7232"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7232"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP conditional requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7232"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."></head><body onload="getMeta(7232,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7232</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">greenbytes</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7232">http://www.rfc-editor.org/info/rfc7232</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#validators">Validators</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.last-modified">Last-Modified</a><ul><li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.generation">Generation</a></li><li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.comparison">Comparison</a></li></ul></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.etag">ETag</a><ul><li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li><li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li><li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li></ul></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#preconditions">Precondition Header Fields</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-match">If-Match</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-none-match">If-None-Match</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-modified-since">If-Modified-Since</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-unmodified-since">If-Unmodified-Since</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.304">304 Not Modified</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#evaluation">Evaluation</a></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.</p><p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.</p><p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification (<a href="#preconditions" title="Precondition Header Fields">Section&nbsp;3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section&nbsp;6</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="validators"><div id="rfc.iref.m.1"></div><div id="rfc.iref.v.1"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.</p><div id="weak.and.strong.validators"><div id="rfc.iref.v.2"></div><div id="rfc.iref.v.3"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></h2><p id="rfc.section.2.1.p.1">Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.</p><p id="rfc.section.2.1.p.2">A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to GET.</p><p id="rfc.section.2.1.p.3">A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="rfc7231.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.</p><p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).</p><p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.</p><p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.</p><p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.</p><p id="rfc.section.2.1.p.8">Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.</p><p id="rfc.section.2.1.p.9">Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.</p></div><div id="header.last-modified"><div id="rfc.iref.l.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#header.last-modified">Last-Modified</a></h2><p id="rfc.section.2.2.p.1">The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    505505</pre><p id="rfc.section.2.2.p.3">An example of its use is</p><div id="rfc.figure.u.2"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    506506</pre><div id="lastmod.generation"><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a href="#lastmod.generation">Generation</a></h3><p id="rfc.section.2.2.1.p.1">An origin server <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability.</p><p id="rfc.section.2.2.1.p.2">A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can use its value to make conditional requests and test the validity of locally cached responses.</p><p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the <a href="rfc7231.html#header.date" class="smpl">Date</a> field value for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially if the representation changes near the time that the response is generated.</p><p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (<a href="rfc7231.html#header.date" class="smpl">Date</a>). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact on cache validation.</p><p id="rfc.section.2.2.1.p.5">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Last-Modified values to a response unless these values were associated with the resource by some other system or user with a reliable clock.</p></div><div id="lastmod.comparison"><h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a href="#lastmod.comparison">Comparison</a></h3><p id="rfc.section.2.2.2.p.1">A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: </p><ul><li>The validator is being compared by an origin server to the actual current validator for the representation and,</li><li>That origin server reliably knows that the associated representation did not change twice during the second covered by the presented validator.</li></ul><p id="rfc.section.2.2.2.p.2">or </p><ul><li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, or <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> header field, because the client has a cache entry for the associated representation, and</li><li>That cache entry includes a <a href="rfc7231.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and</li><li>The presented Last-Modified time is at least 60 seconds before the Date value.</li></ul><p id="rfc.section.2.2.2.p.3">or </p><ul><li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and</li><li>That cache entry includes a <a href="rfc7231.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and</li><li>The presented Last-Modified time is at least 60 seconds before the Date value.</li></ul><p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a <a href="rfc7231.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.</p></div></div><div id="header.etag"><div id="rfc.iref.e.1"></div><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a href="#header.etag">ETag</a></h2><p id="rfc.section.2.3.p.1">The "ETag" header field in a response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.</p><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.etag" class="smpl">ETag</a>       = <a href="#header.etag" class="smpl">entity-tag</a>
  • specs/rfc7232.xml

    r2722 r2725  
    107107</t>
    108108</abstract>
    109 
    110 <note title="Editorial Note (To be removed by RFC Editor)">
    111   <t>
    112     Discussion of this draft takes place on the HTTPBIS working group
    113     mailing list (ietf-http-wg@w3.org), which is archived at
    114     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    115   </t>
    116   <t>
    117     The current issues list is at
    118     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    119     documents (including fancy diffs) can be found at
    120     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    121   </t>
    122   <t>
    123     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    124   </t>
    125 </note>
    126109</front>
    127110
  • specs/rfc7233.html

    r2722 r2725  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Range Units" href="#rfc.section.2"><link rel="Chapter" title="3 Range Requests" href="#rfc.section.3"><link rel="Chapter" title="4 Responses to a Range Request" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Internet Media Type multipart/byteranges" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7232.html" rel="prev"><link href="rfc7234.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7233.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7233"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7233"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Range Requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Lafon, Y."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7233"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."></head><body onload="getMeta(7233,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7233</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">Y. Lafon, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">W3C</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7233">http://www.rfc-editor.org/info/rfc7233</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#range.units">Range Units</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#byte.ranges">Byte Ranges</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.units.other">Other Range Units</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-ranges">Accept-Ranges</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#range.requests">Range Requests</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.range">Range</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#range.response">Responses to a Range Request</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.206">206 Partial Content</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-range">Content-Range</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry">Range Unit Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges.reg">Internet Media Type multipart/byteranges</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Denial-of-Service Attacks Using Range</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.</p><p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.</p><p id="rfc.section.1.p.3">Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="range.units"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#range.units">Range Units</a></h1><p id="rfc.section.2.p.1">A representation can be partitioned into subranges according to various structural units, depending on the structure inherent in the representation's media type. This "<dfn>range unit</dfn>" is used in the <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> (<a href="#header.accept-ranges" id="rfc.xref.header.accept-ranges.1" title="Accept-Ranges">Section&nbsp;2.3</a>) response header field to advertise support for range requests, the <a href="#header.range" class="smpl">Range</a> (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;3.1</a>) request header field to delineate the parts of a representation that are requested, and the <a href="#header.content-range" class="smpl">Content-Range</a> (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;4.2</a>) payload header field to describe which part of a representation is being transferred.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#range.units" class="smpl">range-unit</a>       = <a href="#byte.ranges" class="smpl">bytes-unit</a> / <a href="#range.units.other" class="smpl">other-range-unit</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Range Units" href="#rfc.section.2"><link rel="Chapter" title="3 Range Requests" href="#rfc.section.3"><link rel="Chapter" title="4 Responses to a Range Request" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Internet Media Type multipart/byteranges" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7232.html" rel="prev"><link href="rfc7234.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7233.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7233"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7233"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Range Requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Lafon, Y."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7233"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."></head><body onload="getMeta(7233,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7233</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">Y. Lafon, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">W3C</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7233">http://www.rfc-editor.org/info/rfc7233</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#range.units">Range Units</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#byte.ranges">Byte Ranges</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.units.other">Other Range Units</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-ranges">Accept-Ranges</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#range.requests">Range Requests</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.range">Range</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#range.response">Responses to a Range Request</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.206">206 Partial Content</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-range">Content-Range</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry">Range Unit Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges.reg">Internet Media Type multipart/byteranges</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Denial-of-Service Attacks Using Range</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.</p><p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.</p><p id="rfc.section.1.p.3">Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="range.units"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#range.units">Range Units</a></h1><p id="rfc.section.2.p.1">A representation can be partitioned into subranges according to various structural units, depending on the structure inherent in the representation's media type. This "<dfn>range unit</dfn>" is used in the <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> (<a href="#header.accept-ranges" id="rfc.xref.header.accept-ranges.1" title="Accept-Ranges">Section&nbsp;2.3</a>) response header field to advertise support for range requests, the <a href="#header.range" class="smpl">Range</a> (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;3.1</a>) request header field to delineate the parts of a representation that are requested, and the <a href="#header.content-range" class="smpl">Content-Range</a> (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;4.2</a>) payload header field to describe which part of a representation is being transferred.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#range.units" class="smpl">range-unit</a>       = <a href="#byte.ranges" class="smpl">bytes-unit</a> / <a href="#range.units.other" class="smpl">other-range-unit</a>
    505505</pre><div id="byte.ranges"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#byte.ranges">Byte Ranges</a></h2><p id="rfc.section.2.1.p.1">Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for any representation transferable over HTTP (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). The "bytes" range unit is defined for expressing subranges of the data's octet sequence.</p><div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#byte.ranges" class="smpl">bytes-unit</a>       = "bytes"
    506506</pre><div id="rule.ranges-specifier"><p id="rfc.section.2.1.p.3">        A byte-range request can specify a single range of bytes or a set of ranges within a single representation.</p></div><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> = <a href="#byte.ranges" class="smpl">bytes-unit</a> "=" <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a>
  • specs/rfc7233.xml

    r2722 r2725  
    114114</t>
    115115</abstract>
    116 
    117 <note title="Editorial Note (To be removed by RFC Editor)">
    118   <t>
    119     Discussion of this draft takes place on the HTTPBIS working group
    120     mailing list (ietf-http-wg@w3.org), which is archived at
    121     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    122   </t>
    123   <t>
    124     The current issues list is at
    125     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    126     documents (including fancy diffs) can be found at
    127     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    128   </t>
    129   <t>
    130     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    131   </t>
    132 </note>
    133116</front>
    134117<middle>
  • specs/rfc7234.html

    r2721 r2725  
    606606    }
    607607}
    608 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Overview of Cache Operation" href="#rfc.section.2"><link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3"><link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4"><link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"><link rel="Chapter" title="6 History Lists" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7233.html" rel="prev"><link href="rfc7235.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7234.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7234"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7234"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Caching"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Nottingham, M."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7234"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."></head><body onload="getMeta(7234,&#34;rfc.meta&#34;);initFeedback();"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7234</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">M. Nottingham, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">Akamai</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Caching</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7234">http://www.rfc-editor.org/info/rfc7234</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#caching">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul><li><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li></ul></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li><li><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#validation.sent">Sending a Validation Request</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.received">Handling a Received Validation Request</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.response">Handling a Validation Response</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Freshening Responses via HEAD</a></li></ul></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation">Invalidation</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul><li><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li></ul></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></li><li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></li><li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></li><li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></li><li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul><li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.</p><div id="rfc.iref.c.1"></div><p id="rfc.section.1.p.2">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.</p><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.</p></div><p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="delta-seconds"><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a href="#delta-seconds">Delta Seconds</a></h3><p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
     608</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Overview of Cache Operation" href="#rfc.section.2"><link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3"><link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4"><link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"><link rel="Chapter" title="6 History Lists" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7233.html" rel="prev"><link href="rfc7235.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7234.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7234"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7234"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Caching"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Nottingham, M."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7234"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."></head><body onload="getMeta(7234,&#34;rfc.meta&#34;);initFeedback();"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7234</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">M. Nottingham, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">Akamai</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Caching</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7234">http://www.rfc-editor.org/info/rfc7234</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#caching">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul><li><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li></ul></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li><li><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#validation.sent">Sending a Validation Request</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.received">Handling a Received Validation Request</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.response">Handling a Validation Response</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Freshening Responses via HEAD</a></li></ul></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation">Invalidation</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul><li><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li></ul></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></li><li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></li><li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></li><li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></li><li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul><li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.</p><div id="rfc.iref.c.1"></div><p id="rfc.section.1.p.2">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.</p><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.</p></div><p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="delta-seconds"><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a href="#delta-seconds">Delta Seconds</a></h3><p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    609609</pre><p id="rfc.section.1.2.1.p.3">A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache <em class="bcp14">MUST</em> consider the value to be either 2147483648 (2<sup>31</sup>) or the greatest positive integer it can conveniently represent.</p><div class="note" id="rfc.section.1.2.1.p.4"><p><b>Note:</b> The value 2147483648 is here for historical reasons, effectively represents infinity (over 68 years), and does not need to be stored in binary form; an implementation could produce it as a canned string if any overflow occurs, even if the calculations are performed with an arithmetic type incapable of directly representing that number. What matters here is that an overflow be detected and not treated as a negative value in later calculations.</p> </div></div></div></div><div id="caching.overview"><div id="rfc.iref.c.2"></div><div id="rfc.iref.c.3"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></h1><p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.</p><p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common form of cache entry is a successful result of a retrieval request: i.e., a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to a GET request, which contains a representation of the resource identified by the request target (<a href="rfc7231.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). However, it is also possible to cache permanent redirects, negative results (e.g., <a href="rfc7231.html#status.404" class="smpl">404 (Not Found)</a>), incomplete results (e.g., <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.</p><div id="rfc.iref.c.4"></div><p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.</p><p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>).</p></div><div id="response.cacheability"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a></h1><p id="rfc.section.3.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: </p><ul><li>The request method is understood by the cache and defined as being cacheable, and</li><li>the response status code is understood by the cache, and</li><li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;5.2</a>) does not appear in request or response header fields, and</li><li>the "private" response directive (see <a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a>) does not appear in the response, if the cache is shared, and</li><li>the <a href="rfc7235.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="rfc7235.html#header.authorization" title="Authorization">Section 4.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>), and</li><li>the response either: <ul><li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;5.3</a>), or</li><li>contains a max-age response directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>), or</li><li>contains a s-maxage response directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>) and the cache is shared, or</li><li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>) that allows it to be cached, or</li><li>has a status code that is defined as cacheable by default (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>), or</li><li>contains a public response directive (see <a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a>).</li></ul> </li></ul><p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p><p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all specified caching-related behavior.</p><p id="rfc.section.3.p.4">Note that, in normal operation, some caches will not store a response that has neither a cache validator nor an explicit expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.</p><div id="incomplete.responses"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></h2><p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a>, and the entire response header section has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="rfc7231.html#status.200" class="smpl">200
    610610   (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial-content responses if it does not support the <a href="rfc7233.html#header.range" class="smpl">Range</a> and <a href="rfc7233.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.</p><p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;3.3</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> status code.</p></div><div id="caching.authenticated.responses"><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></h2><p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="rfc7235.html#header.authorization" class="smpl">Authorization</a> header field (<a href="rfc7235.html#header.authorization" title="Authorization">Section 4.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.</p><p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>) have such an effect: must-revalidate, public, and s-maxage.</p><p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server.</p></div><div id="combining.responses"><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a href="#combining.responses">Combining Partial Content</a></h2><p id="rfc.section.3.3.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (<a href="#RFC7233" id="rfc.xref.RFC7233.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in <a href="rfc7233.html#combining.byte.ranges" title="Combining Ranges">Section 4.3</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.</p><p id="rfc.section.3.3.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: </p><ul><li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;5.5</a>);</li><li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,</li><li>use other header fields provided in the new response, aside from <a href="rfc7233.html#header.content-range" class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response.</li></ul></div></div><div id="constructing.responses.from.caches"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h1><p id="rfc.section.4.p.1">When presented with a request, a cache <em class="bcp14">MUST NOT</em> reuse a stored response, unless: </p><ul><li>The presented effective request URI (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) and that of the stored response match, and</li><li>the request method associated with the stored response allows it to be used for the presented request, and</li><li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), and</li><li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;5.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and</li><li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and</li><li>the stored response is either: <ul><li>fresh (see <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>), or</li><li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>), or</li><li>successfully validated (see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>).</li></ul> </li></ul><p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p><p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;5.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.</p><p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="rfc7231.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.</p><p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already-stored responses; see <a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>.</p><p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="rfc7231.html#header.date" class="smpl">Date</a> header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.</p><p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them upon every use.</p><div id="caching.negotiated.responses"><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2><p id="rfc.section.4.1.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="rfc7231.html#header.vary" class="smpl">Vary</a> header field (<a href="rfc7231.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request.</p><p id="rfc.section.4.1.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following: </p><ul><li>adding or removing whitespace, where allowed in the header field's syntax</li><li>combining multiple header fields with the same field name (see <a href="rfc7230.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>)</li><li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)</li></ul><p id="rfc.section.4.1.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request if it is also absent there.</p><p id="rfc.section.4.1.p.4">A <a href="rfc7231.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.</p><p id="rfc.section.4.1.p.5">The stored response with matching selecting header fields is known as the selected response.</p><p id="rfc.section.4.1.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="rfc7231.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="rfc7231.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.</p><p id="rfc.section.4.1.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) request.</p></div><div id="expiration.model"><div id="rfc.iref.f.1"></div><div id="rfc.iref.s.2"></div><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#expiration.model">Freshness</a></h2><p id="rfc.section.4.2.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.</p><div id="rfc.iref.f.2"></div><div id="rfc.iref.e.1"></div><div id="rfc.iref.h.1"></div><p id="rfc.section.4.2.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiration time is available.</p><div id="rfc.iref.a.1"></div><p id="rfc.section.4.2.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.</p><p id="rfc.section.4.2.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.</p><p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;5.3</a>) or the max-age response directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.</p><p id="rfc.section.4.2.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><p id="rfc.section.4.2.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>).</p><div id="rfc.figure.u.2"></div><p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
  • specs/rfc7234.xml

    r2722 r2725  
    128128</t>
    129129</abstract>
    130 
    131 <note title="Editorial Note (To be removed by RFC Editor)">
    132   <t>
    133     Discussion of this draft takes place on the HTTPBIS working group
    134     mailing list (ietf-http-wg@w3.org), which is archived at
    135     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    136   </t>
    137   <t>
    138     The current issues list is at
    139     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    140     documents (including fancy diffs) can be found at
    141     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    142   </t>
    143   <t>
    144     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    145   </t>
    146 </note>
    147 
    148130   </front>
    149131   <middle>
  • specs/rfc7235.html

    r2721 r2725  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Access Authentication Framework" href="#rfc.section.2"><link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"><link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Changes from RFCs 2616 and 2617" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7234.html" rel="prev"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7235.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7235"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7235"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP authentication"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7235"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."></head><body onload="getMeta(7235,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7235</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2617">2617</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Authentication</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7235">http://www.rfc-editor.org/info/rfc7235</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.401">401 Unauthorized</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFCs 2616 and 2617</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</p><p id="rfc.section.1.p.2">The IANA Authentication Scheme Registry (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;5.1</a>) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="access.authentication.framework"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a></h1><div id="challenge.and.response"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#challenge.and.response">Challenge and Response</a></h2><p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.</p><p id="rfc.section.2.1.p.2">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  auth-scheme    = <a href="#imported.abnf" class="smpl">token</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Access Authentication Framework" href="#rfc.section.2"><link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"><link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Changes from RFCs 2616 and 2617" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7234.html" rel="prev"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7235.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7235"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7235"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP authentication"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7235"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."></head><body onload="getMeta(7235,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7235</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2617">2617</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Authentication</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7235">http://www.rfc-editor.org/info/rfc7235</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.401">401 Unauthorized</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFCs 2616 and 2617</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</p><p id="rfc.section.1.p.2">The IANA Authentication Scheme Registry (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;5.1</a>) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="access.authentication.framework"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a></h1><div id="challenge.and.response"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#challenge.and.response">Challenge and Response</a></h2><p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.</p><p id="rfc.section.2.1.p.2">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  auth-scheme    = <a href="#imported.abnf" class="smpl">token</a>
    505505 
    506506  auth-param     = <a href="#imported.abnf" class="smpl">token</a> <a href="#imported.abnf" class="smpl">BWS</a> "=" <a href="#imported.abnf" class="smpl">BWS</a> ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> )
  • specs/rfc7235.xml

    r2722 r2725  
    9696</t>
    9797</abstract>
    98 
    99 <note title="Editorial Note (To be removed by RFC Editor)">
    100   <t>
    101     Discussion of this draft takes place on the HTTPBIS working group
    102     mailing list (ietf-http-wg@w3.org), which is archived at
    103     <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    104   </t>
    105   <t>
    106     The current issues list is at
    107     <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
    108     documents (including fancy diffs) can be found at
    109     <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    110   </t>
    111   <t>
    112     <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    113   </t>
    114 </note>
    11598</front>
    11699<middle>
  • specs/rfc7236.html

    r2721 r2725  
    474474    }
    475475}
    476 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Security Considerations" href="#rfc.section.2"><link rel="Chapter" title="3 IANA Considerations" href="#rfc.section.3"><link rel="Chapter" href="#rfc.section.4" title="4 Normative References"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7236.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7236"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7236"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, Authentication, Authentication Scheme"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7236"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.abstract" content="This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established."></head><body onload="getMeta(7236,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">J. Reschke</td></tr><tr><td class="left">Request for Comments: 7236</td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Informational</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Initial Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP) Authentication&nbsp;Scheme&nbsp;Registrations</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=authscheme-registrations">http://trac.tools.ietf.org/wg/httpbis/trac/query?component=authscheme-registrations</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This document is not an Internet Standards Track specification; it is published for informational purposes.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7236">http://www.rfc-editor.org/info/rfc7236</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li><li><a href="#rfc.authors">Author's Address</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.</p></div><div id="security.considerations"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.2.p.1">There are no security considerations related to the registration itself.</p><p id="rfc.section.2.p.2">Security considerations applicable to the individual authentication schemes ought to be discussed in the specifications that define them.</p></div><div id="iana.considerations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><p id="rfc.section.3.p.1">The registrations below have been added to the IANA "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt; (see <a href="rfc7235.html#authentication.scheme.registry" title="Authentication Scheme Registry">Section 5.1</a> of <a href="#RFC7235"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>).</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Authentication Scheme Name</th><th>Reference</th><th>Notes</th></tr></thead><tbody><tr><td class="left">Basic</td><td class="left"><a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="https://tools.ietf.org/html/rfc2617#section-2">Section 2</a></td><td class="left"></td></tr><tr><td class="left">Bearer</td><td class="left"><a href="#RFC6750"><cite title="The OAuth 2.0 Authorization Framework: Bearer Token Usage">[RFC6750]</cite></a></td><td class="left"></td></tr><tr><td class="left">Digest</td><td class="left"><a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="https://tools.ietf.org/html/rfc2617#section-3">Section 3</a></td><td class="left"></td></tr><tr><td class="left">Negotiate</td><td class="left"><a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>, <a href="https://tools.ietf.org/html/rfc4559#section-3">Section 3</a></td><td class="left">This authentication scheme violates both HTTP semantics (being connection-oriented) and syntax (use of syntax incompatible with the WWW-Authenticate and Authorization header field syntax).</td></tr><tr><td class="left">OAuth</td><td class="left"><a href="#RFC5849"><cite title="The OAuth 1.0 Protocol">[RFC5849]</cite></a>, <a href="https://tools.ietf.org/html/rfc5849#section-3.5.1">Section 3.5.1</a></td><td class="left"></td></tr></tbody></table></div></div><h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> Normative References</h1><table><tr><td class="reference"><b id="RFC2617">[RFC2617]</b></td><td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>&#8221;, RFC&nbsp;2617, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC4559">[RFC4559]</b></td><td class="top">Jaganathan, K., Zhu, L., and J. Brezak, &#8220;<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>&#8221;, RFC&nbsp;4559, June&nbsp;2006.</td></tr><tr><td class="reference"><b id="RFC5849">[RFC5849]</b></td><td class="top">Hammer-Lahav, E., &#8220;<a href="https://tools.ietf.org/html/rfc5849">The OAuth 1.0 Protocol</a>&#8221;, RFC&nbsp;5849, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC6750">[RFC6750]</b></td><td class="top">Jones, M. and D. Hardt, &#8220;<a href="https://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>&#8221;, RFC&nbsp;6750, October&nbsp;2012.</td></tr><tr><td class="reference"><b id="RFC7235">[RFC7235]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7235">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>&#8221;, RFC&nbsp;7235, June&nbsp;2014.</td></tr></table><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1><p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p></div></body></html>
     476</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Security Considerations" href="#rfc.section.2"><link rel="Chapter" title="3 IANA Considerations" href="#rfc.section.3"><link rel="Chapter" href="#rfc.section.4" title="4 Normative References"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7236.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7236"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7236"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, Authentication, Authentication Scheme"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7236"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.abstract" content="This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established."></head><body onload="getMeta(7236,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">J. Reschke</td></tr><tr><td class="left">Request for Comments: 7236</td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Informational</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Initial Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP) Authentication&nbsp;Scheme&nbsp;Registrations</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This document is not an Internet Standards Track specification; it is published for informational purposes.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7236">http://www.rfc-editor.org/info/rfc7236</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li><li><a href="#rfc.authors">Author's Address</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.</p></div><div id="security.considerations"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.2.p.1">There are no security considerations related to the registration itself.</p><p id="rfc.section.2.p.2">Security considerations applicable to the individual authentication schemes ought to be discussed in the specifications that define them.</p></div><div id="iana.considerations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><p id="rfc.section.3.p.1">The registrations below have been added to the IANA "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt; (see <a href="rfc7235.html#authentication.scheme.registry" title="Authentication Scheme Registry">Section 5.1</a> of <a href="#RFC7235"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>).</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Authentication Scheme Name</th><th>Reference</th><th>Notes</th></tr></thead><tbody><tr><td class="left">Basic</td><td class="left"><a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="https://tools.ietf.org/html/rfc2617#section-2">Section 2</a></td><td class="left"></td></tr><tr><td class="left">Bearer</td><td class="left"><a href="#RFC6750"><cite title="The OAuth 2.0 Authorization Framework: Bearer Token Usage">[RFC6750]</cite></a></td><td class="left"></td></tr><tr><td class="left">Digest</td><td class="left"><a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="https://tools.ietf.org/html/rfc2617#section-3">Section 3</a></td><td class="left"></td></tr><tr><td class="left">Negotiate</td><td class="left"><a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>, <a href="https://tools.ietf.org/html/rfc4559#section-3">Section 3</a></td><td class="left">This authentication scheme violates both HTTP semantics (being connection-oriented) and syntax (use of syntax incompatible with the WWW-Authenticate and Authorization header field syntax).</td></tr><tr><td class="left">OAuth</td><td class="left"><a href="#RFC5849"><cite title="The OAuth 1.0 Protocol">[RFC5849]</cite></a>, <a href="https://tools.ietf.org/html/rfc5849#section-3.5.1">Section 3.5.1</a></td><td class="left"></td></tr></tbody></table></div></div><h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> Normative References</h1><table><tr><td class="reference"><b id="RFC2617">[RFC2617]</b></td><td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>&#8221;, RFC&nbsp;2617, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC4559">[RFC4559]</b></td><td class="top">Jaganathan, K., Zhu, L., and J. Brezak, &#8220;<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>&#8221;, RFC&nbsp;4559, June&nbsp;2006.</td></tr><tr><td class="reference"><b id="RFC5849">[RFC5849]</b></td><td class="top">Hammer-Lahav, E., &#8220;<a href="https://tools.ietf.org/html/rfc5849">The OAuth 1.0 Protocol</a>&#8221;, RFC&nbsp;5849, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC6750">[RFC6750]</b></td><td class="top">Jones, M. and D. Hardt, &#8220;<a href="https://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>&#8221;, RFC&nbsp;6750, October&nbsp;2012.</td></tr><tr><td class="reference"><b id="RFC7235">[RFC7235]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7235">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>&#8221;, RFC&nbsp;7235, June&nbsp;2014.</td></tr></table><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1><p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p></div></body></html>
  • specs/rfc7236.xml

    r2721 r2725  
    6161  </abstract>
    6262 
    63   <note title="Editorial Note (To be removed by RFC Editor)">
    64     <t>
    65       Discussion of this draft takes place on the HTTPBIS working group
    66       mailing list (ietf-http-wg@w3.org), which is archived at
    67       <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    68     </t>
    69     <t>
    70       The current issues list is at
    71       <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=authscheme-registrations"/> and related
    72       documents (including fancy diffs) can be found at
    73       <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    74     </t>
    75     <t>
    76       <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    77     </t>
    78   </note>
    79 
    8063  </front>
    8164
  • specs/rfc7237.html

    r2721 r2725  
    474474    }
    475475}
    476 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Security Considerations" href="#rfc.section.2"><link rel="Chapter" title="3 IANA Considerations" href="#rfc.section.3"><link rel="Chapter" href="#rfc.section.4" title="4 Normative References"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7237.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7237"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7237"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, Request Method"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7237"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.abstract" content="This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established."></head><body onload="getMeta(7237,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">J. Reschke</td></tr><tr><td class="left">Request for Comments: 7237</td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Informational</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Initial Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP) Method&nbsp;Registrations</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.</p><h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1><p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.</p><p>The current issues list is at &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=method-registrations">http://trac.tools.ietf.org/wg/httpbis/trac/query?component=method-registrations</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.</p><p><em>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</em> </p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This document is not an Internet Standards Track specification; it is published for informational purposes.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7237">http://www.rfc-editor.org/info/rfc7237</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li><li><a href="#rfc.authors">Author's Address</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs other than <a href="#RFC7231"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> before the IANA HTTP Method Registry was established.</p></div><div id="security.considerations"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.2.p.1">There are no security considerations related to the registration itself.</p><p id="rfc.section.2.p.2">Security considerations applicable to the individual HTTP methods ought to be discussed in the specifications that define them.</p></div><div id="iana.considerations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><p id="rfc.section.3.p.1">The table below provides registrations of HTTP method names that have been added to the IANA "Hypertext Transfer Protocol (HTTP) Method Registry" at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; (see <a href="rfc7231.html#method.registry" title="Method Registry">Section 8.1</a> of <a href="#RFC7231"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Method Name</th><th>Safe</th><th>Idempotent</th><th>Reference</th></tr></thead><tbody><tr><td class="left">ACL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3744"><cite title="Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol">[RFC3744]</cite></a>, <a href="https://tools.ietf.org/html/rfc3744#section-8.1">Section 8.1</a></td></tr><tr><td class="left">BASELINE-CONTROL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-12.6">Section 12.6</a></td></tr><tr><td class="left">BIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-4">Section 4</a></td></tr><tr><td class="left">CHECKIN</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.4">Section 4.4</a> and <a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-9.4">Section 9.4</a></td></tr><tr><td class="left">CHECKOUT</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.3">Section 4.3</a> and <a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-8.8">Section 8.8</a></td></tr><tr><td class="left">COPY</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.8">Section 9.8</a></td></tr><tr><td class="left">LABEL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-8.2">Section 8.2</a></td></tr><tr><td class="left">LINK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-19.6.1.2">Section 19.6.1.2</a></td></tr><tr><td class="left">LOCK</td><td class="left">no</td><td class="left">no</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.10">Section 9.10</a></td></tr><tr><td class="left">MERGE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-11.2">Section 11.2</a></td></tr><tr><td class="left">MKACTIVITY</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-13.5">Section 13.5</a></td></tr><tr><td class="left">MKCALENDAR</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4791"><cite title="Calendaring Extensions to WebDAV (CalDAV)">[RFC4791]</cite></a>, <a href="https://tools.ietf.org/html/rfc4791#section-5.3.1">Section 5.3.1</a></td></tr><tr><td class="left">MKCOL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.3">Section 9.3</a></td></tr><tr><td class="left">MKREDIRECTREF</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4437"><cite title="Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources">[RFC4437]</cite></a>, <a href="https://tools.ietf.org/html/rfc4437#section-6">Section 6</a></td></tr><tr><td class="left">MKWORKSPACE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-6.3">Section 6.3</a></td></tr><tr><td class="left">MOVE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.9">Section 9.9</a></td></tr><tr><td class="left">ORDERPATCH</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3648"><cite title="Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol">[RFC3648]</cite></a>, <a href="https://tools.ietf.org/html/rfc3648#section-7">Section 7</a></td></tr><tr><td class="left">PATCH</td><td class="left">no</td><td class="left">no</td><td class="left"><a href="#RFC5789"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>, <a href="https://tools.ietf.org/html/rfc5789#section-2">Section 2</a></td></tr><tr><td class="left">PROPFIND</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.1">Section 9.1</a></td></tr><tr><td class="left">PROPPATCH</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.2">Section 9.2</a></td></tr><tr><td class="left">REBIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-6">Section 6</a></td></tr><tr><td class="left">REPORT</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-3.6">Section 3.6</a></td></tr><tr><td class="left">SEARCH</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC5323"><cite title="Web Distributed Authoring and Versioning (WebDAV) SEARCH">[RFC5323]</cite></a>, <a href="https://tools.ietf.org/html/rfc5323#section-2">Section 2</a></td></tr><tr><td class="left">UNBIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-5">Section 5</a></td></tr><tr><td class="left">UNCHECKOUT</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.5">Section 4.5</a></td></tr><tr><td class="left">UNLINK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-19.6.1.3">Section 19.6.1.3</a></td></tr><tr><td class="left">UNLOCK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.11">Section 9.11</a></td></tr><tr><td class="left">UPDATE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-7.1">Section 7.1</a></td></tr><tr><td class="left">UPDATEREDIRECTREF</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4437"><cite title="Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources">[RFC4437]</cite></a>, <a href="https://tools.ietf.org/html/rfc4437#section-7">Section 7</a></td></tr><tr><td class="left">VERSION-CONTROL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-3.5">Section 3.5</a></td></tr></tbody></table></div></div><h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> Normative References</h1><table><tr><td class="reference"><b id="RFC2068">[RFC2068]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2068, January&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC3253">[RFC3253]</b></td><td class="top"><a href="mailto:geoffrey.clemm@rational.com" title="Rational Software">Clemm, G.</a>, <a href="mailto:jamsden@us.ibm.com" title="IBM">Amsden, J.</a>, <a href="mailto:tim_ellison@uk.ibm.com" title="IBM">Ellison, T.</a>, <a href="mailto:ckaler@microsoft.com" title="Microsoft">Kaler, C.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3253">Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)</a>&#8221;, RFC&nbsp;3253, March&nbsp;2002.</td></tr><tr><td class="reference"><b id="RFC3648">[RFC3648]</b></td><td class="top"><a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">Whitehead, J.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3648">Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol</a>&#8221;, RFC&nbsp;3648, December&nbsp;2003.</td></tr><tr><td class="reference"><b id="RFC3744">[RFC3744]</b></td><td class="top"><a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, <a href="mailto:eric.sedlar@oracle.com" title="Oracle Corporation">Sedlar, E.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="U.C. Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3744">Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol</a>&#8221;, RFC&nbsp;3744, May&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC4437">[RFC4437]</b></td><td class="top"><a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">Whitehead, J.</a>, <a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4437">Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources</a>&#8221;, RFC&nbsp;4437, March&nbsp;2006.</td></tr><tr><td class="reference"><b id="RFC4791">[RFC4791]</b></td><td class="top"><a href="mailto:cyrus@daboo.name" title="Apple Inc.">Daboo, C.</a>, <a href="mailto:bernard.desruisseaux@oracle.com" title="Oracle Corporation">Desruisseaux, B.</a>, and <a href="mailto:ldusseault@commerce.net" title="CommerceNet">L. Dusseault</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4791">Calendaring Extensions to WebDAV (CalDAV)</a>&#8221;, RFC&nbsp;4791, March&nbsp;2007.</td></tr><tr><td class="reference"><b id="RFC4918">[RFC4918]</b></td><td class="top"><a href="mailto:ldusseault@commerce.net" title="CommerceNet">Dusseault, L., Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4918">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;4918, June&nbsp;2007.</td></tr><tr><td class="reference"><b id="RFC5323">[RFC5323]</b></td><td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J., Ed.</a>, <a href="mailto:Surendra.Reddy@mitrix.com" title="Mitrix, Inc.">Reddy, S.</a>, <a href="mailto:jrd3@alum.mit.edu">Davis, J.</a>, and <a href="mailto:ababich@us.ibm.com" title="IBM Corporation">A. Babich</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5323">Web Distributed Authoring and Versioning (WebDAV) SEARCH</a>&#8221;, RFC&nbsp;5323, November&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC5789">[RFC5789]</b></td><td class="top"><a href="mailto:lisa.dusseault@gmail.com" title="Linden Lab">Dusseault, L.</a> and <a href="mailto:jasnell@gmail.com">J. Snell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5789">PATCH Method for HTTP</a>&#8221;, RFC&nbsp;5789, March&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC5842">[RFC5842]</b></td><td class="top"><a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, <a href="mailto:ccjason@us.ibm.com" title="IBM Research">Crawford, J.</a>, <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J., Ed.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5842">Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;5842, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr></table><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1><p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p></div></body></html>
     476</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Security Considerations" href="#rfc.section.2"><link rel="Chapter" title="3 IANA Considerations" href="#rfc.section.3"><link rel="Chapter" href="#rfc.section.4" title="4 Normative References"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7237.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7237"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7237"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, Request Method"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7237"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.abstract" content="This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established."></head><body onload="getMeta(7237,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">J. Reschke</td></tr><tr><td class="left">Request for Comments: 7237</td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Informational</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Initial Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP) Method&nbsp;Registrations</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This document is not an Internet Standards Track specification; it is published for informational purposes.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7237">http://www.rfc-editor.org/info/rfc7237</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">Normative References</a></li><li><a href="#rfc.authors">Author's Address</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs other than <a href="#RFC7231"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> before the IANA HTTP Method Registry was established.</p></div><div id="security.considerations"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.2.p.1">There are no security considerations related to the registration itself.</p><p id="rfc.section.2.p.2">Security considerations applicable to the individual HTTP methods ought to be discussed in the specifications that define them.</p></div><div id="iana.considerations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><p id="rfc.section.3.p.1">The table below provides registrations of HTTP method names that have been added to the IANA "Hypertext Transfer Protocol (HTTP) Method Registry" at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; (see <a href="rfc7231.html#method.registry" title="Method Registry">Section 8.1</a> of <a href="#RFC7231"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Method Name</th><th>Safe</th><th>Idempotent</th><th>Reference</th></tr></thead><tbody><tr><td class="left">ACL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3744"><cite title="Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol">[RFC3744]</cite></a>, <a href="https://tools.ietf.org/html/rfc3744#section-8.1">Section 8.1</a></td></tr><tr><td class="left">BASELINE-CONTROL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-12.6">Section 12.6</a></td></tr><tr><td class="left">BIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-4">Section 4</a></td></tr><tr><td class="left">CHECKIN</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.4">Section 4.4</a> and <a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-9.4">Section 9.4</a></td></tr><tr><td class="left">CHECKOUT</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.3">Section 4.3</a> and <a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-8.8">Section 8.8</a></td></tr><tr><td class="left">COPY</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.8">Section 9.8</a></td></tr><tr><td class="left">LABEL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-8.2">Section 8.2</a></td></tr><tr><td class="left">LINK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-19.6.1.2">Section 19.6.1.2</a></td></tr><tr><td class="left">LOCK</td><td class="left">no</td><td class="left">no</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.10">Section 9.10</a></td></tr><tr><td class="left">MERGE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-11.2">Section 11.2</a></td></tr><tr><td class="left">MKACTIVITY</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-13.5">Section 13.5</a></td></tr><tr><td class="left">MKCALENDAR</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4791"><cite title="Calendaring Extensions to WebDAV (CalDAV)">[RFC4791]</cite></a>, <a href="https://tools.ietf.org/html/rfc4791#section-5.3.1">Section 5.3.1</a></td></tr><tr><td class="left">MKCOL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.3">Section 9.3</a></td></tr><tr><td class="left">MKREDIRECTREF</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4437"><cite title="Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources">[RFC4437]</cite></a>, <a href="https://tools.ietf.org/html/rfc4437#section-6">Section 6</a></td></tr><tr><td class="left">MKWORKSPACE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-6.3">Section 6.3</a></td></tr><tr><td class="left">MOVE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.9">Section 9.9</a></td></tr><tr><td class="left">ORDERPATCH</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3648"><cite title="Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol">[RFC3648]</cite></a>, <a href="https://tools.ietf.org/html/rfc3648#section-7">Section 7</a></td></tr><tr><td class="left">PATCH</td><td class="left">no</td><td class="left">no</td><td class="left"><a href="#RFC5789"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>, <a href="https://tools.ietf.org/html/rfc5789#section-2">Section 2</a></td></tr><tr><td class="left">PROPFIND</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.1">Section 9.1</a></td></tr><tr><td class="left">PROPPATCH</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.2">Section 9.2</a></td></tr><tr><td class="left">REBIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-6">Section 6</a></td></tr><tr><td class="left">REPORT</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-3.6">Section 3.6</a></td></tr><tr><td class="left">SEARCH</td><td class="left">yes</td><td class="left">yes</td><td class="left"><a href="#RFC5323"><cite title="Web Distributed Authoring and Versioning (WebDAV) SEARCH">[RFC5323]</cite></a>, <a href="https://tools.ietf.org/html/rfc5323#section-2">Section 2</a></td></tr><tr><td class="left">UNBIND</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC5842"><cite title="Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)">[RFC5842]</cite></a>, <a href="https://tools.ietf.org/html/rfc5842#section-5">Section 5</a></td></tr><tr><td class="left">UNCHECKOUT</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-4.5">Section 4.5</a></td></tr><tr><td class="left">UNLINK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-19.6.1.3">Section 19.6.1.3</a></td></tr><tr><td class="left">UNLOCK</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4918"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-9.11">Section 9.11</a></td></tr><tr><td class="left">UPDATE</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-7.1">Section 7.1</a></td></tr><tr><td class="left">UPDATEREDIRECTREF</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC4437"><cite title="Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources">[RFC4437]</cite></a>, <a href="https://tools.ietf.org/html/rfc4437#section-7">Section 7</a></td></tr><tr><td class="left">VERSION-CONTROL</td><td class="left">no</td><td class="left">yes</td><td class="left"><a href="#RFC3253"><cite title="Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)">[RFC3253]</cite></a>, <a href="https://tools.ietf.org/html/rfc3253#section-3.5">Section 3.5</a></td></tr></tbody></table></div></div><h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> Normative References</h1><table><tr><td class="reference"><b id="RFC2068">[RFC2068]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2068, January&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC3253">[RFC3253]</b></td><td class="top"><a href="mailto:geoffrey.clemm@rational.com" title="Rational Software">Clemm, G.</a>, <a href="mailto:jamsden@us.ibm.com" title="IBM">Amsden, J.</a>, <a href="mailto:tim_ellison@uk.ibm.com" title="IBM">Ellison, T.</a>, <a href="mailto:ckaler@microsoft.com" title="Microsoft">Kaler, C.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3253">Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)</a>&#8221;, RFC&nbsp;3253, March&nbsp;2002.</td></tr><tr><td class="reference"><b id="RFC3648">[RFC3648]</b></td><td class="top"><a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">Whitehead, J.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3648">Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol</a>&#8221;, RFC&nbsp;3648, December&nbsp;2003.</td></tr><tr><td class="reference"><b id="RFC3744">[RFC3744]</b></td><td class="top"><a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, <a href="mailto:eric.sedlar@oracle.com" title="Oracle Corporation">Sedlar, E.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="U.C. Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3744">Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol</a>&#8221;, RFC&nbsp;3744, May&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC4437">[RFC4437]</b></td><td class="top"><a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">Whitehead, J.</a>, <a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4437">Web Distributed Authoring and Versioning (WebDAV) Redirect&nbsp;Reference&nbsp;Resources</a>&#8221;, RFC&nbsp;4437, March&nbsp;2006.</td></tr><tr><td class="reference"><b id="RFC4791">[RFC4791]</b></td><td class="top"><a href="mailto:cyrus@daboo.name" title="Apple Inc.">Daboo, C.</a>, <a href="mailto:bernard.desruisseaux@oracle.com" title="Oracle Corporation">Desruisseaux, B.</a>, and <a href="mailto:ldusseault@commerce.net" title="CommerceNet">L. Dusseault</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4791">Calendaring Extensions to WebDAV (CalDAV)</a>&#8221;, RFC&nbsp;4791, March&nbsp;2007.</td></tr><tr><td class="reference"><b id="RFC4918">[RFC4918]</b></td><td class="top"><a href="mailto:ldusseault@commerce.net" title="CommerceNet">Dusseault, L., Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4918">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;4918, June&nbsp;2007.</td></tr><tr><td class="reference"><b id="RFC5323">[RFC5323]</b></td><td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J., Ed.</a>, <a href="mailto:Surendra.Reddy@mitrix.com" title="Mitrix, Inc.">Reddy, S.</a>, <a href="mailto:jrd3@alum.mit.edu">Davis, J.</a>, and <a href="mailto:ababich@us.ibm.com" title="IBM Corporation">A. Babich</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5323">Web Distributed Authoring and Versioning (WebDAV) SEARCH</a>&#8221;, RFC&nbsp;5323, November&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC5789">[RFC5789]</b></td><td class="top"><a href="mailto:lisa.dusseault@gmail.com" title="Linden Lab">Dusseault, L.</a> and <a href="mailto:jasnell@gmail.com">J. Snell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5789">PATCH Method for HTTP</a>&#8221;, RFC&nbsp;5789, March&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC5842">[RFC5842]</b></td><td class="top"><a href="mailto:geoffrey.clemm@us.ibm.com" title="IBM">Clemm, G.</a>, <a href="mailto:ccjason@us.ibm.com" title="IBM Research">Crawford, J.</a>, <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J., Ed.</a>, and <a href="mailto:ejw@cse.ucsc.edu" title="UC Santa Cruz, Dept. of Computer Science">J. Whitehead</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5842">Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;5842, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr></table><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1><p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p></div></body></html>
  • specs/rfc7237.xml

    r2721 r2725  
    5959  </abstract>
    6060 
    61   <note title="Editorial Note (To be removed by RFC Editor)">
    62     <t>
    63       Discussion of this draft takes place on the HTTPBIS working group
    64       mailing list (ietf-http-wg@w3.org), which is archived at
    65       <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
    66     </t>
    67     <t>
    68       The current issues list is at
    69       <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=method-registrations"/> and related
    70       documents (including fancy diffs) can be found at
    71       <eref target="http://tools.ietf.org/wg/httpbis/"/>.
    72     </t>
    73     <t>
    74       <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
    75     </t>
    76   </note>
    77 
    7861  </front>
    7962
Note: See TracChangeset for help on using the changeset viewer.