* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 2737


Ignore:
Timestamp:
2015-04-10 03:23:33 (2 weeks ago)
Author:
julian.reschke@gmx.de
Message:

update specs

Location:
specs
Files:
2 added
8 edited

Legend:

Unmodified
Added
Removed
  • specs/rfc7230.html

    r2736 r2737  
    525525    } 
    526526} 
    527 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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: <a class="self" href="#rfc.section.1.p.1">&para;</a></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></div><div id="rfc.section.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p>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.<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><div id="rfc.section.1.p.5"><p>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.<a class="self" href="#rfc.section.1.p.5">&para;</a></p></div><div id="rfc.section.1.p.6"><p>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.<a class="self" href="#rfc.section.1.p.6">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><div id="core.rules"><div id="rfc.section.1.2.p.2"><p>            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).<a class="self" href="#rfc.section.1.2.p.2">&para;</a></p></div></div><div id="rfc.section.1.2.p.3"><p>As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.<a class="self" href="#rfc.section.1.2.p.3">&para;</a></p></div></div></div><div id="architecture"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="operation"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#operation">Client/Server Messaging</a></h2><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><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.1"></div><div id="rfc.iref.s.2"></div><div id="rfc.iref.r.1"></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.section.2.1.p.3"><p>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).<a class="self" href="#rfc.section.2.1.p.3">&para;</a></p></div><div id="rfc.section.2.1.p.4"><p>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).<a class="self" href="#rfc.section.2.1.p.4">&para;</a></p></div><div id="rfc.figure.u.1"><pre class="drawing">         request   &gt; 
     527</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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: <a class="self" href="#rfc.section.1.p.1">&para;</a></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></div><div id="rfc.section.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p>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.<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><div id="rfc.section.1.p.5"><p>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.<a class="self" href="#rfc.section.1.p.5">&para;</a></p></div><div id="rfc.section.1.p.6"><p>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.<a class="self" href="#rfc.section.1.p.6">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>Conformance criteria and considerations regarding error handling are defined in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><div id="core.rules"><div id="rfc.section.1.2.p.2"><p>            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).<a class="self" href="#rfc.section.1.2.p.2">&para;</a></p></div></div><div id="rfc.section.1.2.p.3"><p>As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.<a class="self" href="#rfc.section.1.2.p.3">&para;</a></p></div></div></div><div id="architecture"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#architecture">Architecture</a></h1><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="operation"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#operation">Client/Server Messaging</a></h2><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><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.1"></div><div id="rfc.iref.s.2"></div><div id="rfc.iref.r.1"></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.section.2.1.p.3"><p>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).<a class="self" href="#rfc.section.2.1.p.3">&para;</a></p></div><div id="rfc.section.2.1.p.4"><p>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).<a class="self" href="#rfc.section.2.1.p.4">&para;</a></p></div><div id="rfc.figure.u.1"><pre class="drawing">         request   &gt; 
    528528    <b>UA</b> ======================================= <b>O</b> 
    529529                                &lt;   response 
  • specs/rfc7231.html

    r2736 r2737  
    525525    } 
    526526} 
    527 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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>).<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>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>).<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p><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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><div id="rfc.section.1.2.p.2"><p>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>.<a class="self" href="#rfc.section.1.2.p.2">&para;</a></p></div></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><div id="rfc.section.2.p.1"><p>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>.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>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>).<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div><div id="rfc.section.2.p.3"><p>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.<a class="self" href="#rfc.section.2.p.3">&para;</a></p></div></div><div id="representations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><div id="rfc.section.3.p.1"><p>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>.<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><div id="rfc.section.3.p.2"><p>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.<a class="self" href="#rfc.section.3.p.2">&para;</a></p></div><div id="rfc.section.3.p.3"><p>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>).<a class="self" href="#rfc.section.3.p.3">&para;</a></p></div><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><div id="rfc.section.3.1.p.1"><p>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.<a class="self" href="#rfc.section.3.1.p.1">&para;</a></p></div><div id="rfc.section.3.1.p.2"><p>The following header fields convey representation metadata:<a class="self" href="#rfc.section.3.1.p.2">&para;</a></p></div><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><div id="rfc.section.3.1.1.1.p.1"><p>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.<a class="self" href="#rfc.section.3.1.1.1.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> ) 
     527</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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>).<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>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>).<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p><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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><div id="rfc.section.1.2.p.2"><p>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>.<a class="self" href="#rfc.section.1.2.p.2">&para;</a></p></div></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><div id="rfc.section.2.p.1"><p>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>.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>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>).<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div><div id="rfc.section.2.p.3"><p>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.<a class="self" href="#rfc.section.2.p.3">&para;</a></p></div></div><div id="representations"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><div id="rfc.section.3.p.1"><p>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>.<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><div id="rfc.section.3.p.2"><p>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.<a class="self" href="#rfc.section.3.p.2">&para;</a></p></div><div id="rfc.section.3.p.3"><p>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>).<a class="self" href="#rfc.section.3.p.3">&para;</a></p></div><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><div id="rfc.section.3.1.p.1"><p>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.<a class="self" href="#rfc.section.3.1.p.1">&para;</a></p></div><div id="rfc.section.3.1.p.2"><p>The following header fields convey representation metadata:<a class="self" href="#rfc.section.3.1.p.2">&para;</a></p></div><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><div id="rfc.section.3.1.1.1.p.1"><p>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.<a class="self" href="#rfc.section.3.1.1.1.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> ) 
    528528  <a href="#media.type" class="smpl">type</a>       = <a href="#imported.abnf" class="smpl">token</a> 
    529529  <a href="#media.type" class="smpl">subtype</a>    = <a href="#imported.abnf" class="smpl">token</a> 
  • specs/rfc7232.html

    r2736 r2737  
    525525    } 
    526526} 
    527 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p><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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p>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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></div></div><div id="validators"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="weak.and.strong.validators"><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><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.section.2.1.p.3"><p>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.<a class="self" href="#rfc.section.2.1.p.3">&para;</a></p></div><div id="rfc.section.2.1.p.4"><p>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).<a class="self" href="#rfc.section.2.1.p.4">&para;</a></p></div><div id="rfc.section.2.1.p.5"><p>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.<a class="self" href="#rfc.section.2.1.p.5">&para;</a></p></div><div id="rfc.section.2.1.p.6"><p>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.<a class="self" href="#rfc.section.2.1.p.6">&para;</a></p></div><div id="rfc.section.2.1.p.7"><p>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.<a class="self" href="#rfc.section.2.1.p.7">&para;</a></p></div><div id="rfc.section.2.1.p.8"><p>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.<a class="self" href="#rfc.section.2.1.p.8">&para;</a></p></div><div id="rfc.section.2.1.p.9"><p>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.<a class="self" href="#rfc.section.2.1.p.9">&para;</a></p></div></div><div id="header.last-modified"><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><div id="rfc.section.2.2.p.1"><p>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.<a class="self" href="#rfc.section.2.2.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
     527</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p><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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><div id="rfc.section.1.p.4"><p>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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></div></div><div id="validators"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="weak.and.strong.validators"><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><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.section.2.1.p.3"><p>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.<a class="self" href="#rfc.section.2.1.p.3">&para;</a></p></div><div id="rfc.section.2.1.p.4"><p>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).<a class="self" href="#rfc.section.2.1.p.4">&para;</a></p></div><div id="rfc.section.2.1.p.5"><p>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.<a class="self" href="#rfc.section.2.1.p.5">&para;</a></p></div><div id="rfc.section.2.1.p.6"><p>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.<a class="self" href="#rfc.section.2.1.p.6">&para;</a></p></div><div id="rfc.section.2.1.p.7"><p>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.<a class="self" href="#rfc.section.2.1.p.7">&para;</a></p></div><div id="rfc.section.2.1.p.8"><p>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.<a class="self" href="#rfc.section.2.1.p.8">&para;</a></p></div><div id="rfc.section.2.1.p.9"><p>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.<a class="self" href="#rfc.section.2.1.p.9">&para;</a></p></div></div><div id="header.last-modified"><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><div id="rfc.section.2.2.p.1"><p>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.<a class="self" href="#rfc.section.2.2.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
    528528</pre></div><div id="rfc.section.2.2.p.2"><p>An example of its use is<a class="self" href="#rfc.section.2.2.p.2">&para;</a></p></div><div id="rfc.figure.u.2"><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 
    529529</pre></div><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><div id="rfc.section.2.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.2.1.p.1">&para;</a></p></div><div id="rfc.section.2.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.2.1.p.2">&para;</a></p></div><div id="rfc.section.2.2.1.p.3"><p>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.<a class="self" href="#rfc.section.2.2.1.p.3">&para;</a></p></div><div id="rfc.section.2.2.1.p.4"><p>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.<a class="self" href="#rfc.section.2.2.1.p.4">&para;</a></p></div><div id="rfc.section.2.2.1.p.5"><p>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.<a class="self" href="#rfc.section.2.2.1.p.5">&para;</a></p></div></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><div id="rfc.section.2.2.2.p.1"><p>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: <a class="self" href="#rfc.section.2.2.2.p.1">&para;</a></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></div><div id="rfc.section.2.2.2.p.2"><p>or <a class="self" href="#rfc.section.2.2.2.p.2">&para;</a></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></div><div id="rfc.section.2.2.2.p.3"><p>or <a class="self" href="#rfc.section.2.2.2.p.3">&para;</a></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></div><div id="rfc.section.2.2.2.p.4"><p>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.<a class="self" href="#rfc.section.2.2.2.p.4">&para;</a></p></div></div></div><div id="header.etag"><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a href="#header.etag">ETag</a></h2><div id="rfc.section.2.3.p.1"><p>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.<a class="self" href="#rfc.section.2.3.p.1">&para;</a></p></div><div id="rfc.figure.u.3"><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/rfc7233.html

    r2736 r2737  
    525525    } 
    526526} 
    527 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
     527</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.section.1.p.3"><p>Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
    528528</pre></div><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><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><div id="rfc.figure.u.2"><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#byte.ranges" class="smpl">bytes-unit</a>       = "bytes" 
    529529</pre></div><div id="rule.ranges-specifier"><div id="rfc.section.2.1.p.2"><p>        A byte-range request can specify a single range of bytes or a set of ranges within a single representation.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div></div><div id="rfc.figure.u.3"><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/rfc7234.html

    r2736 r2737  
    528528    } 
    529529} 
    530 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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;);"><table class="header" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.iref.c.1"></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><div id="rfc.section.1.p.3"><p>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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div></div><div id="rfc.section.1.p.4"><p>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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><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><div id="rfc.section.1.2.1.p.1"><p>The delta-seconds rule specifies a non-negative integer, representing time in seconds.<a class="self" href="#rfc.section.1.2.1.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
     530</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="Authoritative 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.718, 2015/04/08 13:10:26, 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;);"><table class="header" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.iref.c.1"></div><div id="rfc.section.1.p.2"><p>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.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><div id="rfc.section.1.p.3"><p>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.<a class="self" href="#rfc.section.1.p.3">&para;</a></p></div></div><div id="rfc.section.1.p.4"><p>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>).<a class="self" href="#rfc.section.1.p.4">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div><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><div id="rfc.section.1.2.1.p.1"><p>The delta-seconds rule specifies a non-negative integer, representing time in seconds.<a class="self" href="#rfc.section.1.2.1.p.1">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
    531531</pre></div><div id="rfc.section.1.2.1.p.2"><p>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.<a class="self" href="#rfc.section.1.2.1.p.2">&para;</a></p></div><div class="note"><div id="rfc.section.1.2.1.p.3"><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.<a class="self" href="#rfc.section.1.2.1.p.3">&para;</a></p></div></div></div></div></div><div id="caching.overview"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></h1><div id="rfc.section.2.p.1"><p>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.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>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.<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div><div id="rfc.iref.c.2"></div><div id="rfc.section.2.p.3"><p>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.<a class="self" href="#rfc.section.2.p.3">&para;</a></p></div><div id="rfc.section.2.p.4"><p>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>).<a class="self" href="#rfc.section.2.p.4">&para;</a></p></div></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><div id="rfc.section.3.p.1"><p>A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: <a class="self" href="#rfc.section.3.p.1">&para;</a></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></div><div id="rfc.section.3.p.2"><p>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>.<a class="self" href="#rfc.section.3.p.2">&para;</a></p></div><div id="rfc.section.3.p.3"><p>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.<a class="self" href="#rfc.section.3.p.3">&para;</a></p></div><div id="rfc.section.3.p.4"><p>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.<a class="self" href="#rfc.section.3.p.4">&para;</a></p></div><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><div id="rfc.section.3.1.p.1"><p>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 
    532532   (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.<a class="self" href="#rfc.section.3.1.p.1">&para;</a></p></div><div id="rfc.section.3.1.p.2"><p>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.<a class="self" href="#rfc.section.3.1.p.2">&para;</a></p></div></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><div id="rfc.section.3.2.p.1"><p>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.<a class="self" href="#rfc.section.3.2.p.1">&para;</a></p></div><div id="rfc.section.3.2.p.2"><p>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.<a class="self" href="#rfc.section.3.2.p.2">&para;</a></p></div><div id="rfc.section.3.2.p.3"><p>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.<a class="self" href="#rfc.section.3.2.p.3">&para;</a></p></div></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><div id="rfc.section.3.3.p.1"><p>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>.<a class="self" href="#rfc.section.3.3.p.1">&para;</a></p></div><div id="rfc.section.3.3.p.2"><p>When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: <a class="self" href="#rfc.section.3.3.p.2">&para;</a></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><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><div id="rfc.section.4.p.1"><p>When presented with a request, a cache <em class="bcp14">MUST NOT</em> reuse a stored response, unless: <a class="self" href="#rfc.section.4.p.1">&para;</a></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></div><div id="rfc.section.4.p.2"><p>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>.<a class="self" href="#rfc.section.4.p.2">&para;</a></p></div><div id="rfc.section.4.p.3"><p>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>.<a class="self" href="#rfc.section.4.p.3">&para;</a></p></div><div id="rfc.section.4.p.4"><p>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.<a class="self" href="#rfc.section.4.p.4">&para;</a></p></div><div id="rfc.section.4.p.5"><p>Also, note that unsafe requests might invalidate already-stored responses; see <a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>.<a class="self" href="#rfc.section.4.p.5">&para;</a></p></div><div id="rfc.section.4.p.6"><p>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.<a class="self" href="#rfc.section.4.p.6">&para;</a></p></div><div id="rfc.section.4.p.7"><p>A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them upon every use.<a class="self" href="#rfc.section.4.p.7">&para;</a></p></div><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><div id="rfc.section.4.1.p.1"><p>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.<a class="self" href="#rfc.section.4.1.p.1">&para;</a></p></div><div id="rfc.section.4.1.p.2"><p>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: <a class="self" href="#rfc.section.4.1.p.2">&para;</a></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></div><div id="rfc.section.4.1.p.3"><p>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.<a class="self" href="#rfc.section.4.1.p.3">&para;</a></p></div><div id="rfc.section.4.1.p.4"><p>A <a href="rfc7231.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.<a class="self" href="#rfc.section.4.1.p.4">&para;</a></p></div><div id="rfc.section.4.1.p.5"><p>The stored response with matching selecting header fields is known as the selected response.<a class="self" href="#rfc.section.4.1.p.5">&para;</a></p></div><div id="rfc.section.4.1.p.6"><p>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>.<a class="self" href="#rfc.section.4.1.p.6">&para;</a></p></div><div id="rfc.section.4.1.p.7"><p>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.<a class="self" href="#rfc.section.4.1.p.7">&para;</a></p></div></div><div id="expiration.model"><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#expiration.model">Freshness</a></h2><div id="rfc.section.4.2.p.1"><p>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.<a class="self" href="#rfc.section.4.2.p.1">&para;</a></p></div><div id="rfc.iref.f.1"></div><div id="rfc.iref.e.1"></div><div id="rfc.iref.h.1"></div><div id="rfc.section.4.2.p.2"><p>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.<a class="self" href="#rfc.section.4.2.p.2">&para;</a></p></div><div id="rfc.iref.a.1"></div><div id="rfc.section.4.2.p.3"><p>A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.<a class="self" href="#rfc.section.4.2.p.3">&para;</a></p></div><div id="rfc.section.4.2.p.4"><p>When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.<a class="self" href="#rfc.section.4.2.p.4">&para;</a></p></div><div id="rfc.section.4.2.p.5"><p>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.<a class="self" href="#rfc.section.4.2.p.5">&para;</a></p></div><div id="rfc.section.4.2.p.6"><p>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>).<a class="self" href="#rfc.section.4.2.p.6">&para;</a></p></div><div id="rfc.section.4.2.p.7"><p>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>).<a class="self" href="#rfc.section.4.2.p.7">&para;</a></p></div><div id="rfc.figure.u.2"><p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age) 
  • specs/rfc7235.html

    r2736 r2737  
    525525    } 
    526526} 
    527 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></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><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
     527</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div><div id="rfc.section.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.p.2">&para;</a></p></div><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><div id="rfc.section.1.1.p.1"><p>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>.<a class="self" href="#rfc.section.1.1.p.1">&para;</a></p></div><div id="rfc.section.1.1.p.2"><p>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>.<a class="self" href="#rfc.section.1.1.p.2">&para;</a></p></div></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><div id="rfc.section.1.2.p.1"><p>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.<a class="self" href="#rfc.section.1.2.p.1">&para;</a></p></div></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><div id="rfc.section.2.1.p.1"><p>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.<a class="self" href="#rfc.section.2.1.p.1">&para;</a></p></div><div id="rfc.section.2.1.p.2"><p>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.<a class="self" href="#rfc.section.2.1.p.2">&para;</a></p></div><div id="rfc.figure.u.1"><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> 
    528528   
    529529  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/rfc7236.html

    r2736 r2737  
    494494    } 
    495495} 
    496 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>There are no security considerations related to the registration itself.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>Security considerations applicable to the individual authentication schemes ought to be discussed in the specifications that define them.<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div></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><div id="rfc.section.3.p.1"><p>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>).<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><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">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">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">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de">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="avoidbreakinside"><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> 
     496</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>There are no security considerations related to the registration itself.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>Security considerations applicable to the individual authentication schemes ought to be discussed in the specifications that define them.<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div></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><div id="rfc.section.3.p.1"><p>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>).<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><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">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">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">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de">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="avoidbreakinside"><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.html

    r2736 r2737  
    494494    } 
    495495} 
    496 </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="Authoritative 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.717, 2015/03/23 17:14:43, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>There are no security considerations related to the registration itself.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>Security considerations applicable to the individual HTTP methods ought to be discussed in the specifications that define them.<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div></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><div id="rfc.section.3.p.1"><p>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>).<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><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">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org">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">Clemm, G.</a>, <a href="mailto:jamsden@us.ibm.com">Amsden, J.</a>, <a href="mailto:tim_ellison@uk.ibm.com">Ellison, T.</a>, <a href="mailto:ckaler@microsoft.com">Kaler, C.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Whitehead, J.</a> and <a href="mailto:julian.reschke@greenbytes.de">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">Clemm, G.</a>, <a href="mailto:julian.reschke@greenbytes.de">Reschke, J.</a>, <a href="mailto:eric.sedlar@oracle.com">Sedlar, E.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Whitehead, J.</a>, <a href="mailto:geoffrey.clemm@us.ibm.com">Clemm, G.</a>, and <a href="mailto:julian.reschke@greenbytes.de">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">Daboo, C.</a>, <a href="mailto:bernard.desruisseaux@oracle.com">Desruisseaux, B.</a>, and <a href="mailto:ldusseault@commerce.net">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">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">Reschke, J., Ed.</a>, <a href="mailto:Surendra.Reddy@mitrix.com">Reddy, S.</a>, <a href="mailto:jrd3@alum.mit.edu">Davis, J.</a>, and <a href="mailto:ababich@us.ibm.com">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">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">Clemm, G.</a>, <a href="mailto:ccjason@us.ibm.com">Crawford, J.</a>, <a href="mailto:julian.reschke@greenbytes.de">Reschke, J., Ed.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de">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="avoidbreakinside"><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> 
     496</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="Authoritative 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.718, 2015/04/08 13:10:26, 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" id="rfc.headerblock"><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" id="rfc.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"><div id="rfc.toc"><h1 class="np"><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><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><div id="rfc.section.1.p.1"><p>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.<a class="self" href="#rfc.section.1.p.1">&para;</a></p></div></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><div id="rfc.section.2.p.1"><p>There are no security considerations related to the registration itself.<a class="self" href="#rfc.section.2.p.1">&para;</a></p></div><div id="rfc.section.2.p.2"><p>Security considerations applicable to the individual HTTP methods ought to be discussed in the specifications that define them.<a class="self" href="#rfc.section.2.p.2">&para;</a></p></div></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><div id="rfc.section.3.p.1"><p>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>).<a class="self" href="#rfc.section.3.p.1">&para;</a></p></div><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">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org">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">Clemm, G.</a>, <a href="mailto:jamsden@us.ibm.com">Amsden, J.</a>, <a href="mailto:tim_ellison@uk.ibm.com">Ellison, T.</a>, <a href="mailto:ckaler@microsoft.com">Kaler, C.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Whitehead, J.</a> and <a href="mailto:julian.reschke@greenbytes.de">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">Clemm, G.</a>, <a href="mailto:julian.reschke@greenbytes.de">Reschke, J.</a>, <a href="mailto:eric.sedlar@oracle.com">Sedlar, E.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Whitehead, J.</a>, <a href="mailto:geoffrey.clemm@us.ibm.com">Clemm, G.</a>, and <a href="mailto:julian.reschke@greenbytes.de">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">Daboo, C.</a>, <a href="mailto:bernard.desruisseaux@oracle.com">Desruisseaux, B.</a>, and <a href="mailto:ldusseault@commerce.net">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">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">Reschke, J., Ed.</a>, <a href="mailto:Surendra.Reddy@mitrix.com">Reddy, S.</a>, <a href="mailto:jrd3@alum.mit.edu">Davis, J.</a>, and <a href="mailto:ababich@us.ibm.com">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">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">Clemm, G.</a>, <a href="mailto:ccjason@us.ibm.com">Crawford, J.</a>, <a href="mailto:julian.reschke@greenbytes.de">Reschke, J., Ed.</a>, and <a href="mailto:ejw@cse.ucsc.edu">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">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de">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="avoidbreakinside"><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> 
Note: See TracChangeset for help on using the changeset viewer.