Changeset 2726 for specs


Ignore:
Timestamp:
14/06/14 11:20:37 (6 years ago)
Author:
julian.reschke@…
Message:

update to latest version of rfc2629.xslt, regen all HTML

Location:
specs
Files:
8 edited

Legend:

Unmodified
Added
Removed
  • specs/rfc7230.html

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

    r2725 r2726  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Resources" href="#rfc.section.2"><link rel="Chapter" title="3 Representations" href="#rfc.section.3"><link rel="Chapter" title="4 Request Methods" href="#rfc.section.4"><link rel="Chapter" title="5 Request Header Fields" href="#rfc.section.5"><link rel="Chapter" title="6 Response Status Codes" href="#rfc.section.6"><link rel="Chapter" title="7 Response Header Fields" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7230.html" rel="prev"><link href="rfc7232.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7231.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7231"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7231"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7231"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."></head><body onload="getMeta(7231,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7231</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resources">Resources</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representations">Representations</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.metadata">Representation Metadata</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing Representation Data</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#data.encoding">Encoding for Compression or Integrity</a></li><li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#audience.language">Audience Language</a></li><li><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#identification">Identification</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Payload Semantics</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul><li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li><li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li></ul></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#methods">Request Methods</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.overview">Overview</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.properties">Common Method Properties</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li><li><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li><li><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li><li><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li></ul></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#request.header.fields">Request Header Fields</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#request.conditionals">Conditionals</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request.conneg">Content Negotiation</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li><li><a href="#rfc.section.5.3.5">5.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#request.auth">Authentication Credentials</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.context">Request Context</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#status.codes">Response Status Codes</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.1xx">Informational 1xx</a><ul><li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.100">100 Continue</a></li><li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.101">101 Switching Protocols</a></li></ul></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.2xx">Successful 2xx</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.200">200 OK</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.201">201 Created</a></li><li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.202">202 Accepted</a></li><li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></li><li><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.204">204 No Content</a></li><li><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.205">205 Reset Content</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.3xx">Redirection 3xx</a><ul><li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.300">300 Multiple Choices</a></li><li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.301">301 Moved Permanently</a></li><li><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.302">302 Found</a></li><li><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.303">303 See Other</a></li><li><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.305">305 Use Proxy</a></li><li><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.306">306 (Unused)</a></li><li><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.307">307 Temporary Redirect</a></li></ul></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.4xx">Client Error 4xx</a><ul><li><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.400">400 Bad Request</a></li><li><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.402">402 Payment Required</a></li><li><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.403">403 Forbidden</a></li><li><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.404">404 Not Found</a></li><li><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.405">405 Method Not Allowed</a></li><li><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.406">406 Not Acceptable</a></li><li><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.408">408 Request Timeout</a></li><li><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#status.409">409 Conflict</a></li><li><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;&nbsp;&nbsp;<a href="#status.410">410 Gone</a></li><li><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;&nbsp;&nbsp;<a href="#status.411">411 Length Required</a></li><li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Payload Too Large</a></li><li><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li><li><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li><li><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;&nbsp;&nbsp;<a href="#status.417">417 Expectation Failed</a></li><li><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;&nbsp;&nbsp;<a href="#status.426">426 Upgrade Required</a></li></ul></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.5xx">Server Error 5xx</a><ul><li><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.500">500 Internal Server Error</a></li><li><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.501">501 Not Implemented</a></li><li><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.502">502 Bad Gateway</a></li><li><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.503">503 Service Unavailable</a></li><li><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.504">504 Gateway Timeout</a></li><li><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#response.control.data">Control Data</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#origination.date">Origination Date</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li><li><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#response.validator">Validator Header Fields</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#response.auth">Authentication Challenges</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.context">Response Context</a><ul><li><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li><li><a href="#rfc.section.7.4.2">7.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li></ul></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul><li><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li><li><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry">Status Code Registry</a><ul><li><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li><li><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registry">Header Field Registry</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Registrations</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based on File and Path Names</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.injection">Attacks Based on Command, Code, or Query Injection</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Disclosure of Personal Information</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#disclosure.product.information">Disclosure of Product Information</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#fingerprinting">Browser Fingerprinting</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li><li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-encoding">Conversion of Content-Encoding</a></li><li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></li><li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).</p><p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;7</a>).</p><p id="rfc.section.1.p.4"><span id="rfc.iref.c.1"></span> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "<dfn>content negotiation</dfn>" (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><p id="rfc.section.1.2.p.2">This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in <a href="#RFC6365" id="rfc.xref.RFC6365.1"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.</p></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><p id="rfc.section.2.p.1">The target of an HTTP request is called a "<dfn>resource</dfn>". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in <a href="rfc7230.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the <a href="rfc7230.html#target-resource" class="smpl">target URI</a> in one of various forms, as defined in (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). When a request is received, the server reconstructs an <a href="rfc7230.html#effective.request.uri" class="smpl">effective request URI</a> for the target resource (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, the method semantics take precedence.</p></div><div id="representations"><div id="rfc.iref.r.1"></div><div id="rfc.iref.s.1"></div><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.</p><p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.</p><p id="rfc.section.3.p.3">An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).</p><div id="representation.metadata"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#representation.metadata">Representation Metadata</a></h2><p id="rfc.section.3.1.p.1">Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.</p><p id="rfc.section.3.1.p.2">The following header fields convey representation metadata:</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">Content-Type</td><td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.1.1.5</a></td></tr><tr><td class="left">Content-Encoding</td><td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.1.2.2</a></td></tr><tr><td class="left">Content-Language</td><td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.1.3.2</a></td></tr><tr><td class="left">Content-Location</td><td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.1.4.2</a></td></tr></tbody></table></div><div id="data.type"><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a href="#data.type">Processing Representation Data</a></h3><div id="media.type"><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a href="#media.type">Media Type</a></h4><p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet media types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#media.type" class="smpl">media-type</a> = <a href="#media.type" class="smpl">type</a> "/" <a href="#media.type" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Resources" href="#rfc.section.2"><link rel="Chapter" title="3 Representations" href="#rfc.section.3"><link rel="Chapter" title="4 Request Methods" href="#rfc.section.4"><link rel="Chapter" title="5 Request Header Fields" href="#rfc.section.5"><link rel="Chapter" title="6 Response Status Codes" href="#rfc.section.6"><link rel="Chapter" title="7 Response Header Fields" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7230.html" rel="prev"><link href="rfc7232.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7231.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7231"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7231"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP semantics, HTTP payload, HTTP content, HTTP method, HTTP status code"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7231"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."></head><body onload="getMeta(7231,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7231</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resources">Resources</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representations">Representations</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.metadata">Representation Metadata</a><ul><li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing Representation Data</a></li><li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#data.encoding">Encoding for Compression or Integrity</a></li><li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#audience.language">Audience Language</a></li><li><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#identification">Identification</a></li></ul></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Payload Semantics</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul><li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li><li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li></ul></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#methods">Request Methods</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.overview">Overview</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#method.properties">Common Method Properties</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#safe.methods">Safe Methods</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.definitions">Method Definitions</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#GET">GET</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#HEAD">HEAD</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#POST">POST</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#PUT">PUT</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#DELETE">DELETE</a></li><li><a href="#rfc.section.4.3.6">4.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#CONNECT">CONNECT</a></li><li><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;&nbsp;&nbsp;<a href="#OPTIONS">OPTIONS</a></li><li><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;&nbsp;&nbsp;<a href="#TRACE">TRACE</a></li></ul></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#request.header.fields">Request Header Fields</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#request.controls">Controls</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.expect">Expect</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.max-forwards">Max-Forwards</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#request.conditionals">Conditionals</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#request.conneg">Content Negotiation</a><ul><li><a href="#rfc.section.5.3.1">5.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li><li><a href="#rfc.section.5.3.2">5.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li><li><a href="#rfc.section.5.3.3">5.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li><li><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li><li><a href="#rfc.section.5.3.5">5.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li></ul></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#request.auth">Authentication Credentials</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#request.context">Request Context</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.from">From</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.referer">Referer</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.user-agent">User-Agent</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#status.codes">Response Status Codes</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.1xx">Informational 1xx</a><ul><li><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.100">100 Continue</a></li><li><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.101">101 Switching Protocols</a></li></ul></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.2xx">Successful 2xx</a><ul><li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.200">200 OK</a></li><li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.201">201 Created</a></li><li><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.202">202 Accepted</a></li><li><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></li><li><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.204">204 No Content</a></li><li><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.205">205 Reset Content</a></li></ul></li><li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.3xx">Redirection 3xx</a><ul><li><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.300">300 Multiple Choices</a></li><li><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.301">301 Moved Permanently</a></li><li><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.302">302 Found</a></li><li><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.303">303 See Other</a></li><li><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.305">305 Use Proxy</a></li><li><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.306">306 (Unused)</a></li><li><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.307">307 Temporary Redirect</a></li></ul></li><li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.4xx">Client Error 4xx</a><ul><li><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.400">400 Bad Request</a></li><li><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.402">402 Payment Required</a></li><li><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.403">403 Forbidden</a></li><li><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.404">404 Not Found</a></li><li><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.405">405 Method Not Allowed</a></li><li><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.406">406 Not Acceptable</a></li><li><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#status.408">408 Request Timeout</a></li><li><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;&nbsp;&nbsp;<a href="#status.409">409 Conflict</a></li><li><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;&nbsp;&nbsp;<a href="#status.410">410 Gone</a></li><li><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;&nbsp;&nbsp;<a href="#status.411">411 Length Required</a></li><li><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Payload Too Large</a></li><li><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li><li><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li><li><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;&nbsp;&nbsp;<a href="#status.417">417 Expectation Failed</a></li><li><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;&nbsp;&nbsp;<a href="#status.426">426 Upgrade Required</a></li></ul></li><li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.5xx">Server Error 5xx</a><ul><li><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.500">500 Internal Server Error</a></li><li><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.501">501 Not Implemented</a></li><li><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.502">502 Bad Gateway</a></li><li><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.503">503 Service Unavailable</a></li><li><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;&nbsp;&nbsp;<a href="#status.504">504 Gateway Timeout</a></li><li><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;&nbsp;&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#response.control.data">Control Data</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#origination.date">Origination Date</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li><li><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#response.validator">Validator Header Fields</a></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#response.auth">Authentication Challenges</a></li><li><a href="#rfc.section.7.4">7.4</a>&nbsp;&nbsp;&nbsp;<a href="#response.context">Response Context</a><ul><li><a href="#rfc.section.7.4.1">7.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.allow">Allow</a></li><li><a href="#rfc.section.7.4.2">7.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.server">Server</a></li></ul></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry">Method Registry</a><ul><li><a href="#rfc.section.8.1.1">8.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#method.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.1.2">8.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.methods">Considerations for New Methods</a></li><li><a href="#rfc.section.8.1.3">8.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#method.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry">Status Code Registry</a><ul><li><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li><li><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.3">8.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registry">Header Field Registry</a><ul><li><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></li><li><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.8.4">8.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a><ul><li><a href="#rfc.section.8.4.1">8.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.procedure">Procedure</a></li><li><a href="#rfc.section.8.4.2">8.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Registrations</a></li></ul></li></ul></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.9.1">9.1</a>&nbsp;&nbsp;&nbsp;<a href="#attack.pathname">Attacks Based on File and Path Names</a></li><li><a href="#rfc.section.9.2">9.2</a>&nbsp;&nbsp;&nbsp;<a href="#attack.injection">Attacks Based on Command, Code, or Query Injection</a></li><li><a href="#rfc.section.9.3">9.3</a>&nbsp;&nbsp;&nbsp;<a href="#personal.information">Disclosure of Personal Information</a></li><li><a href="#rfc.section.9.4">9.4</a>&nbsp;&nbsp;&nbsp;<a href="#sensitive.information.in.uris">Disclosure of Sensitive Information in URIs</a></li><li><a href="#rfc.section.9.5">9.5</a>&nbsp;&nbsp;&nbsp;<a href="#fragment.disclosure">Disclosure of Fragment after Redirects</a></li><li><a href="#rfc.section.9.6">9.6</a>&nbsp;&nbsp;&nbsp;<a href="#disclosure.product.information">Disclosure of Product Information</a></li><li><a href="#rfc.section.9.7">9.7</a>&nbsp;&nbsp;&nbsp;<a href="#fingerprinting">Browser Fingerprinting</a></li></ul></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.11">11.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.11.1">11.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.11.2">11.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul><li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li><li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li><li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-encoding">Conversion of Content-Encoding</a></li><li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.content-transfer-encoding">Conversion of Content-Transfer-Encoding</a></li><li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li></ul></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).</p><p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section&nbsp;7</a>).</p><p id="rfc.section.1.p.4"><span id="rfc.iref.c.1"></span> This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "<dfn>content negotiation</dfn>" (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><p id="rfc.section.1.2.p.2">This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in <a href="#RFC6365" id="rfc.xref.RFC6365.1"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.</p></div></div><div id="resources"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#resources">Resources</a></h1><p id="rfc.section.2.p.1">The target of an HTTP request is called a "<dfn>resource</dfn>". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in <a href="rfc7230.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the <a href="rfc7230.html#target-resource" class="smpl">target URI</a> in one of various forms, as defined in (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). When a request is received, the server reconstructs an <a href="rfc7230.html#effective.request.uri" class="smpl">effective request URI</a> for the target resource (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>) and a few request-modifying header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, the method semantics take precedence.</p></div><div id="representations"><div id="rfc.iref.r.1"></div><div id="rfc.iref.s.1"></div><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1><p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.</p><p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.</p><p id="rfc.section.3.p.3">An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).</p><div id="representation.metadata"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#representation.metadata">Representation Metadata</a></h2><p id="rfc.section.3.1.p.1">Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.</p><p id="rfc.section.3.1.p.2">The following header fields convey representation metadata:</p><div id="rfc.table.u.1"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">Content-Type</td><td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.1.1.5</a></td></tr><tr><td class="left">Content-Encoding</td><td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.1.2.2</a></td></tr><tr><td class="left">Content-Language</td><td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.1.3.2</a></td></tr><tr><td class="left">Content-Location</td><td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.1.4.2</a></td></tr></tbody></table></div><div id="data.type"><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a href="#data.type">Processing Representation Data</a></h3><div id="media.type"><h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a href="#media.type">Media Type</a></h4><p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet media types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#media.type" class="smpl">media-type</a> = <a href="#media.type" class="smpl">type</a> "/" <a href="#media.type" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
    505505  <a href="#media.type" class="smpl">type</a>       = <a href="#imported.abnf" class="smpl">token</a>
    506506  <a href="#media.type" class="smpl">subtype</a>    = <a href="#imported.abnf" class="smpl">token</a>
     
    531531Proxy-Authorization: basic aGVsbG86d29ybGQ=
    532532
    533 </pre><p id="rfc.section.4.3.6.p.9">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.</p><p id="rfc.section.4.3.6.p.10">A server <em class="bcp14">MUST NOT</em> send any <a href="rfc7230.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header fields in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.</p><p id="rfc.section.4.3.6.p.11">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.</p><p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p></div><div id="OPTIONS"><h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a href="#OPTIONS">OPTIONS</a></h3><div id="rfc.iref.o.1"></div><p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.</p><p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).</p><p id="rfc.section.4.3.7.p.3">If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.</p><p id="rfc.section.4.3.7.p.4">A server generating a successful response to OPTIONS <em class="bcp14">SHOULD</em> send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server <em class="bcp14">MUST</em> generate a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> field with a value of "0" if no payload body is to be sent in the response.</p><p id="rfc.section.4.3.7.p.5">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.2</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.</p><p id="rfc.section.4.3.7.p.6">A client that generates an OPTIONS request containing a payload body <em class="bcp14">MUST</em> send a valid <a href="#header.content-type" class="smpl">Content-Type</a> header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.</p><p id="rfc.section.4.3.7.p.7">Responses to the OPTIONS method are not cacheable.</p></div><div id="TRACE"><h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a href="#TRACE">TRACE</a></h3><div id="rfc.iref.t.1"></div><p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="rfc7230.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).</p><p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.</p><p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the <a href="rfc7230.html#header.via" class="smpl">Via</a> header field (<a href="rfc7230.html#header.via" title="Via">Section 5.7.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.</p><p id="rfc.section.4.3.8.p.4">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request.</p><p id="rfc.section.4.3.8.p.5">Responses to the TRACE method are not cacheable.</p></div></div></div><div id="request.header.fields"><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#request.header.fields">Request Header Fields</a></h1><p id="rfc.section.5.p.1">A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing. These fields act as request modifiers, similar to the parameters on a programming language method invocation.</p><div id="request.controls"><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#request.controls">Controls</a></h2><p id="rfc.section.5.1.p.1">Controls are request header fields that direct specific handling of the request.</p><div id="rfc.table.u.3"><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">Cache-Control</td><td class="left"><a href="rfc7234.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Expect</td><td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;5.1.1</a></td></tr><tr><td class="left">Host</td><td class="left"><a href="rfc7230.html#header.host" title="Host">Section 5.4</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a></td></tr><tr><td class="left">Max-Forwards</td><td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;5.1.2</a></td></tr><tr><td class="left">Pragma</td><td class="left"><a href="rfc7234.html#header.pragma" title="Pragma">Section 5.4</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Range</td><td class="left"><a href="rfc7233.html#header.range" title="Range">Section 3.1</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">TE</td><td class="left"><a href="rfc7230.html#header.te" title="TE">Section 4.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a></td></tr></tbody></table></div><div id="header.expect"><div id="rfc.iref.e.1"></div><div id="rfc.iref.38"></div><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a href="#header.expect">Expect</a></h3><p id="rfc.section.5.1.1.p.1">The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request. The only such expectation defined by this specification is <a href="#header.expect" class="smpl">100-continue</a>.</p><div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#header.expect" class="smpl">Expect</a>  = "100-continue"
     533</pre><p id="rfc.section.4.3.6.p.9">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.</p><p id="rfc.section.4.3.6.p.10">A server <em class="bcp14">MUST NOT</em> send any <a href="rfc7230.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header fields in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.</p><p id="rfc.section.4.3.6.p.11">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.</p><p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p></div><div id="OPTIONS"><h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a href="#OPTIONS">OPTIONS</a></h3><div id="rfc.iref.o.1"></div><p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.</p><p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).</p><p id="rfc.section.4.3.7.p.3">If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.</p><p id="rfc.section.4.3.7.p.4">A server generating a successful response to OPTIONS <em class="bcp14">SHOULD</em> send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server <em class="bcp14">MUST</em> generate a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> field with a value of "0" if no payload body is to be sent in the response.</p><p id="rfc.section.4.3.7.p.5">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.2</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.</p><p id="rfc.section.4.3.7.p.6">A client that generates an OPTIONS request containing a payload body <em class="bcp14">MUST</em> send a valid <a href="#header.content-type" class="smpl">Content-Type</a> header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.</p><p id="rfc.section.4.3.7.p.7">Responses to the OPTIONS method are not cacheable.</p></div><div id="TRACE"><h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a href="#TRACE">TRACE</a></h3><div id="rfc.iref.t.1"></div><p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="rfc7230.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).</p><p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient of the request <em class="bcp14">SHOULD</em> exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.</p><p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the <a href="rfc7230.html#header.via" class="smpl">Via</a> header field (<a href="rfc7230.html#header.via" title="Via">Section 5.7.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.</p><p id="rfc.section.4.3.8.p.4">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request.</p><p id="rfc.section.4.3.8.p.5">Responses to the TRACE method are not cacheable.</p></div></div></div><div id="request.header.fields"><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#request.header.fields">Request Header Fields</a></h1><p id="rfc.section.5.p.1">A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing. These fields act as request modifiers, similar to the parameters on a programming language method invocation.</p><div id="request.controls"><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#request.controls">Controls</a></h2><p id="rfc.section.5.1.p.1">Controls are request header fields that direct specific handling of the request.</p><div id="rfc.table.u.3"><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">Cache-Control</td><td class="left"><a href="rfc7234.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Expect</td><td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;5.1.1</a></td></tr><tr><td class="left">Host</td><td class="left"><a href="rfc7230.html#header.host" title="Host">Section 5.4</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a></td></tr><tr><td class="left">Max-Forwards</td><td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;5.1.2</a></td></tr><tr><td class="left">Pragma</td><td class="left"><a href="rfc7234.html#header.pragma" title="Pragma">Section 5.4</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Range</td><td class="left"><a href="rfc7233.html#header.range" title="Range">Section 3.1</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">TE</td><td class="left"><a href="rfc7230.html#header.te" title="TE">Section 4.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a></td></tr></tbody></table></div><div id="header.expect"><div id="rfc.iref.e.1"></div><div id="rfc.iref.1.1"></div><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a href="#header.expect">Expect</a></h3><p id="rfc.section.5.1.1.p.1">The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request. The only such expectation defined by this specification is <a href="#header.expect" class="smpl">100-continue</a>.</p><div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#header.expect" class="smpl">Expect</a>  = "100-continue"
    534534</pre><p id="rfc.section.5.1.1.p.3">The Expect field-value is case-insensitive.</p><p id="rfc.section.5.1.1.p.4">A server that receives an Expect field-value other than <a href="#header.expect" class="smpl">100-continue</a> <em class="bcp14">MAY</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code to indicate that the unexpected expectation cannot be met.</p><p id="rfc.section.5.1.1.p.5">A <dfn>100-continue</dfn> expectation informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a <a href="#status.100" class="smpl">100 (Continue)</a> interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error response. This allows the client to wait for an indication that it is worthwhile to send the message body before actually doing so, which can improve efficiency when the message body is huge or when the client anticipates that an error is likely (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).</p><p id="rfc.section.5.1.1.p.6">For example, a request that begins with</p><div id="rfc.figure.u.21"></div><pre class="text2">PUT /somewhere/fun HTTP/1.1
    535535Host: origin.example.com
     
    579579  <a href="#header.user-agent" class="smpl">product-version</a> = <a href="#imported.abnf" class="smpl">token</a>
    580580</pre><p id="rfc.section.5.5.3.p.5">A sender <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; a sender <em class="bcp14">MUST NOT</em> generate advertising or other nonessential information within the product identifier. A sender <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought to differ only in the product-version portion of the product identifier).</p><p id="rfc.section.5.5.3.p.6">Example:</p><div id="rfc.figure.u.41"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    581 </pre><p id="rfc.section.5.5.3.p.8">A user agent <em class="bcp14">SHOULD NOT</em> generate a User-Agent field containing needlessly fine-grained detail and <em class="bcp14">SHOULD</em> limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting").</p><p id="rfc.section.5.5.3.p.9">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.</p></div></div></div><div id="status.codes"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#status.codes">Response Status Codes</a></h1><p id="rfc.section.6.p.1">The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.</p><p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient <em class="bcp14">MUST NOT</em> cache a response with an unrecognized status code.</p><p id="rfc.section.6.p.3">For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a <a href="#status.400" class="smpl">400 (Bad Request)</a> status code. The response message will usually contain a representation that explains the status.</p><p id="rfc.section.6.p.4">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit: </p><ul><li><a href="#status.1xx" class="smpl">1xx (Informational)</a>: The request was received, continuing process</li><li><a href="#status.2xx" class="smpl">2xx (Successful)</a>: The request was successfully received, understood, and accepted</li><li><a href="#status.3xx" class="smpl">3xx (Redirection)</a>: Further action needs to be taken in order to complete the request</li><li><a href="#status.4xx" class="smpl">4xx (Client Error)</a>: The request contains bad syntax or cannot be fulfilled</li><li><a href="#status.5xx" class="smpl">5xx (Server Error)</a>: The server failed to fulfill an apparently valid request</li></ul><div id="overview.of.status.codes"><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></h2><p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="rfc7232.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>, <a href="rfc7233.html#range.response" title="Responses to a Range Request">Section 4</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>, and <a href="rfc7235.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>. The reason phrases listed here are only recommendations &#8212; they can be replaced by local equivalents without affecting the protocol.</p><p id="rfc.section.6.1.p.2">Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls <a href="#RFC7234" id="rfc.xref.RFC7234.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>; all other status codes are not cacheable by default.</p><div id="rfc.table.u.9"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Code</th><th>Reason-Phrase</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">100</td><td class="left">Continue</td><td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a></td></tr><tr><td class="left">101</td><td class="left">Switching Protocols</td><td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section&nbsp;6.2.2</a></td></tr><tr><td class="left">200</td><td class="left">OK</td><td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section&nbsp;6.3.1</a></td></tr><tr><td class="left">201</td><td class="left">Created</td><td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section&nbsp;6.3.2</a></td></tr><tr><td class="left">202</td><td class="left">Accepted</td><td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section&nbsp;6.3.3</a></td></tr><tr><td class="left">203</td><td class="left">Non-Authoritative Information</td><td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section&nbsp;6.3.4</a></td></tr><tr><td class="left">204</td><td class="left">No Content</td><td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section&nbsp;6.3.5</a></td></tr><tr><td class="left">205</td><td class="left">Reset Content</td><td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section&nbsp;6.3.6</a></td></tr><tr><td class="left">206</td><td class="left">Partial Content</td><td id="status.206" class="left"><a href="rfc7233.html#status.206" title="206 Partial Content">Section 4.1</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">300</td><td class="left">Multiple Choices</td><td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section&nbsp;6.4.1</a></td></tr><tr><td class="left">301</td><td class="left">Moved Permanently</td><td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section&nbsp;6.4.2</a></td></tr><tr><td class="left">302</td><td class="left">Found</td><td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section&nbsp;6.4.3</a></td></tr><tr><td class="left">303</td><td class="left">See Other</td><td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section&nbsp;6.4.4</a></td></tr><tr><td class="left">304</td><td class="left">Not Modified</td><td id="status.304" class="left"><a href="rfc7232.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></td></tr><tr><td class="left">305</td><td class="left">Use Proxy</td><td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section&nbsp;6.4.5</a></td></tr><tr><td class="left">307</td><td class="left">Temporary Redirect</td><td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section&nbsp;6.4.7</a></td></tr><tr><td class="left">400</td><td class="left">Bad Request</td><td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section&nbsp;6.5.1</a></td></tr><tr><td class="left">401</td><td class="left">Unauthorized</td><td id="status.401" class="left"><a href="rfc7235.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></td></tr><tr><td class="left">402</td><td class="left">Payment Required</td><td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section&nbsp;6.5.2</a></td></tr><tr><td class="left">403</td><td class="left">Forbidden</td><td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section&nbsp;6.5.3</a></td></tr><tr><td class="left">404</td><td class="left">Not Found</td><td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section&nbsp;6.5.4</a></td></tr><tr><td class="left">405</td><td class="left">Method Not Allowed</td><td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section&nbsp;6.5.5</a></td></tr><tr><td class="left">406</td><td class="left">Not Acceptable</td><td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section&nbsp;6.5.6</a></td></tr><tr><td class="left">407</td><td class="left">Proxy Authentication Required</td><td id="status.407" class="left"><a href="rfc7235.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></td></tr><tr><td class="left">408</td><td class="left">Request Timeout</td><td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section&nbsp;6.5.7</a></td></tr><tr><td class="left">409</td><td class="left">Conflict</td><td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section&nbsp;6.5.8</a></td></tr><tr><td class="left">410</td><td class="left">Gone</td><td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section&nbsp;6.5.9</a></td></tr><tr><td class="left">411</td><td class="left">Length Required</td><td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section&nbsp;6.5.10</a></td></tr><tr><td class="left">412</td><td class="left">Precondition Failed</td><td id="status.412" class="left"><a href="rfc7232.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></td></tr><tr><td class="left">413</td><td class="left">Payload Too Large</td><td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Payload Too Large">Section&nbsp;6.5.11</a></td></tr><tr><td class="left">414</td><td class="left">URI Too Long</td><td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section&nbsp;6.5.12</a></td></tr><tr><td class="left">415</td><td class="left">Unsupported Media Type</td><td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section&nbsp;6.5.13</a></td></tr><tr><td class="left">416</td><td class="left">Range Not Satisfiable</td><td id="status.416" class="left"><a href="rfc7233.html#status.416" title="416 Range Not Satisfiable">Section 4.4</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">417</td><td class="left">Expectation Failed</td><td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section&nbsp;6.5.14</a></td></tr><tr><td class="left">426</td><td class="left">Upgrade Required</td><td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section&nbsp;6.5.15</a></td></tr><tr><td class="left">500</td><td class="left">Internal Server Error</td><td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section&nbsp;6.6.1</a></td></tr><tr><td class="left">501</td><td class="left">Not Implemented</td><td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section&nbsp;6.6.2</a></td></tr><tr><td class="left">502</td><td class="left">Bad Gateway</td><td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section&nbsp;6.6.3</a></td></tr><tr><td class="left">503</td><td class="left">Service Unavailable</td><td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section&nbsp;6.6.4</a></td></tr><tr><td class="left">504</td><td class="left">Gateway Timeout</td><td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section&nbsp;6.6.5</a></td></tr><tr><td class="left">505</td><td class="left">HTTP Version Not Supported</td><td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section&nbsp;6.6.6</a></td></tr></tbody></table></div><p id="rfc.section.6.1.p.3">Note that this list is not exhaustive &#8212; it does not include extension status codes defined in other specifications. The complete list of status codes is maintained by IANA. See <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;8.2</a> for details.</p></div><div id="status.1xx"><h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#status.1xx">Informational 1xx</a></h2><div id="rfc.iref.65"></div><div id="rfc.iref.s.3"></div><p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. 1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section). Since HTTP/1.0 did not define any 1xx status codes, a server <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client.</p><p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx responses.</p><p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).</p><div id="status.100"><div id="rfc.iref.66"></div><h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a href="#status.100">100 Continue</a></h3><p id="rfc.section.6.2.1.p.1">The <dfn>100 (Continue)</dfn> status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.</p><p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#header.expect" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.1</a>. The client ought to continue sending the request and discard the 100 response.</p><p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#header.expect" class="smpl">100-continue</a> expectation, the client can simply discard this interim response.</p></div><div id="status.101"><div id="rfc.iref.66"></div><h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a href="#status.101">101 Switching Protocols</a></h3><p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="rfc7230.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="rfc7230.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.</p><p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.</p></div></div><div id="status.2xx"><h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#status.2xx">Successful 2xx</a></h2><div id="rfc.iref.66"></div><div id="rfc.iref.s.4"></div><p id="rfc.section.6.3.p.1">The <dfn>2xx (Successful)</dfn> class of status code indicates that the client's request was successfully received, understood, and accepted.</p><div id="status.200"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a href="#status.200">200 OK</a></h3><p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as: </p><dl><dt>GET</dt><dd>a representation of the <a href="#resources" class="smpl">target resource</a>;</dd><dt>HEAD</dt><dd>the same representation as GET, but without the representation data;</dd><dt>POST</dt><dd>a representation of the status of, or results obtained from, the action;</dd><dt>PUT, DELETE</dt><dd>a representation of the status of the action;</dd><dt>OPTIONS</dt><dd>a representation of the communications options;</dd><dt>TRACE</dt><dd>a representation of the request message as received by the end server.</dd></dl><p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.</p><p id="rfc.section.6.3.1.p.3">A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.201"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#status.201">201 Created</a></h3><p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a <a href="#header.location" class="smpl">Location</a> header field in the response or, if no <a href="#header.location" class="smpl">Location</a> field is received, by the effective request URI.</p><p id="rfc.section.6.3.2.p.2">The 201 response payload typically describes and links to the resource(s) created. See <a href="#response.validator" title="Validator Header Fields">Section&nbsp;7.2</a> for a discussion of the meaning and purpose of validator header fields, such as <a href="rfc7232.html#header.etag" class="smpl">ETag</a> and <a href="rfc7232.html#header.last-modified" class="smpl">Last-Modified</a>, in a 201 response.</p></div><div id="status.202"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a href="#status.202">202 Accepted</a></h3><p id="rfc.section.6.3.3.p.1">The <dfn>202 (Accepted)</dfn> status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.</p><p id="rfc.section.6.3.3.p.2">The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.</p></div><div id="status.203"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></h3><p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="rfc7230.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).</p><p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="rfc7234.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>), which has the advantage of being applicable to responses with any status code.</p><p id="rfc.section.6.3.4.p.3">A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.204"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a href="#status.204">204 No Content</a></h3><p id="rfc.section.6.3.5.p.1">The <dfn>204 (No Content)</dfn> status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the <a href="#resources" class="smpl">target resource</a> and its <a href="#representations" class="smpl">selected representation</a> after the requested action was applied.</p><p id="rfc.section.6.3.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an <a href="rfc7232.html#header.etag" class="smpl">ETag</a> header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.</p><p id="rfc.section.6.3.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.</p><p id="rfc.section.6.3.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.</p><p id="rfc.section.6.3.5.p.5">A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.</p><p id="rfc.section.6.3.5.p.6">A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.205"><div id="rfc.iref.67"></div><h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;<a href="#status.205">205 Reset Content</a></h3><p id="rfc.section.6.3.6.p.1">The <dfn>205 (Reset Content)</dfn> status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.</p><p id="rfc.section.6.3.6.p.2">This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.</p><p id="rfc.section.6.3.6.p.3">Since the 205 status code implies that no additional content will be provided, a server <em class="bcp14">MUST NOT</em> generate a payload in a 205 response. In other words, a server <em class="bcp14">MUST</em> do one of the following for a 205 response: a) indicate a zero-length body for the response by including a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header field with a value of 0; b) indicate a zero-length payload for the response by including a <a href="rfc7230.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.</p></div></div><div id="status.3xx"><h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a href="#status.3xx">Redirection 3xx</a></h2><div id="rfc.iref.67"></div><div id="rfc.iref.s.5"></div><p id="rfc.section.6.4.p.1">The <dfn>3xx (Redirection)</dfn> class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If a <a href="#header.location" class="smpl">Location</a> header field (<a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.2</a>) is provided, the user agent <em class="bcp14">MAY</em> automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to done with care for methods not known to be <a href="#safe.methods" class="smpl">safe</a>, as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, since the user might not wish to redirect an unsafe request.</p><p id="rfc.section.6.4.p.2">There are several types of redirects: </p><ol><li><p>Redirects that indicate the resource might be available at a different URI, as provided by the <a href="#header.location" class="smpl">Location</a> field, as in the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>.</p></li><li><p>Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> status code.</p></li><li><p>Redirection to a different resource, identified by the <a href="#header.location" class="smpl">Location</a> field, that can represent an indirect response to the request, as in the <a href="#status.303" class="smpl">303 (See Other)</a> status code.</p></li><li><p>Redirection to a previously cached result, as in the <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> status code.</p></li></ol><div class="note" id="rfc.section.6.4.p.3"><p><b>Note:</b> In HTTP/1.0, the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="https://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). Early user agents split on whether the method applied to the redirect target would be the same as the original request or would be rewritten as GET. Although HTTP originally defined the former semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> (to match its original implementation at CERN), and defined <a href="#status.303" class="smpl">303 (See Other)</a> to match the latter semantics, prevailing practice gradually converged on the latter semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> as well. The first revision of HTTP/1.1 added <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still do method rewriting for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>; therefore, this specification makes that behavior conformant when the original request is POST.</p> </div><p id="rfc.section.6.4.p.4">A client <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).</p><div class="note" id="rfc.section.6.4.p.5"><p><b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.</p> </div><div id="status.300"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a href="#status.300">300 Multiple Choices</a></h3><p id="rfc.section.6.4.1.p.1">The <dfn>300 (Multiple Choices)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><p id="rfc.section.6.4.1.p.2">If the server has a preferred choice, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field containing a preferred choice's URI reference. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection.</p><p id="rfc.section.6.4.1.p.3">For request methods other than HEAD, the server <em class="bcp14">SHOULD</em> generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent <em class="bcp14">MAY</em> make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.</p><p id="rfc.section.6.4.1.p.4">A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p><div class="note" id="rfc.section.6.4.1.p.5"><p><b>Note:</b> The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields <a href="#RFC5988" id="rfc.xref.RFC5988.1"><cite title="Web Linking">[RFC5988]</cite></a>, each with a relationship of "alternate", though deployment is a chicken-and-egg problem.</p> </div></div><div id="status.301"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a href="#status.301">301 Moved Permanently</a></h3><p id="rfc.section.6.4.2.p.1">The <dfn>301 (Moved Permanently)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.</p><p id="rfc.section.6.4.2.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a preferred URI reference for the new permanent URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).</p><div class="note" id="rfc.section.6.4.2.p.3"><p><b>Note:</b> For historical reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.</p> </div><p id="rfc.section.6.4.2.p.4">A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.302"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a href="#status.302">302 Found</a></h3><p id="rfc.section.6.4.3.p.1">The <dfn>302 (Found)</dfn> status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.</p><p id="rfc.section.6.4.3.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a URI reference for the different URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).</p><div class="note" id="rfc.section.6.4.3.p.3"><p><b>Note:</b> For historical reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.</p> </div></div><div id="status.303"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a href="#status.303">303 See Other</a></h3><p id="rfc.section.6.4.4.p.1">The <dfn>303 (See Other)</dfn> status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the <a href="#header.location" class="smpl">Location</a> header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.</p><p id="rfc.section.6.4.4.p.2">This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.</p><p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the origin server does not have a representation of the <a href="#resources" class="smpl">target resource</a> that can be transferred by the server over HTTP. However, the <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.</p><p id="rfc.section.6.4.4.p.4">Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the <a href="#header.location" class="smpl">Location</a> header field.</p></div><div id="status.305"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.5"><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;<a href="#status.305">305 Use Proxy</a></h3><p id="rfc.section.6.4.5.p.1">The <dfn>305 (Use Proxy)</dfn> status code was defined in a previous version of this specification and is now deprecated (<a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;B</a>).</p></div><div id="status.306"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.6"><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;<a href="#status.306">306 (Unused)</a></h3><p id="rfc.section.6.4.6.p.1">The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.</p></div><div id="status.307"><div id="rfc.iref.68"></div><h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;<a href="#status.307">307 Temporary Redirect</a></h3><p id="rfc.section.6.4.7.p.1">The <dfn>307 (Temporary Redirect)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> resides temporarily under a different URI and the user agent <em class="bcp14">MUST NOT</em> change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.</p><p id="rfc.section.6.4.7.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a URI reference for the different URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).</p><div class="note" id="rfc.section.6.4.7.p.3"><p><b>Note:</b> This status code is similar to <a href="#status.302" class="smpl">302 (Found)</a>, except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for <a href="#status.301" class="smpl">301 (Moved
    582     Permanently)</a> (<a href="#RFC7238" id="rfc.xref.RFC7238.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[RFC7238]</cite></a>, however, defines the status code 308 (Permanent Redirect) for this purpose).</p> </div></div></div><div id="status.4xx"><h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a href="#status.4xx">Client Error 4xx</a></h2><div id="rfc.iref.68"></div><div id="rfc.iref.s.6"></div><p id="rfc.section.6.5.p.1">The <dfn>4xx (Client Error)</dfn> class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.</p><div id="status.400"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a href="#status.400">400 Bad Request</a></h3><p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).</p></div><div id="status.402"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;<a href="#status.402">402 Payment Required</a></h3><p id="rfc.section.6.5.2.p.1">The <dfn>402 (Payment Required)</dfn> status code is reserved for future use.</p></div><div id="status.403"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;<a href="#status.403">403 Forbidden</a></h3><p id="rfc.section.6.5.3.p.1">The <dfn>403 (Forbidden)</dfn> status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).</p><p id="rfc.section.6.5.3.p.2">If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client <em class="bcp14">SHOULD NOT</em> automatically repeat the request with the same credentials. The client <em class="bcp14">MAY</em> repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.</p><p id="rfc.section.6.5.3.p.3">An origin server that wishes to "hide" the current existence of a forbidden <a href="#resources" class="smpl">target resource</a> <em class="bcp14">MAY</em> instead respond with a status code of <a href="#status.404" class="smpl">404 (Not Found)</a>.</p></div><div id="status.404"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a href="#status.404">404 Not Found</a></h3><p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.</p><p id="rfc.section.6.5.4.p.2">A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.405"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a href="#status.405">405 Method Not Allowed</a></h3><p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method received in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.</p><p id="rfc.section.6.5.5.p.2">A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.406"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a href="#status.406">406 Not Acceptable</a></h3><p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation that would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.</p><p id="rfc.section.6.5.6.p.2">The server <em class="bcp14">SHOULD</em> generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent <em class="bcp14">MAY</em> automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section&nbsp;6.4.1</a>.</p></div><div id="status.408"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a href="#status.408">408 Request Timeout</a></h3><p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server <em class="bcp14">SHOULD</em> send the "<a href="rfc7230.html#header.connection" class="smpl">close</a>" connection option (<a href="rfc7230.html#header.connection" title="Connection">Section 6.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection.</p></div><div id="status.409"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a href="#status.409">409 Conflict</a></h3><p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server <em class="bcp14">SHOULD</em> generate a payload that includes enough information for a user to recognize the source of the conflict.</p><p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.</p></div><div id="status.410"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;<a href="#status.410">410 Gone</a></h3><p id="rfc.section.6.5.9.p.1">The <dfn>410 (Gone)</dfn> status code indicates that access to the <a href="#resources" class="smpl">target resource</a> is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a> ought to be used instead.</p><p id="rfc.section.6.5.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time &#8212; that is left to the discretion of the server owner.</p><p id="rfc.section.6.5.9.p.3">A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.411"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a href="#status.411">411 Length Required</a></h3><p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> (<a href="rfc7230.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.</p></div><div id="status.413"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a href="#status.413">413 Payload Too Large</a></h3><p id="rfc.section.6.5.11.p.1">The <dfn>413 (Payload Too Large)</dfn> status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.</p><p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.</p></div><div id="status.414"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a href="#status.414">414 URI Too Long</a></h3><p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client attempting to exploit potential security holes.</p><p id="rfc.section.6.5.12.p.2">A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.415"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a href="#status.415">415 Unsupported Media Type</a></h3><p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the <a href="#resources" class="smpl">target resource</a>. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.</p></div><div id="status.417"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;<a href="#status.417">417 Expectation Failed</a></h3><p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;5.1.1</a>) could not be met by at least one of the inbound servers.</p></div><div id="status.426"><div id="rfc.iref.69"></div><h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<a href="#status.426">426 Upgrade Required</a></h3><p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="rfc7230.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="rfc7230.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><div id="rfc.figure.u.42"></div><p>Example:</p><pre class="text">HTTP/1.1 426 Upgrade Required
     581</pre><p id="rfc.section.5.5.3.p.8">A user agent <em class="bcp14">SHOULD NOT</em> generate a User-Agent field containing needlessly fine-grained detail and <em class="bcp14">SHOULD</em> limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting").</p><p id="rfc.section.5.5.3.p.9">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.</p></div></div></div><div id="status.codes"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#status.codes">Response Status Codes</a></h1><p id="rfc.section.6.p.1">The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.</p><p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient <em class="bcp14">MUST NOT</em> cache a response with an unrecognized status code.</p><p id="rfc.section.6.p.3">For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a <a href="#status.400" class="smpl">400 (Bad Request)</a> status code. The response message will usually contain a representation that explains the status.</p><p id="rfc.section.6.p.4">The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit: </p><ul><li><a href="#status.1xx" class="smpl">1xx (Informational)</a>: The request was received, continuing process</li><li><a href="#status.2xx" class="smpl">2xx (Successful)</a>: The request was successfully received, understood, and accepted</li><li><a href="#status.3xx" class="smpl">3xx (Redirection)</a>: Further action needs to be taken in order to complete the request</li><li><a href="#status.4xx" class="smpl">4xx (Client Error)</a>: The request contains bad syntax or cannot be fulfilled</li><li><a href="#status.5xx" class="smpl">5xx (Server Error)</a>: The server failed to fulfill an apparently valid request</li></ul><div id="overview.of.status.codes"><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#overview.of.status.codes">Overview of Status Codes</a></h2><p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="rfc7232.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>, <a href="rfc7233.html#range.response" title="Responses to a Range Request">Section 4</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>, and <a href="rfc7235.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>. The reason phrases listed here are only recommendations &#8212; they can be replaced by local equivalents without affecting the protocol.</p><p id="rfc.section.6.1.p.2">Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls <a href="#RFC7234" id="rfc.xref.RFC7234.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>; all other status codes are not cacheable by default.</p><div id="rfc.table.u.9"><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Code</th><th>Reason-Phrase</th><th>Defined in...</th></tr></thead><tbody><tr><td class="left">100</td><td class="left">Continue</td><td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a></td></tr><tr><td class="left">101</td><td class="left">Switching Protocols</td><td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section&nbsp;6.2.2</a></td></tr><tr><td class="left">200</td><td class="left">OK</td><td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section&nbsp;6.3.1</a></td></tr><tr><td class="left">201</td><td class="left">Created</td><td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section&nbsp;6.3.2</a></td></tr><tr><td class="left">202</td><td class="left">Accepted</td><td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section&nbsp;6.3.3</a></td></tr><tr><td class="left">203</td><td class="left">Non-Authoritative Information</td><td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section&nbsp;6.3.4</a></td></tr><tr><td class="left">204</td><td class="left">No Content</td><td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section&nbsp;6.3.5</a></td></tr><tr><td class="left">205</td><td class="left">Reset Content</td><td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section&nbsp;6.3.6</a></td></tr><tr><td class="left">206</td><td class="left">Partial Content</td><td id="status.206" class="left"><a href="rfc7233.html#status.206" title="206 Partial Content">Section 4.1</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">300</td><td class="left">Multiple Choices</td><td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section&nbsp;6.4.1</a></td></tr><tr><td class="left">301</td><td class="left">Moved Permanently</td><td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section&nbsp;6.4.2</a></td></tr><tr><td class="left">302</td><td class="left">Found</td><td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section&nbsp;6.4.3</a></td></tr><tr><td class="left">303</td><td class="left">See Other</td><td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section&nbsp;6.4.4</a></td></tr><tr><td class="left">304</td><td class="left">Not Modified</td><td id="status.304" class="left"><a href="rfc7232.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></td></tr><tr><td class="left">305</td><td class="left">Use Proxy</td><td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section&nbsp;6.4.5</a></td></tr><tr><td class="left">307</td><td class="left">Temporary Redirect</td><td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section&nbsp;6.4.7</a></td></tr><tr><td class="left">400</td><td class="left">Bad Request</td><td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section&nbsp;6.5.1</a></td></tr><tr><td class="left">401</td><td class="left">Unauthorized</td><td id="status.401" class="left"><a href="rfc7235.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></td></tr><tr><td class="left">402</td><td class="left">Payment Required</td><td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section&nbsp;6.5.2</a></td></tr><tr><td class="left">403</td><td class="left">Forbidden</td><td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section&nbsp;6.5.3</a></td></tr><tr><td class="left">404</td><td class="left">Not Found</td><td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section&nbsp;6.5.4</a></td></tr><tr><td class="left">405</td><td class="left">Method Not Allowed</td><td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section&nbsp;6.5.5</a></td></tr><tr><td class="left">406</td><td class="left">Not Acceptable</td><td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section&nbsp;6.5.6</a></td></tr><tr><td class="left">407</td><td class="left">Proxy Authentication Required</td><td id="status.407" class="left"><a href="rfc7235.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a></td></tr><tr><td class="left">408</td><td class="left">Request Timeout</td><td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section&nbsp;6.5.7</a></td></tr><tr><td class="left">409</td><td class="left">Conflict</td><td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section&nbsp;6.5.8</a></td></tr><tr><td class="left">410</td><td class="left">Gone</td><td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section&nbsp;6.5.9</a></td></tr><tr><td class="left">411</td><td class="left">Length Required</td><td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section&nbsp;6.5.10</a></td></tr><tr><td class="left">412</td><td class="left">Precondition Failed</td><td id="status.412" class="left"><a href="rfc7232.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a></td></tr><tr><td class="left">413</td><td class="left">Payload Too Large</td><td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Payload Too Large">Section&nbsp;6.5.11</a></td></tr><tr><td class="left">414</td><td class="left">URI Too Long</td><td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section&nbsp;6.5.12</a></td></tr><tr><td class="left">415</td><td class="left">Unsupported Media Type</td><td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section&nbsp;6.5.13</a></td></tr><tr><td class="left">416</td><td class="left">Range Not Satisfiable</td><td id="status.416" class="left"><a href="rfc7233.html#status.416" title="416 Range Not Satisfiable">Section 4.4</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></td></tr><tr><td class="left">417</td><td class="left">Expectation Failed</td><td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section&nbsp;6.5.14</a></td></tr><tr><td class="left">426</td><td class="left">Upgrade Required</td><td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section&nbsp;6.5.15</a></td></tr><tr><td class="left">500</td><td class="left">Internal Server Error</td><td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section&nbsp;6.6.1</a></td></tr><tr><td class="left">501</td><td class="left">Not Implemented</td><td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section&nbsp;6.6.2</a></td></tr><tr><td class="left">502</td><td class="left">Bad Gateway</td><td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section&nbsp;6.6.3</a></td></tr><tr><td class="left">503</td><td class="left">Service Unavailable</td><td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section&nbsp;6.6.4</a></td></tr><tr><td class="left">504</td><td class="left">Gateway Timeout</td><td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section&nbsp;6.6.5</a></td></tr><tr><td class="left">505</td><td class="left">HTTP Version Not Supported</td><td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section&nbsp;6.6.6</a></td></tr></tbody></table></div><p id="rfc.section.6.1.p.3">Note that this list is not exhaustive &#8212; it does not include extension status codes defined in other specifications. The complete list of status codes is maintained by IANA. See <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;8.2</a> for details.</p></div><div id="status.1xx"><h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#status.1xx">Informational 1xx</a></h2><div id="rfc.iref.1.2"></div><div id="rfc.iref.s.3"></div><p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. 1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section). Since HTTP/1.0 did not define any 1xx status codes, a server <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client.</p><p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx responses.</p><p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).</p><div id="status.100"><div id="rfc.iref.1.3"></div><h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a href="#status.100">100 Continue</a></h3><p id="rfc.section.6.2.1.p.1">The <dfn>100 (Continue)</dfn> status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.</p><p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#header.expect" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.1</a>. The client ought to continue sending the request and discard the 100 response.</p><p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#header.expect" class="smpl">100-continue</a> expectation, the client can simply discard this interim response.</p></div><div id="status.101"><div id="rfc.iref.1.4"></div><h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a href="#status.101">101 Switching Protocols</a></h3><p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="rfc7230.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="rfc7230.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.</p><p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.</p></div></div><div id="status.2xx"><h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#status.2xx">Successful 2xx</a></h2><div id="rfc.iref.2.1"></div><div id="rfc.iref.s.4"></div><p id="rfc.section.6.3.p.1">The <dfn>2xx (Successful)</dfn> class of status code indicates that the client's request was successfully received, understood, and accepted.</p><div id="status.200"><div id="rfc.iref.2.2"></div><h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a href="#status.200">200 OK</a></h3><p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as: </p><dl><dt>GET</dt><dd>a representation of the <a href="#resources" class="smpl">target resource</a>;</dd><dt>HEAD</dt><dd>the same representation as GET, but without the representation data;</dd><dt>POST</dt><dd>a representation of the status of, or results obtained from, the action;</dd><dt>PUT, DELETE</dt><dd>a representation of the status of the action;</dd><dt>OPTIONS</dt><dd>a representation of the communications options;</dd><dt>TRACE</dt><dd>a representation of the request message as received by the end server.</dd></dl><p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.</p><p id="rfc.section.6.3.1.p.3">A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.201"><div id="rfc.iref.2.3"></div><h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#status.201">201 Created</a></h3><p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a <a href="#header.location" class="smpl">Location</a> header field in the response or, if no <a href="#header.location" class="smpl">Location</a> field is received, by the effective request URI.</p><p id="rfc.section.6.3.2.p.2">The 201 response payload typically describes and links to the resource(s) created. See <a href="#response.validator" title="Validator Header Fields">Section&nbsp;7.2</a> for a discussion of the meaning and purpose of validator header fields, such as <a href="rfc7232.html#header.etag" class="smpl">ETag</a> and <a href="rfc7232.html#header.last-modified" class="smpl">Last-Modified</a>, in a 201 response.</p></div><div id="status.202"><div id="rfc.iref.2.4"></div><h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a href="#status.202">202 Accepted</a></h3><p id="rfc.section.6.3.3.p.1">The <dfn>202 (Accepted)</dfn> status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.</p><p id="rfc.section.6.3.3.p.2">The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.</p></div><div id="status.203"><div id="rfc.iref.2.5"></div><h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a href="#status.203">203 Non-Authoritative Information</a></h3><p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="rfc7230.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).</p><p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="rfc7234.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>), which has the advantage of being applicable to responses with any status code.</p><p id="rfc.section.6.3.4.p.3">A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.204"><div id="rfc.iref.2.6"></div><h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a href="#status.204">204 No Content</a></h3><p id="rfc.section.6.3.5.p.1">The <dfn>204 (No Content)</dfn> status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the <a href="#resources" class="smpl">target resource</a> and its <a href="#representations" class="smpl">selected representation</a> after the requested action was applied.</p><p id="rfc.section.6.3.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an <a href="rfc7232.html#header.etag" class="smpl">ETag</a> header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.</p><p id="rfc.section.6.3.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.</p><p id="rfc.section.6.3.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.</p><p id="rfc.section.6.3.5.p.5">A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.</p><p id="rfc.section.6.3.5.p.6">A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.205"><div id="rfc.iref.2.7"></div><h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;<a href="#status.205">205 Reset Content</a></h3><p id="rfc.section.6.3.6.p.1">The <dfn>205 (Reset Content)</dfn> status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.</p><p id="rfc.section.6.3.6.p.2">This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.</p><p id="rfc.section.6.3.6.p.3">Since the 205 status code implies that no additional content will be provided, a server <em class="bcp14">MUST NOT</em> generate a payload in a 205 response. In other words, a server <em class="bcp14">MUST</em> do one of the following for a 205 response: a) indicate a zero-length body for the response by including a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header field with a value of 0; b) indicate a zero-length payload for the response by including a <a href="rfc7230.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.</p></div></div><div id="status.3xx"><h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a href="#status.3xx">Redirection 3xx</a></h2><div id="rfc.iref.3.1"></div><div id="rfc.iref.s.5"></div><p id="rfc.section.6.4.p.1">The <dfn>3xx (Redirection)</dfn> class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If a <a href="#header.location" class="smpl">Location</a> header field (<a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.2</a>) is provided, the user agent <em class="bcp14">MAY</em> automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to done with care for methods not known to be <a href="#safe.methods" class="smpl">safe</a>, as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, since the user might not wish to redirect an unsafe request.</p><p id="rfc.section.6.4.p.2">There are several types of redirects: </p><ol><li><p>Redirects that indicate the resource might be available at a different URI, as provided by the <a href="#header.location" class="smpl">Location</a> field, as in the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a>, <a href="#status.302" class="smpl">302 (Found)</a>, and <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>.</p></li><li><p>Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> status code.</p></li><li><p>Redirection to a different resource, identified by the <a href="#header.location" class="smpl">Location</a> field, that can represent an indirect response to the request, as in the <a href="#status.303" class="smpl">303 (See Other)</a> status code.</p></li><li><p>Redirection to a previously cached result, as in the <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> status code.</p></li></ol><div class="note" id="rfc.section.6.4.p.3"><p><b>Note:</b> In HTTP/1.0, the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="https://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). Early user agents split on whether the method applied to the redirect target would be the same as the original request or would be rewritten as GET. Although HTTP originally defined the former semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> (to match its original implementation at CERN), and defined <a href="#status.303" class="smpl">303 (See Other)</a> to match the latter semantics, prevailing practice gradually converged on the latter semantics for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> as well. The first revision of HTTP/1.1 added <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still do method rewriting for <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>; therefore, this specification makes that behavior conformant when the original request is POST.</p> </div><p id="rfc.section.6.4.p.4">A client <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).</p><div class="note" id="rfc.section.6.4.p.5"><p><b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="https://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.</p> </div><div id="status.300"><div id="rfc.iref.3.2"></div><h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a href="#status.300">300 Multiple Choices</a></h3><p id="rfc.section.6.4.1.p.1">The <dfn>300 (Multiple Choices)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.4</a>).</p><p id="rfc.section.6.4.1.p.2">If the server has a preferred choice, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field containing a preferred choice's URI reference. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection.</p><p id="rfc.section.6.4.1.p.3">For request methods other than HEAD, the server <em class="bcp14">SHOULD</em> generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent <em class="bcp14">MAY</em> make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.</p><p id="rfc.section.6.4.1.p.4">A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p><div class="note" id="rfc.section.6.4.1.p.5"><p><b>Note:</b> The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields <a href="#RFC5988" id="rfc.xref.RFC5988.1"><cite title="Web Linking">[RFC5988]</cite></a>, each with a relationship of "alternate", though deployment is a chicken-and-egg problem.</p> </div></div><div id="status.301"><div id="rfc.iref.3.3"></div><h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a href="#status.301">301 Moved Permanently</a></h3><p id="rfc.section.6.4.2.p.1">The <dfn>301 (Moved Permanently)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.</p><p id="rfc.section.6.4.2.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a preferred URI reference for the new permanent URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).</p><div class="note" id="rfc.section.6.4.2.p.3"><p><b>Note:</b> For historical reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.</p> </div><p id="rfc.section.6.4.2.p.4">A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.302"><div id="rfc.iref.3.4"></div><h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a href="#status.302">302 Found</a></h3><p id="rfc.section.6.4.3.p.1">The <dfn>302 (Found)</dfn> status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.</p><p id="rfc.section.6.4.3.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a URI reference for the different URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).</p><div class="note" id="rfc.section.6.4.3.p.3"><p><b>Note:</b> For historical reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.</p> </div></div><div id="status.303"><div id="rfc.iref.3.5"></div><h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a href="#status.303">303 See Other</a></h3><p id="rfc.section.6.4.4.p.1">The <dfn>303 (See Other)</dfn> status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the <a href="#header.location" class="smpl">Location</a> header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.</p><p id="rfc.section.6.4.4.p.2">This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.</p><p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the origin server does not have a representation of the <a href="#resources" class="smpl">target resource</a> that can be transferred by the server over HTTP. However, the <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.</p><p id="rfc.section.6.4.4.p.4">Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the <a href="#header.location" class="smpl">Location</a> header field.</p></div><div id="status.305"><div id="rfc.iref.3.6"></div><h3 id="rfc.section.6.4.5"><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;<a href="#status.305">305 Use Proxy</a></h3><p id="rfc.section.6.4.5.p.1">The <dfn>305 (Use Proxy)</dfn> status code was defined in a previous version of this specification and is now deprecated (<a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;B</a>).</p></div><div id="status.306"><div id="rfc.iref.3.7"></div><h3 id="rfc.section.6.4.6"><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;<a href="#status.306">306 (Unused)</a></h3><p id="rfc.section.6.4.6.p.1">The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.</p></div><div id="status.307"><div id="rfc.iref.3.8"></div><h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;<a href="#status.307">307 Temporary Redirect</a></h3><p id="rfc.section.6.4.7.p.1">The <dfn>307 (Temporary Redirect)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> resides temporarily under a different URI and the user agent <em class="bcp14">MUST NOT</em> change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.</p><p id="rfc.section.6.4.7.p.2">The server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field in the response containing a URI reference for the different URI. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).</p><div class="note" id="rfc.section.6.4.7.p.3"><p><b>Note:</b> This status code is similar to <a href="#status.302" class="smpl">302 (Found)</a>, except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for <a href="#status.301" class="smpl">301 (Moved
     582    Permanently)</a> (<a href="#RFC7238" id="rfc.xref.RFC7238.1"><cite title="The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)">[RFC7238]</cite></a>, however, defines the status code 308 (Permanent Redirect) for this purpose).</p> </div></div></div><div id="status.4xx"><h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a href="#status.4xx">Client Error 4xx</a></h2><div id="rfc.iref.4.1"></div><div id="rfc.iref.s.6"></div><p id="rfc.section.6.5.p.1">The <dfn>4xx (Client Error)</dfn> class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.</p><div id="status.400"><div id="rfc.iref.4.2"></div><h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a href="#status.400">400 Bad Request</a></h3><p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).</p></div><div id="status.402"><div id="rfc.iref.4.3"></div><h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;<a href="#status.402">402 Payment Required</a></h3><p id="rfc.section.6.5.2.p.1">The <dfn>402 (Payment Required)</dfn> status code is reserved for future use.</p></div><div id="status.403"><div id="rfc.iref.4.4"></div><h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;<a href="#status.403">403 Forbidden</a></h3><p id="rfc.section.6.5.3.p.1">The <dfn>403 (Forbidden)</dfn> status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).</p><p id="rfc.section.6.5.3.p.2">If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client <em class="bcp14">SHOULD NOT</em> automatically repeat the request with the same credentials. The client <em class="bcp14">MAY</em> repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.</p><p id="rfc.section.6.5.3.p.3">An origin server that wishes to "hide" the current existence of a forbidden <a href="#resources" class="smpl">target resource</a> <em class="bcp14">MAY</em> instead respond with a status code of <a href="#status.404" class="smpl">404 (Not Found)</a>.</p></div><div id="status.404"><div id="rfc.iref.4.5"></div><h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a href="#status.404">404 Not Found</a></h3><p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.</p><p id="rfc.section.6.5.4.p.2">A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.405"><div id="rfc.iref.4.6"></div><h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a href="#status.405">405 Method Not Allowed</a></h3><p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method received in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.</p><p id="rfc.section.6.5.5.p.2">A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.406"><div id="rfc.iref.4.7"></div><h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a href="#status.406">406 Not Acceptable</a></h3><p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation that would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.</p><p id="rfc.section.6.5.6.p.2">The server <em class="bcp14">SHOULD</em> generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent <em class="bcp14">MAY</em> automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section&nbsp;6.4.1</a>.</p></div><div id="status.408"><div id="rfc.iref.4.8"></div><h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a href="#status.408">408 Request Timeout</a></h3><p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server <em class="bcp14">SHOULD</em> send the "<a href="rfc7230.html#header.connection" class="smpl">close</a>" connection option (<a href="rfc7230.html#header.connection" title="Connection">Section 6.1</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection.</p></div><div id="status.409"><div id="rfc.iref.4.9"></div><h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a href="#status.409">409 Conflict</a></h3><p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server <em class="bcp14">SHOULD</em> generate a payload that includes enough information for a user to recognize the source of the conflict.</p><p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.</p></div><div id="status.410"><div id="rfc.iref.4.10"></div><h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;<a href="#status.410">410 Gone</a></h3><p id="rfc.section.6.5.9.p.1">The <dfn>410 (Gone)</dfn> status code indicates that access to the <a href="#resources" class="smpl">target resource</a> is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a> ought to be used instead.</p><p id="rfc.section.6.5.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time &#8212; that is left to the discretion of the server owner.</p><p id="rfc.section.6.5.9.p.3">A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.411"><div id="rfc.iref.4.11"></div><h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a href="#status.411">411 Length Required</a></h3><p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> (<a href="rfc7230.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.</p></div><div id="status.413"><div id="rfc.iref.4.12"></div><h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a href="#status.413">413 Payload Too Large</a></h3><p id="rfc.section.6.5.11.p.1">The <dfn>413 (Payload Too Large)</dfn> status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.</p><p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.</p></div><div id="status.414"><div id="rfc.iref.4.13"></div><h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a href="#status.414">414 URI Too Long</a></h3><p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="rfc7230.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client attempting to exploit potential security holes.</p><p id="rfc.section.6.5.12.p.2">A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.415"><div id="rfc.iref.4.14"></div><h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a href="#status.415">415 Unsupported Media Type</a></h3><p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the <a href="#resources" class="smpl">target resource</a>. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.</p></div><div id="status.417"><div id="rfc.iref.4.15"></div><h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;<a href="#status.417">417 Expectation Failed</a></h3><p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section&nbsp;5.1.1</a>) could not be met by at least one of the inbound servers.</p></div><div id="status.426"><div id="rfc.iref.4.16"></div><h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<a href="#status.426">426 Upgrade Required</a></h3><p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="rfc7230.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="rfc7230.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).</p><div id="rfc.figure.u.42"></div><p>Example:</p><pre class="text">HTTP/1.1 426 Upgrade Required
    583583Upgrade: HTTP/3.0
    584584Connection: Upgrade
     
    587587
    588588<span id="s426body">This service requires use of the HTTP/3.0 protocol.
    589 </span></pre></div></div><div id="status.5xx"><h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a href="#status.5xx">Server Error 5xx</a></h2><div id="rfc.iref.69"></div><div id="rfc.iref.s.7"></div><p id="rfc.section.6.6.p.1">The <dfn>5xx (Server Error)</dfn> class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.</p><div id="status.500"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<a href="#status.500">500 Internal Server Error</a></h3><p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.</p></div><div id="status.501"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.2"><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;<a href="#status.501">501 Not Implemented</a></h3><p id="rfc.section.6.6.2.p.1">The <dfn>501 (Not Implemented)</dfn> status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.</p><p id="rfc.section.6.6.2.p.2">A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.502"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.3"><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;<a href="#status.502">502 Bad Gateway</a></h3><p id="rfc.section.6.6.3.p.1">The <dfn>502 (Bad Gateway)</dfn> status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.</p></div><div id="status.503"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.4"><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;<a href="#status.503">503 Service Unavailable</a></h3><p id="rfc.section.6.6.4.p.1">The <dfn>503 (Service Unavailable)</dfn> status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server <em class="bcp14">MAY</em> send a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;7.1.3</a>) to suggest an appropriate amount of time for the client to wait before retrying the request.</p><div class="note" id="rfc.section.6.6.4.p.2"><p><b>Note:</b> The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.</p> </div></div><div id="status.504"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.5"><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;<a href="#status.504">504 Gateway Timeout</a></h3><p id="rfc.section.6.6.5.p.1">The <dfn>504 (Gateway Timeout)</dfn> status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.</p></div><div id="status.505"><div id="rfc.iref.70"></div><h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></h3><p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in <a href="rfc7230.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.</p></div></div></div><div id="response.header.fields"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#response.header.fields">Response Header Fields</a></h1><p id="rfc.section.7.p.1">The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the <a href="#resources" class="smpl">target resource</a>, or about related resources.</p><p id="rfc.section.7.p.2">Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the semantics of the request method and/or response status code.</p><div id="response.control.data"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#response.control.data">Control Data</a></h2><p id="rfc.section.7.1.p.1">Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.</p><div id="rfc.table.u.10"><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">Age</td><td class="left"><a href="rfc7234.html#header.age" title="Age">Section 5.1</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Cache-Control</td><td class="left"><a href="rfc7234.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Expires</td><td class="left"><a href="rfc7234.html#header.expires" title="Expires">Section 5.3</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Date</td><td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;7.1.1.2</a></td></tr><tr><td class="left">Location</td><td class="left"><a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;7.1.2</a></td></tr><tr><td class="left">Retry-After</td><td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;7.1.3</a></td></tr><tr><td class="left">Vary</td><td class="left"><a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;7.1.4</a></td></tr><tr><td class="left">Warning</td><td class="left"><a href="rfc7234.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr></tbody></table></div><div id="origination.date"><h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a href="#origination.date">Origination Date</a></h3><div id="http.date"><h4 id="rfc.section.7.1.1.1"><a href="#rfc.section.7.1.1.1">7.1.1.1</a>&nbsp;<a href="#http.date">Date/Time Formats</a></h4><p id="rfc.section.7.1.1.1.p.1">Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>.</p><div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
     589</span></pre></div></div><div id="status.5xx"><h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a href="#status.5xx">Server Error 5xx</a></h2><div id="rfc.iref.5.1"></div><div id="rfc.iref.s.7"></div><p id="rfc.section.6.6.p.1">The <dfn>5xx (Server Error)</dfn> class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.</p><div id="status.500"><div id="rfc.iref.5.2"></div><h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<a href="#status.500">500 Internal Server Error</a></h3><p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.</p></div><div id="status.501"><div id="rfc.iref.5.3"></div><h3 id="rfc.section.6.6.2"><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;<a href="#status.501">501 Not Implemented</a></h3><p id="rfc.section.6.6.2.p.1">The <dfn>501 (Not Implemented)</dfn> status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.</p><p id="rfc.section.6.6.2.p.2">A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see <a href="rfc7234.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>).</p></div><div id="status.502"><div id="rfc.iref.5.4"></div><h3 id="rfc.section.6.6.3"><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;<a href="#status.502">502 Bad Gateway</a></h3><p id="rfc.section.6.6.3.p.1">The <dfn>502 (Bad Gateway)</dfn> status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.</p></div><div id="status.503"><div id="rfc.iref.5.5"></div><h3 id="rfc.section.6.6.4"><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;<a href="#status.503">503 Service Unavailable</a></h3><p id="rfc.section.6.6.4.p.1">The <dfn>503 (Service Unavailable)</dfn> status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server <em class="bcp14">MAY</em> send a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;7.1.3</a>) to suggest an appropriate amount of time for the client to wait before retrying the request.</p><div class="note" id="rfc.section.6.6.4.p.2"><p><b>Note:</b> The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.</p> </div></div><div id="status.504"><div id="rfc.iref.5.6"></div><h3 id="rfc.section.6.6.5"><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;<a href="#status.504">504 Gateway Timeout</a></h3><p id="rfc.section.6.6.5.p.1">The <dfn>504 (Gateway Timeout)</dfn> status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.</p></div><div id="status.505"><div id="rfc.iref.5.7"></div><h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;<a href="#status.505">505 HTTP Version Not Supported</a></h3><p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in <a href="rfc7230.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.</p></div></div></div><div id="response.header.fields"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#response.header.fields">Response Header Fields</a></h1><p id="rfc.section.7.p.1">The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the <a href="#resources" class="smpl">target resource</a>, or about related resources.</p><p id="rfc.section.7.p.2">Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the semantics of the request method and/or response status code.</p><div id="response.control.data"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#response.control.data">Control Data</a></h2><p id="rfc.section.7.1.p.1">Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.</p><div id="rfc.table.u.10"><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">Age</td><td class="left"><a href="rfc7234.html#header.age" title="Age">Section 5.1</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Cache-Control</td><td class="left"><a href="rfc7234.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Expires</td><td class="left"><a href="rfc7234.html#header.expires" title="Expires">Section 5.3</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr><tr><td class="left">Date</td><td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;7.1.1.2</a></td></tr><tr><td class="left">Location</td><td class="left"><a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;7.1.2</a></td></tr><tr><td class="left">Retry-After</td><td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;7.1.3</a></td></tr><tr><td class="left">Vary</td><td class="left"><a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;7.1.4</a></td></tr><tr><td class="left">Warning</td><td class="left"><a href="rfc7234.html#header.warning" title="Warning">Section 5.5</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a></td></tr></tbody></table></div><div id="origination.date"><h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a href="#origination.date">Origination Date</a></h3><div id="http.date"><h4 id="rfc.section.7.1.1.1"><a href="#rfc.section.7.1.1.1">7.1.1.1</a>&nbsp;<a href="#http.date">Date/Time Formats</a></h4><p id="rfc.section.7.1.1.1.p.1">Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>.</p><div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
    590590</pre><div id="rfc.figure.u.44"></div><p>An example of the preferred format is</p><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
    591591</pre><div id="rfc.figure.u.45"></div><p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
     
    799799
    800800<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    801 </pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.X">X</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1</a>, <a href="#rfc.iref.66"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.2">8.2.3</a></li><li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.38"><b>5.1.1</b></a></li><li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.66"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li><li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.65"><b>6.2</b></a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">8.2.3</a></li><li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a>, <a href="#rfc.xref.status.201.3">B</a></li><li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">8.2.3</a></li><li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">B</a></li><li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">8.2.3</a></li><li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.67"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">8.2.3</a></li><li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.66"><b>6.3</b></a></li></ul></li><li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul><li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">6.5.6</a>, <a href="#rfc.xref.status.300.3">8.2.3</a></li><li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">B</a></li><li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">B</a></li><li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">B</a></li><li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">B</a></li><li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.68"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li><li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.68"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li><li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.67"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">B</a></li><li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">8.2.3</a></li><li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a></li><li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">8.2.3</a></li><li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">8.2.3</a></li><li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">8.2.3</a></li><li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">8.2.3</a></li><li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">8.2.3</a></li><li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">8.2.3</a></li><li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">8.2.3</a></li><li>413 Payload Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li><li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">8.2.3</a></li><li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li><li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">8.2.3</a></li><li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.69"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">B</a></li><li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.68"><b>6.5</b></a></li></ul></li><li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul><li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">8.2.3</a></li><li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">8.2.3</a></li><li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">8.2.3</a></li><li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">8.2.3</a></li><li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">8.2.3</a></li><li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.70"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">8.2.3</a></li><li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.69"><b>6.6</b></a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.1.1.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.3.2</a></li><li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3.2</a>, <a href="#rfc.xref.header.accept-charset.3">B</a></li><li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.1.2.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.3.2</a>, <a href="#rfc.xref.header.accept-encoding.4">8.4.2</a></li><li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.1.3.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">8.3.2</a></li><li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3.2</a>, <a href="#rfc.xref.header.allow.4">B</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP13</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP13.1">3.1.1.1</a>, <a href="#BCP13"><b>11.2</b></a></li><li><em>BCP178</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP178.1">8.3.1</a>, <a href="#BCP178"><b>11.2</b></a></li><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">8.3</a>, <a href="#rfc.xref.BCP90.2">8.3.1</a>, <a href="#BCP90"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>4.2.3</b></a></li><li>compress (content coding)&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>3.1.2.1</b></a></li><li>conditional request&nbsp;&nbsp;<a href="#rfc.iref.c.10"><b>5.2</b></a></li><li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.9"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">8.1.3</a>, <a href="#rfc.xref.CONNECT.3">B</a></li><li>content coding&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>3.1.2.1</b></a></li><li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li><li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.1</a>, <a href="#rfc.xref.header.content-encoding.2">3.1.2.1</a>, <a href="#rfc.iref.c.5"><b>3.1.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.3">8.3.2</a></li><li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.1</a>, <a href="#rfc.iref.c.6"><b>3.1.3.2</b></a>, <a href="#rfc.xref.header.content-language.2">8.3.2</a></li><li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.7"><b>3.1.4.2</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.2</a>, <a href="#rfc.xref.header.content-location.4">8.3.2</a>, <a href="#rfc.xref.header.content-location.5">B</a></li><li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.11">A.5</a></li><li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">3.1.1.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1.5</b></a>, <a href="#rfc.xref.header.content-type.3">8.3.1</a>, <a href="#rfc.xref.header.content-type.4">8.3.2</a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">7.1</a>, <a href="#rfc.iref.d.3"><b>7.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">8.3.2</a></li><li>deflate (content coding)&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>3.1.2.1</b></a></li><li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.2"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">8.1.3</a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.expect.2">6.2.1</a>, <a href="#rfc.xref.header.expect.3">6.5.14</a>, <a href="#rfc.xref.header.expect.4">8.3.2</a>, <a href="#rfc.xref.header.expect.5">B</a></li></ul></li><li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul><li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">5.5</a>, <a href="#rfc.iref.f.1"><b>5.5.1</b></a>, <a href="#rfc.xref.header.from.2">8.3.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.1.4.2</a>, <a href="#rfc.xref.GET.3">3.3</a>, <a href="#rfc.xref.GET.4">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.5">8.1.3</a>, <a href="#rfc.xref.GET.6">B</a></li><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Accept</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>5.3.2</b></a></li><li><tt>Accept-Charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>5.3.3</b></a></li><li><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>5.3.4</b></a></li><li><tt>accept-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>5.3.2</b></a></li><li><tt>Accept-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>5.3.5</b></a></li><li><tt>accept-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.2</b></a></li><li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>7.4.1</b></a></li><li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>7.1.1.1</b></a></li><li><tt>charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>3.1.1.2</b></a></li><li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>5.3.4</b></a></li><li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>3.1.2.1</b></a></li><li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>3.1.2.2</b></a></li><li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>3.1.3.2</b></a></li><li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>3.1.4.2</b></a></li><li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>3.1.1.5</b></a></li><li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>7.1.1.2</b></a></li><li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>7.1.1.1</b></a></li><li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>7.1.1.1</b></a></li><li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li><li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>7.1.1.1</b></a></li><li><tt>delay-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>7.1.3</b></a></li><li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>5.1.1</b></a></li><li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>5.5.1</b></a></li><li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li><li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>7.1.1.1</b></a></li><li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>7.1.1.1</b></a></li><li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>7.1.1.1</b></a></li><li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>5.3.5</b></a></li><li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.1.3.1</b></a></li><li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>7.1.2</b></a></li><li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>5.1.2</b></a></li><li><tt>media-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>5.3.2</b></a></li><li><tt>media-type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.1.1</b></a></li><li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>4.1</b></a></li><li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>7.1.1.1</b></a></li><li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li><li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>7.1.1.1</b></a></li><li><tt>parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.1.1.1</b></a></li><li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>5.5.3</b></a></li><li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>5.5.3</b></a></li><li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>5.3.1</b></a></li><li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>5.5.2</b></a></li><li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>7.1.3</b></a></li><li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>7.1.1.1</b></a></li><li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li><li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>7.4.2</b></a></li><li><tt>subtype</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.1.1.1</b></a></li><li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>7.1.1.1</b></a></li><li><tt>type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1.1.1</b></a></li><li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>5.5.3</b></a></li><li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.4</b></a></li><li><tt>weight</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>5.3.1</b></a></li><li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>7.1.1.1</b></a></li></ul></li><li>gzip (content coding)&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.1.2.1</b></a></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3.1.4.2</a>, <a href="#rfc.xref.HEAD.2">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.3">8.1.3</a></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>idempotent&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>4.2.2</b></a></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">B</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1.2</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">B</a></li><li>MIME-Version header field&nbsp;&nbsp;<a href="#rfc.xref.mime-version.1">8.3.2</a>, <a href="#rfc.iref.m.2"><b>A.1</b></a></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.11">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.12">B</a></li><li><em>OWASP</em>&nbsp;&nbsp;<a href="#rfc.xref.OWASP.1">9</a>, <a href="#OWASP"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li><li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.1.4.2</a>, <a href="#rfc.xref.POST.2">3.3</a>, <a href="#rfc.xref.POST.3">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.4">8.1.3</a></li><li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1.4.2</a>, <a href="#rfc.xref.PUT.2">3.3</a>, <a href="#rfc.xref.PUT.3">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.4">8.1.3</a>, <a href="#rfc.xref.PUT.5">B</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.4</a>, <a href="#rfc.xref.header.referer.4">B</a></li><li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>3</b></a></li><li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li><li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3.2</a></li><li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a><ul><li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a></li></ul></li><li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">3.1.1.3</a>, <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.2">A</a>, <a href="#rfc.xref.RFC2045.3">A.1</a></li><li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.1.1.1</a>, <a href="#rfc.xref.RFC2046.2">3.1.1.4</a>, <a href="#rfc.xref.RFC2046.3">3.1.1.5</a>, <a href="#RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul><li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">3.1.1.5</a></li><li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.2">3.1.1.4</a></li></ul></li><li><em>RFC2049</em>&nbsp;&nbsp;<a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">A.2</a></li></ul></li><li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul><li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li></ul></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>11.1</b></a></li><li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.4</a>, <a href="#RFC2295"><b>11.2</b></a></li><li><em>RFC2388</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2388.1">3.1.1.4</a>, <a href="#RFC2388"><b>11.2</b></a></li><li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4.2</a>, <a href="#RFC2557"><b>11.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4.2</a></li></ul></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a>, <a href="#RFC2616"><b>11.2</b></a><ul><li><em>Section 14.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a></li></ul></li><li><em>RFC2774</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2774.1">8.1.2</a>, <a href="#RFC2774"><b>11.2</b></a></li><li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">B</a>, <a href="#rfc.xref.RFC2817.3">B</a>, <a href="#rfc.xref.RFC2817.4">B</a><ul><li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.4">B</a></li></ul></li><li><em>RFC2978</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2978.1">3.1.1.2</a>, <a href="#RFC2978"><b>11.2</b></a></li><li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">5.5.2</a>, <a href="#rfc.xref.RFC3986.2">7.1.2</a>, <a href="#rfc.xref.RFC3986.3">7.1.2</a>, <a href="#RFC3986"><b>11.1</b></a><ul><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.2</a></li><li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.3">7.1.2</a></li></ul></li><li><em>RFC4647</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.1">5.3.5</a>, <a href="#rfc.xref.RFC4647.2">5.3.5</a>, <a href="#rfc.xref.RFC4647.3">5.3.5</a>, <a href="#rfc.xref.RFC4647.4">5.3.5</a>, <a href="#RFC4647"><b>11.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.1">5.3.5</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.2">5.3.5</a></li><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.3">5.3.5</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.4">5.3.5</a></li></ul></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">8.1.1</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#rfc.xref.RFC5226.3">8.4.1</a>, <a href="#RFC5226"><b>11.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">8.1.1</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#rfc.xref.RFC5226.3">8.4.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">8.3.1</a>, <a href="#RFC5234"><b>11.1</b></a>, <a href="#rfc.xref.RFC5234.3">C</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.3">C</a></li></ul></li><li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">4.3.6</a>, <a href="#RFC5246"><b>11.2</b></a></li><li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.6">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.7">A</a><ul><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a></li><li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.6">7.1.1.2</a></li></ul></li><li><em>RFC5646</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5646.1">3.1.3.1</a>, <a href="#rfc.xref.RFC5646.2">3.1.3.1</a>, <a href="#rfc.xref.RFC5646.3">3.1.3.1</a>, <a href="#RFC5646"><b>11.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5646.2">3.1.3.1</a></li></ul></li><li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">4.3.4</a>, <a href="#RFC5789"><b>11.2</b></a></li><li><em>RFC5905</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5905.1">7.1.1.1</a>, <a href="#RFC5905"><b>11.2</b></a></li><li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">8.3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li><li><em>RFC5988</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5988.1">6.4.1</a>, <a href="#RFC5988"><b>11.2</b></a></li><li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">4.3.8</a>, <a href="#rfc.xref.RFC6265.2">5.4</a>, <a href="#RFC6265"><b>11.2</b></a></li><li><em>RFC6266</em>&nbsp;&nbsp;<a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">B</a></li><li><em>RFC6365</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6365.1">1.2</a>, <a href="#rfc.xref.RFC6365.2">3.1.1.2</a>, <a href="#RFC6365"><b>11.1</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2</a>, <a href="#rfc.xref.RFC7230.5">2</a>, <a href="#rfc.xref.RFC7230.6">2</a>, <a href="#rfc.xref.RFC7230.7">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.8">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.9">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.10">3.1.2.2</a>, <a href="#rfc.xref.RFC7230.11">3.1.4.1</a>, <a href="#rfc.xref.RFC7230.12">3.1.4.2</a>, <a href="#rfc.xref.RFC7230.13">3.3</a>, <a href="#rfc.xref.RFC7230.14">3.3</a>, <a href="#rfc.xref.RFC7230.15">3.3</a>, <a href="#rfc.xref.RFC7230.16">4.3.6</a>, <a href="#rfc.xref.RFC7230.17">4.3.7</a>, <a href="#rfc.xref.RFC7230.18">4.3.8</a>, <a href="#rfc.xref.RFC7230.19">4.3.8</a>, <a href="#rfc.xref.RFC7230.20">5.1</a>, <a href="#rfc.xref.RFC7230.21">5.1</a>, <a href="#rfc.xref.RFC7230.22">5.1.1</a>, <a href="#rfc.xref.RFC7230.23">5.5.3</a>, <a href="#rfc.xref.RFC7230.24">6.2.2</a>, <a href="#rfc.xref.RFC7230.25">6.3.4</a>, <a href="#rfc.xref.RFC7230.26">6.5.7</a>, <a href="#rfc.xref.RFC7230.27">6.5.10</a>, <a href="#rfc.xref.RFC7230.28">6.5.12</a>, <a href="#rfc.xref.RFC7230.29">6.5.15</a>, <a href="#rfc.xref.RFC7230.30">6.6.6</a>, <a href="#rfc.xref.RFC7230.31">7.4.2</a>, <a href="#rfc.xref.RFC7230.32">8.1.2</a>, <a href="#rfc.xref.RFC7230.33">8.3.1</a>, <a href="#rfc.xref.RFC7230.34">8.3.1</a>, <a href="#rfc.xref.RFC7230.35">8.3.1</a>, <a href="#rfc.xref.RFC7230.36">8.3.1</a>, <a href="#rfc.xref.RFC7230.37">8.3.1</a>, <a href="#rfc.xref.RFC7230.38">8.3.1</a>, <a href="#rfc.xref.RFC7230.39">8.3.1</a>, <a href="#rfc.xref.RFC7230.40">8.4</a>, <a href="#rfc.xref.RFC7230.41">8.4.1</a>, <a href="#rfc.xref.RFC7230.42">8.4.1</a>, <a href="#rfc.xref.RFC7230.43">9</a>, <a href="#rfc.xref.RFC7230.44">9.6</a>, <a href="#rfc.xref.RFC7230.45">10</a>, <a href="#RFC7230"><b>11.1</b></a>, <a href="#rfc.xref.RFC7230.46">B</a>, <a href="#rfc.xref.RFC7230.47">C</a>, <a href="#rfc.xref.RFC7230.48">C</a>, <a href="#rfc.xref.RFC7230.49">C</a>, <a href="#rfc.xref.RFC7230.50">C</a>, <a href="#rfc.xref.RFC7230.51">C</a>, <a href="#rfc.xref.RFC7230.52">C</a>, <a href="#rfc.xref.RFC7230.53">C</a>, <a href="#rfc.xref.RFC7230.54">C</a>, <a href="#rfc.xref.RFC7230.55">C</a>, <a href="#rfc.xref.RFC7230.56">C</a>, <a href="#rfc.xref.RFC7230.57">C</a>, <a href="#rfc.xref.RFC7230.58">D</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.58">D</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.30">6.6.6</a></li><li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2</a>, <a href="#rfc.xref.RFC7230.51">C</a>, <a href="#rfc.xref.RFC7230.52">C</a>, <a href="#rfc.xref.RFC7230.55">C</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.23">5.5.3</a>, <a href="#rfc.xref.RFC7230.31">7.4.2</a>, <a href="#rfc.xref.RFC7230.33">8.3.1</a>, <a href="#rfc.xref.RFC7230.37">8.3.1</a>, <a href="#rfc.xref.RFC7230.54">C</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.48">C</a>, <a href="#rfc.xref.RFC7230.49">C</a>, <a href="#rfc.xref.RFC7230.50">C</a></li><li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.35">8.3.1</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.36">8.3.1</a>, <a href="#rfc.xref.RFC7230.53">C</a>, <a href="#rfc.xref.RFC7230.56">C</a>, <a href="#rfc.xref.RFC7230.57">C</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">3.1.2.2</a>, <a href="#rfc.xref.RFC7230.15">3.3</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.32">8.1.2</a></li><li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.13">3.3</a>, <a href="#rfc.xref.RFC7230.27">6.5.10</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.41">8.4.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.39">8.3.1</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.7">3.1.2.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.40">8.4</a>, <a href="#rfc.xref.RFC7230.42">8.4.1</a></li><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">3.1.2.1</a></li><li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">3.1.2.1</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.21">5.1</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.14">3.3</a></li><li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.5">2</a>, <a href="#rfc.xref.RFC7230.16">4.3.6</a>, <a href="#rfc.xref.RFC7230.17">4.3.7</a>, <a href="#rfc.xref.RFC7230.28">6.5.12</a></li><li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.20">5.1</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">2</a>, <a href="#rfc.xref.RFC7230.11">3.1.4.1</a>, <a href="#rfc.xref.RFC7230.12">3.1.4.2</a></li><li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.19">4.3.8</a>, <a href="#rfc.xref.RFC7230.44">9.6</a></li><li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.25">6.3.4</a></li><li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.26">6.5.7</a>, <a href="#rfc.xref.RFC7230.38">8.3.1</a></li><li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.22">5.1.1</a></li><li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.24">6.2.2</a>, <a href="#rfc.xref.RFC7230.29">6.5.15</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.34">8.3.1</a></li><li><em>Section 8.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.18">4.3.8</a></li><li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.43">9</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.45">10</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">3</a>, <a href="#rfc.xref.RFC7232.2">4.1</a>, <a href="#rfc.xref.RFC7232.3">5.2</a>, <a href="#rfc.xref.RFC7232.4">5.2</a>, <a href="#rfc.xref.RFC7232.5">5.2</a>, <a href="#rfc.xref.RFC7232.6">5.2</a>, <a href="#rfc.xref.RFC7232.7">5.2</a>, <a href="#rfc.xref.RFC7232.8">5.2</a>, <a href="#rfc.xref.RFC7232.9">6.1</a>, <a href="#rfc.xref.RFC7232.10">6.1</a>, <a href="#rfc.xref.RFC7232.11">6.1</a>, <a href="#rfc.xref.RFC7232.12">7.2</a>, <a href="#rfc.xref.RFC7232.13">7.2</a>, <a href="#rfc.xref.RFC7232.14">7.2</a>, <a href="#RFC7232"><b>11.1</b></a><ul><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.14">7.2</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.13">7.2</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">5.2</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">5.2</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.7">5.2</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.8">5.2</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.9">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.10">6.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.11">6.1</a></li><li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.4">5.2</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.1.1.4</a>, <a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.3">4.3.1</a>, <a href="#rfc.xref.RFC7233.4">4.3.4</a>, <a href="#rfc.xref.RFC7233.5">5.1</a>, <a href="#rfc.xref.RFC7233.6">5.2</a>, <a href="#rfc.xref.RFC7233.7">6.1</a>, <a href="#rfc.xref.RFC7233.8">6.1</a>, <a href="#rfc.xref.RFC7233.9">6.1</a>, <a href="#rfc.xref.RFC7233.10">7.4</a>, <a href="#rfc.xref.RFC7233.11">8.1.2</a>, <a href="#RFC7233"><b>11.1</b></a>, <a href="#rfc.xref.RFC7233.12">A.6</a><ul><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.10">7.4</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.5">5.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.6">5.2</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.7">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.8">6.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.4">4.3.4</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.9">6.1</a></li><li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.12">A.6</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2.3</a>, <a href="#rfc.xref.RFC7234.2">4.3.1</a>, <a href="#rfc.xref.RFC7234.3">4.3.2</a>, <a href="#rfc.xref.RFC7234.4">4.3.2</a>, <a href="#rfc.xref.RFC7234.5">4.3.3</a>, <a href="#rfc.xref.RFC7234.6">4.3.4</a>, <a href="#rfc.xref.RFC7234.7">4.3.5</a>, <a href="#rfc.xref.RFC7234.8">5.1</a>, <a href="#rfc.xref.RFC7234.9">5.1</a>, <a href="#rfc.xref.RFC7234.10">6.1</a>, <a href="#rfc.xref.RFC7234.11">6.3.1</a>, <a href="#rfc.xref.RFC7234.12">6.3.4</a>, <a href="#rfc.xref.RFC7234.13">6.3.4</a>, <a href="#rfc.xref.RFC7234.14">6.3.5</a>, <a href="#rfc.xref.RFC7234.15">6.4.1</a>, <a href="#rfc.xref.RFC7234.16">6.4.2</a>, <a href="#rfc.xref.RFC7234.17">6.5.4</a>, <a href="#rfc.xref.RFC7234.18">6.5.5</a>, <a href="#rfc.xref.RFC7234.19">6.5.9</a>, <a href="#rfc.xref.RFC7234.20">6.5.12</a>, <a href="#rfc.xref.RFC7234.21">6.6.2</a>, <a href="#rfc.xref.RFC7234.22">7.1</a>, <a href="#rfc.xref.RFC7234.23">7.1</a>, <a href="#rfc.xref.RFC7234.24">7.1</a>, <a href="#rfc.xref.RFC7234.25">7.1</a>, <a href="#rfc.xref.RFC7234.26">7.1.4</a>, <a href="#rfc.xref.RFC7234.27">7.1.4</a>, <a href="#rfc.xref.RFC7234.28">8.2.2</a>, <a href="#RFC7234"><b>11.1</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.26">7.1.4</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.5">4.3.3</a></li><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.11">6.3.1</a>, <a href="#rfc.xref.RFC7234.13">6.3.4</a>, <a href="#rfc.xref.RFC7234.14">6.3.5</a>, <a href="#rfc.xref.RFC7234.15">6.4.1</a>, <a href="#rfc.xref.RFC7234.16">6.4.2</a>, <a href="#rfc.xref.RFC7234.17">6.5.4</a>, <a href="#rfc.xref.RFC7234.18">6.5.5</a>, <a href="#rfc.xref.RFC7234.19">6.5.9</a>, <a href="#rfc.xref.RFC7234.20">6.5.12</a>, <a href="#rfc.xref.RFC7234.21">6.6.2</a></li><li><em>Section 4.3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.4">4.3.2</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.6">4.3.4</a>, <a href="#rfc.xref.RFC7234.7">4.3.5</a></li><li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.22">7.1</a></li><li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.2">4.3.1</a>, <a href="#rfc.xref.RFC7234.3">4.3.2</a>, <a href="#rfc.xref.RFC7234.8">5.1</a>, <a href="#rfc.xref.RFC7234.23">7.1</a>, <a href="#rfc.xref.RFC7234.27">7.1.4</a></li><li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.24">7.1</a></li><li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.9">5.1</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.12">6.3.4</a>, <a href="#rfc.xref.RFC7234.25">7.1</a></li></ul></li><li><em>RFC7235</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">4.3.8</a>, <a href="#rfc.xref.RFC7235.2">5.4</a>, <a href="#rfc.xref.RFC7235.3">5.4</a>, <a href="#rfc.xref.RFC7235.4">5.4</a>, <a href="#rfc.xref.RFC7235.5">6.1</a>, <a href="#rfc.xref.RFC7235.6">6.1</a>, <a href="#rfc.xref.RFC7235.7">6.1</a>, <a href="#rfc.xref.RFC7235.8">7.1.4</a>, <a href="#rfc.xref.RFC7235.9">7.3</a>, <a href="#rfc.xref.RFC7235.10">7.3</a>, <a href="#RFC7235"><b>11.1</b></a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.5">6.1</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.6">6.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.7">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.9">7.3</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.3">5.4</a>, <a href="#rfc.xref.RFC7235.8">7.1.4</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.10">7.3</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.4">5.4</a></li></ul></li><li><em>RFC7238</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7238.1">6.4.7</a>, <a href="#RFC7238"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.2.1</b></a></li><li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3</b></a>, <a href="#rfc.iref.s.8">7.2</a></li><li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.9"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.6</a></li><li>Status Codes Classes&nbsp;&nbsp;<ul><li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.2</b></a></li><li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.3</b></a></li><li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li><li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.5</b></a></li><li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>6.6</b></a></li></ul></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.2</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li></ul></li><li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul><li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.6</a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.4.1</a>, <a href="#rfc.xref.header.vary.2">7.1</a>, <a href="#rfc.iref.v.1"><b>7.1.4</b></a>, <a href="#rfc.xref.header.vary.3">8.3.1</a>, <a href="#rfc.xref.header.vary.4">8.3.2</a></li></ul></li><li><a id="rfc.index.X" href="#rfc.index.X"><b>X</b></a><ul><li>x-compress (content coding)&nbsp;&nbsp;<a href="#rfc.iref.x.1"><b>3.1.2.1</b></a></li><li>x-gzip (content coding)&nbsp;&nbsp;<a href="#rfc.iref.x.2"><b>3.1.2.1</b></a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
     801</pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.X">X</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">6.1</a>, <a href="#rfc.iref.1.3"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.2">8.2.3</a></li><li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.1.1"><b>5.1.1</b></a></li><li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.1.4"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li><li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.1.2"><b>6.2</b></a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.2.2"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">8.2.3</a></li><li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.2.3"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">8.2.3</a>, <a href="#rfc.xref.status.201.3">B</a></li><li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.2.4"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">8.2.3</a></li><li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.2.5"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">8.2.3</a>, <a href="#rfc.xref.status.203.3">B</a></li><li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.2.6"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">8.2.3</a></li><li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.2.7"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">8.2.3</a></li><li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.2.1"><b>6.3</b></a></li></ul></li><li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul><li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.3.2"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">6.5.6</a>, <a href="#rfc.xref.status.300.3">8.2.3</a></li><li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.3.3"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">8.2.3</a>, <a href="#rfc.xref.status.301.3">B</a></li><li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.3.4"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">8.2.3</a>, <a href="#rfc.xref.status.302.3">B</a></li><li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.3.5"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">8.2.3</a>, <a href="#rfc.xref.status.303.3">B</a></li><li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.3.6"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">8.2.3</a>, <a href="#rfc.xref.status.305.3">B</a></li><li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.3.7"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li><li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.3.8"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li><li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.3.1"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.4.2"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">8.2.3</a>, <a href="#rfc.xref.status.400.3">B</a></li><li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.4.3"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">8.2.3</a></li><li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.4.4"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">8.2.3</a></li><li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.4.5"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">8.2.3</a></li><li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.4.6"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">8.2.3</a></li><li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.4.7"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">8.2.3</a></li><li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.4.8"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">8.2.3</a></li><li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.4.9"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">8.2.3</a></li><li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.4.10"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">8.2.3</a></li><li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.4.11"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">8.2.3</a></li><li>413 Payload Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.4.12"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">8.2.3</a></li><li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.4.13"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">8.2.3</a></li><li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.4.14"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">8.2.3</a></li><li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.4.15"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">8.2.3</a></li><li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.4.16"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">8.2.3</a>, <a href="#rfc.xref.status.426.3">B</a></li><li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.4.1"><b>6.5</b></a></li></ul></li><li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul><li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.5.2"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">8.2.3</a></li><li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.5.3"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">8.2.3</a></li><li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.5.4"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">8.2.3</a></li><li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.5.5"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">8.2.3</a></li><li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.5.6"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">8.2.3</a></li><li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.5.7"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">8.2.3</a></li><li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.5.1"><b>6.6</b></a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.1.1.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.3.2</a></li><li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3.2</a>, <a href="#rfc.xref.header.accept-charset.3">B</a></li><li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.1.2.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.3.2</a>, <a href="#rfc.xref.header.accept-encoding.4">8.4.2</a></li><li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.1.3.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">8.3.2</a></li><li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3.2</a>, <a href="#rfc.xref.header.allow.4">B</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP13</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP13.1">3.1.1.1</a>, <a href="#BCP13"><b>11.2</b></a></li><li><em>BCP178</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP178.1">8.3.1</a>, <a href="#BCP178"><b>11.2</b></a></li><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">8.3</a>, <a href="#rfc.xref.BCP90.2">8.3.1</a>, <a href="#BCP90"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>4.2.3</b></a></li><li>compress (content coding)&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>3.1.2.1</b></a></li><li>conditional request&nbsp;&nbsp;<a href="#rfc.iref.c.10"><b>5.2</b></a></li><li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.9"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">8.1.3</a>, <a href="#rfc.xref.CONNECT.3">B</a></li><li>content coding&nbsp;&nbsp;<a href="#rfc.iref.c.3"><b>3.1.2.1</b></a></li><li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li><li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.1</a>, <a href="#rfc.xref.header.content-encoding.2">3.1.2.1</a>, <a href="#rfc.iref.c.5"><b>3.1.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.3">8.3.2</a></li><li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.1</a>, <a href="#rfc.iref.c.6"><b>3.1.3.2</b></a>, <a href="#rfc.xref.header.content-language.2">8.3.2</a></li><li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.7"><b>3.1.4.2</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.2</a>, <a href="#rfc.xref.header.content-location.4">8.3.2</a>, <a href="#rfc.xref.header.content-location.5">B</a></li><li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.11">A.5</a></li><li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">3.1.1.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1.5</b></a>, <a href="#rfc.xref.header.content-type.3">8.3.1</a>, <a href="#rfc.xref.header.content-type.4">8.3.2</a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">7.1</a>, <a href="#rfc.iref.d.3"><b>7.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">8.3.2</a></li><li>deflate (content coding)&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>3.1.2.1</b></a></li><li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.2"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">8.1.3</a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.expect.2">6.2.1</a>, <a href="#rfc.xref.header.expect.3">6.5.14</a>, <a href="#rfc.xref.header.expect.4">8.3.2</a>, <a href="#rfc.xref.header.expect.5">B</a></li></ul></li><li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul><li>From header field&nbsp;&nbsp;<a href="#rfc.xref.header.from.1">5.5</a>, <a href="#rfc.iref.f.1"><b>5.5.1</b></a>, <a href="#rfc.xref.header.from.2">8.3.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.1.4.2</a>, <a href="#rfc.xref.GET.3">3.3</a>, <a href="#rfc.xref.GET.4">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.5">8.1.3</a>, <a href="#rfc.xref.GET.6">B</a></li><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Accept</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>5.3.2</b></a></li><li><tt>Accept-Charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>5.3.3</b></a></li><li><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>5.3.4</b></a></li><li><tt>accept-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>5.3.2</b></a></li><li><tt>Accept-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>5.3.5</b></a></li><li><tt>accept-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.2</b></a></li><li><tt>Allow</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>7.4.1</b></a></li><li><tt>asctime-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>7.1.1.1</b></a></li><li><tt>charset</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>3.1.1.2</b></a></li><li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>5.3.4</b></a></li><li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>3.1.2.1</b></a></li><li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>3.1.2.2</b></a></li><li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>3.1.3.2</b></a></li><li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>3.1.4.2</b></a></li><li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>3.1.1.5</b></a></li><li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>7.1.1.2</b></a></li><li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>7.1.1.1</b></a></li><li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>7.1.1.1</b></a></li><li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li><li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>7.1.1.1</b></a></li><li><tt>delay-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.52"><b>7.1.3</b></a></li><li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>5.1.1</b></a></li><li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>5.5.1</b></a></li><li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li><li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>7.1.1.1</b></a></li><li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>7.1.1.1</b></a></li><li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>7.1.1.1</b></a></li><li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>5.3.5</b></a></li><li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.1.3.1</b></a></li><li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>7.1.2</b></a></li><li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>5.1.2</b></a></li><li><tt>media-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>5.3.2</b></a></li><li><tt>media-type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.1.1</b></a></li><li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>4.1</b></a></li><li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>7.1.1.1</b></a></li><li><tt>month</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li><li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>7.1.1.1</b></a></li><li><tt>parameter</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.1.1.1</b></a></li><li><tt>product</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>5.5.3</b></a></li><li><tt>product-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>5.5.3</b></a></li><li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>5.3.1</b></a></li><li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>5.5.2</b></a></li><li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>7.1.3</b></a></li><li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>7.1.1.1</b></a></li><li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li><li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.55"><b>7.4.2</b></a></li><li><tt>subtype</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.1.1.1</b></a></li><li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>7.1.1.1</b></a></li><li><tt>type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1.1.1</b></a></li><li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>5.5.3</b></a></li><li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.4</b></a></li><li><tt>weight</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>5.3.1</b></a></li><li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>7.1.1.1</b></a></li></ul></li><li>gzip (content coding)&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.1.2.1</b></a></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3.1.4.2</a>, <a href="#rfc.xref.HEAD.2">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.3">8.1.3</a></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>idempotent&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>4.2.2</b></a></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">B</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Max-Forwards header field&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1.2</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">B</a></li><li>MIME-Version header field&nbsp;&nbsp;<a href="#rfc.xref.mime-version.1">8.3.2</a>, <a href="#rfc.iref.m.2"><b>A.1</b></a></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>OPTIONS method&nbsp;&nbsp;<a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.11">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.12">B</a></li><li><em>OWASP</em>&nbsp;&nbsp;<a href="#rfc.xref.OWASP.1">9</a>, <a href="#OWASP"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li><li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.1.4.2</a>, <a href="#rfc.xref.POST.2">3.3</a>, <a href="#rfc.xref.POST.3">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.4">8.1.3</a></li><li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1.4.2</a>, <a href="#rfc.xref.PUT.2">3.3</a>, <a href="#rfc.xref.PUT.3">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.4">8.1.3</a>, <a href="#rfc.xref.PUT.5">B</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.4</a>, <a href="#rfc.xref.header.referer.4">B</a></li><li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>3</b></a></li><li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li><li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3.2</a></li><li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a><ul><li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a></li></ul></li><li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">3.1.1.3</a>, <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.2">A</a>, <a href="#rfc.xref.RFC2045.3">A.1</a></li><li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.1.1.1</a>, <a href="#rfc.xref.RFC2046.2">3.1.1.4</a>, <a href="#rfc.xref.RFC2046.3">3.1.1.5</a>, <a href="#RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul><li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">3.1.1.5</a></li><li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.2">3.1.1.4</a></li></ul></li><li><em>RFC2049</em>&nbsp;&nbsp;<a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">A.2</a><ul><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2049.1">A.2</a></li></ul></li><li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">5.1.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul><li><em>Section 10.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">6.4</a></li></ul></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>11.1</b></a></li><li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.4</a>, <a href="#RFC2295"><b>11.2</b></a></li><li><em>RFC2388</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2388.1">3.1.1.4</a>, <a href="#RFC2388"><b>11.2</b></a></li><li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4.2</a>, <a href="#RFC2557"><b>11.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4.2</a></li></ul></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a>, <a href="#RFC2616"><b>11.2</b></a><ul><li><em>Section 14.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">5.3.5</a></li></ul></li><li><em>RFC2774</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2774.1">8.1.2</a>, <a href="#RFC2774"><b>11.2</b></a></li><li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#RFC2817"><b>11.2</b></a>, <a href="#rfc.xref.RFC2817.2">B</a>, <a href="#rfc.xref.RFC2817.3">B</a>, <a href="#rfc.xref.RFC2817.4">B</a><ul><li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">8.2</a>, <a href="#rfc.xref.RFC2817.4">B</a></li></ul></li><li><em>RFC2978</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2978.1">3.1.1.2</a>, <a href="#RFC2978"><b>11.2</b></a></li><li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">5.5.2</a>, <a href="#rfc.xref.RFC3986.2">7.1.2</a>, <a href="#rfc.xref.RFC3986.3">7.1.2</a>, <a href="#RFC3986"><b>11.1</b></a><ul><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.2</a></li><li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.3">7.1.2</a></li></ul></li><li><em>RFC4647</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.1">5.3.5</a>, <a href="#rfc.xref.RFC4647.2">5.3.5</a>, <a href="#rfc.xref.RFC4647.3">5.3.5</a>, <a href="#rfc.xref.RFC4647.4">5.3.5</a>, <a href="#RFC4647"><b>11.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.1">5.3.5</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.2">5.3.5</a></li><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.3">5.3.5</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4647.4">5.3.5</a></li></ul></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">8.1.1</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#rfc.xref.RFC5226.3">8.4.1</a>, <a href="#RFC5226"><b>11.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">8.1.1</a>, <a href="#rfc.xref.RFC5226.2">8.2.1</a>, <a href="#rfc.xref.RFC5226.3">8.4.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">8.3.1</a>, <a href="#RFC5234"><b>11.1</b></a>, <a href="#rfc.xref.RFC5234.3">C</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.3">C</a></li></ul></li><li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">4.3.6</a>, <a href="#RFC5246"><b>11.2</b></a></li><li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.6">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.7">A</a><ul><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a></li><li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.6">7.1.1.2</a></li></ul></li><li><em>RFC5646</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5646.1">3.1.3.1</a>, <a href="#rfc.xref.RFC5646.2">3.1.3.1</a>, <a href="#rfc.xref.RFC5646.3">3.1.3.1</a>, <a href="#RFC5646"><b>11.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5646.2">3.1.3.1</a></li></ul></li><li><em>RFC5789</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5789.1">4.3.4</a>, <a href="#RFC5789"><b>11.2</b></a></li><li><em>RFC5905</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5905.1">7.1.1.1</a>, <a href="#RFC5905"><b>11.2</b></a></li><li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">8.3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li><li><em>RFC5988</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5988.1">6.4.1</a>, <a href="#RFC5988"><b>11.2</b></a></li><li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">4.3.8</a>, <a href="#rfc.xref.RFC6265.2">5.4</a>, <a href="#RFC6265"><b>11.2</b></a></li><li><em>RFC6266</em>&nbsp;&nbsp;<a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">B</a></li><li><em>RFC6365</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6365.1">1.2</a>, <a href="#rfc.xref.RFC6365.2">3.1.1.2</a>, <a href="#RFC6365"><b>11.1</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2</a>, <a href="#rfc.xref.RFC7230.5">2</a>, <a href="#rfc.xref.RFC7230.6">2</a>, <a href="#rfc.xref.RFC7230.7">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.8">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.9">3.1.2.1</a>, <a href="#rfc.xref.RFC7230.10">3.1.2.2</a>, <a href="#rfc.xref.RFC7230.11">3.1.4.1</a>, <a href="#rfc.xref.RFC7230.12">3.1.4.2</a>, <a href="#rfc.xref.RFC7230.13">3.3</a>, <a href="#rfc.xref.RFC7230.14">3.3</a>, <a href="#rfc.xref.RFC7230.15">3.3</a>, <a href="#rfc.xref.RFC7230.16">4.3.6</a>, <a href="#rfc.xref.RFC7230.17">4.3.7</a>, <a href="#rfc.xref.RFC7230.18">4.3.8</a>, <a href="#rfc.xref.RFC7230.19">4.3.8</a>, <a href="#rfc.xref.RFC7230.20">5.1</a>, <a href="#rfc.xref.RFC7230.21">5.1</a>, <a href="#rfc.xref.RFC7230.22">5.1.1</a>, <a href="#rfc.xref.RFC7230.23">5.5.3</a>, <a href="#rfc.xref.RFC7230.24">6.2.2</a>, <a href="#rfc.xref.RFC7230.25">6.3.4</a>, <a href="#rfc.xref.RFC7230.26">6.5.7</a>, <a href="#rfc.xref.RFC7230.27">6.5.10</a>, <a href="#rfc.xref.RFC7230.28">6.5.12</a>, <a href="#rfc.xref.RFC7230.29">6.5.15</a>, <a href="#rfc.xref.RFC7230.30">6.6.6</a>, <a href="#rfc.xref.RFC7230.31">7.4.2</a>, <a href="#rfc.xref.RFC7230.32">8.1.2</a>, <a href="#rfc.xref.RFC7230.33">8.3.1</a>, <a href="#rfc.xref.RFC7230.34">8.3.1</a>, <a href="#rfc.xref.RFC7230.35">8.3.1</a>, <a href="#rfc.xref.RFC7230.36">8.3.1</a>, <a href="#rfc.xref.RFC7230.37">8.3.1</a>, <a href="#rfc.xref.RFC7230.38">8.3.1</a>, <a href="#rfc.xref.RFC7230.39">8.3.1</a>, <a href="#rfc.xref.RFC7230.40">8.4</a>, <a href="#rfc.xref.RFC7230.41">8.4.1</a>, <a href="#rfc.xref.RFC7230.42">8.4.1</a>, <a href="#rfc.xref.RFC7230.43">9</a>, <a href="#rfc.xref.RFC7230.44">9.6</a>, <a href="#rfc.xref.RFC7230.45">10</a>, <a href="#RFC7230"><b>11.1</b></a>, <a href="#rfc.xref.RFC7230.46">B</a>, <a href="#rfc.xref.RFC7230.47">C</a>, <a href="#rfc.xref.RFC7230.48">C</a>, <a href="#rfc.xref.RFC7230.49">C</a>, <a href="#rfc.xref.RFC7230.50">C</a>, <a href="#rfc.xref.RFC7230.51">C</a>, <a href="#rfc.xref.RFC7230.52">C</a>, <a href="#rfc.xref.RFC7230.53">C</a>, <a href="#rfc.xref.RFC7230.54">C</a>, <a href="#rfc.xref.RFC7230.55">C</a>, <a href="#rfc.xref.RFC7230.56">C</a>, <a href="#rfc.xref.RFC7230.57">C</a>, <a href="#rfc.xref.RFC7230.58">D</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.58">D</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.30">6.6.6</a></li><li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2</a>, <a href="#rfc.xref.RFC7230.51">C</a>, <a href="#rfc.xref.RFC7230.52">C</a>, <a href="#rfc.xref.RFC7230.55">C</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.23">5.5.3</a>, <a href="#rfc.xref.RFC7230.31">7.4.2</a>, <a href="#rfc.xref.RFC7230.33">8.3.1</a>, <a href="#rfc.xref.RFC7230.37">8.3.1</a>, <a href="#rfc.xref.RFC7230.54">C</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.48">C</a>, <a href="#rfc.xref.RFC7230.49">C</a>, <a href="#rfc.xref.RFC7230.50">C</a></li><li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.35">8.3.1</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.36">8.3.1</a>, <a href="#rfc.xref.RFC7230.53">C</a>, <a href="#rfc.xref.RFC7230.56">C</a>, <a href="#rfc.xref.RFC7230.57">C</a></li><li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">3.1.2.2</a>, <a href="#rfc.xref.RFC7230.15">3.3</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.32">8.1.2</a></li><li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.13">3.3</a>, <a href="#rfc.xref.RFC7230.27">6.5.10</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.41">8.4.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.39">8.3.1</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.7">3.1.2.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.40">8.4</a>, <a href="#rfc.xref.RFC7230.42">8.4.1</a></li><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">3.1.2.1</a></li><li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">3.1.2.1</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.21">5.1</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.14">3.3</a></li><li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.5">2</a>, <a href="#rfc.xref.RFC7230.16">4.3.6</a>, <a href="#rfc.xref.RFC7230.17">4.3.7</a>, <a href="#rfc.xref.RFC7230.28">6.5.12</a></li><li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.20">5.1</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">2</a>, <a href="#rfc.xref.RFC7230.11">3.1.4.1</a>, <a href="#rfc.xref.RFC7230.12">3.1.4.2</a></li><li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.19">4.3.8</a>, <a href="#rfc.xref.RFC7230.44">9.6</a></li><li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.25">6.3.4</a></li><li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.26">6.5.7</a>, <a href="#rfc.xref.RFC7230.38">8.3.1</a></li><li><em>Section 6.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.22">5.1.1</a></li><li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.24">6.2.2</a>, <a href="#rfc.xref.RFC7230.29">6.5.15</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.34">8.3.1</a></li><li><em>Section 8.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.18">4.3.8</a></li><li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.43">9</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.45">10</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">3</a>, <a href="#rfc.xref.RFC7232.2">4.1</a>, <a href="#rfc.xref.RFC7232.3">5.2</a>, <a href="#rfc.xref.RFC7232.4">5.2</a>, <a href="#rfc.xref.RFC7232.5">5.2</a>, <a href="#rfc.xref.RFC7232.6">5.2</a>, <a href="#rfc.xref.RFC7232.7">5.2</a>, <a href="#rfc.xref.RFC7232.8">5.2</a>, <a href="#rfc.xref.RFC7232.9">6.1</a>, <a href="#rfc.xref.RFC7232.10">6.1</a>, <a href="#rfc.xref.RFC7232.11">6.1</a>, <a href="#rfc.xref.RFC7232.12">7.2</a>, <a href="#rfc.xref.RFC7232.13">7.2</a>, <a href="#rfc.xref.RFC7232.14">7.2</a>, <a href="#RFC7232"><b>11.1</b></a><ul><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.14">7.2</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.13">7.2</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">5.2</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">5.2</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.7">5.2</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.8">5.2</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.9">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.10">6.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.11">6.1</a></li><li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.4">5.2</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.1.1.4</a>, <a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.3">4.3.1</a>, <a href="#rfc.xref.RFC7233.4">4.3.4</a>, <a href="#rfc.xref.RFC7233.5">5.1</a>, <a href="#rfc.xref.RFC7233.6">5.2</a>, <a href="#rfc.xref.RFC7233.7">6.1</a>, <a href="#rfc.xref.RFC7233.8">6.1</a>, <a href="#rfc.xref.RFC7233.9">6.1</a>, <a href="#rfc.xref.RFC7233.10">7.4</a>, <a href="#rfc.xref.RFC7233.11">8.1.2</a>, <a href="#RFC7233"><b>11.1</b></a>, <a href="#rfc.xref.RFC7233.12">A.6</a><ul><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.10">7.4</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.5">5.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.6">5.2</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.7">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.8">6.1</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.4">4.3.4</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.9">6.1</a></li><li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.12">A.6</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2.3</a>, <a href="#rfc.xref.RFC7234.2">4.3.1</a>, <a href="#rfc.xref.RFC7234.3">4.3.2</a>, <a href="#rfc.xref.RFC7234.4">4.3.2</a>, <a href="#rfc.xref.RFC7234.5">4.3.3</a>, <a href="#rfc.xref.RFC7234.6">4.3.4</a>, <a href="#rfc.xref.RFC7234.7">4.3.5</a>, <a href="#rfc.xref.RFC7234.8">5.1</a>, <a href="#rfc.xref.RFC7234.9">5.1</a>, <a href="#rfc.xref.RFC7234.10">6.1</a>, <a href="#rfc.xref.RFC7234.11">6.3.1</a>, <a href="#rfc.xref.RFC7234.12">6.3.4</a>, <a href="#rfc.xref.RFC7234.13">6.3.4</a>, <a href="#rfc.xref.RFC7234.14">6.3.5</a>, <a href="#rfc.xref.RFC7234.15">6.4.1</a>, <a href="#rfc.xref.RFC7234.16">6.4.2</a>, <a href="#rfc.xref.RFC7234.17">6.5.4</a>, <a href="#rfc.xref.RFC7234.18">6.5.5</a>, <a href="#rfc.xref.RFC7234.19">6.5.9</a>, <a href="#rfc.xref.RFC7234.20">6.5.12</a>, <a href="#rfc.xref.RFC7234.21">6.6.2</a>, <a href="#rfc.xref.RFC7234.22">7.1</a>, <a href="#rfc.xref.RFC7234.23">7.1</a>, <a href="#rfc.xref.RFC7234.24">7.1</a>, <a href="#rfc.xref.RFC7234.25">7.1</a>, <a href="#rfc.xref.RFC7234.26">7.1.4</a>, <a href="#rfc.xref.RFC7234.27">7.1.4</a>, <a href="#rfc.xref.RFC7234.28">8.2.2</a>, <a href="#RFC7234"><b>11.1</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.26">7.1.4</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.5">4.3.3</a></li><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.11">6.3.1</a>, <a href="#rfc.xref.RFC7234.13">6.3.4</a>, <a href="#rfc.xref.RFC7234.14">6.3.5</a>, <a href="#rfc.xref.RFC7234.15">6.4.1</a>, <a href="#rfc.xref.RFC7234.16">6.4.2</a>, <a href="#rfc.xref.RFC7234.17">6.5.4</a>, <a href="#rfc.xref.RFC7234.18">6.5.5</a>, <a href="#rfc.xref.RFC7234.19">6.5.9</a>, <a href="#rfc.xref.RFC7234.20">6.5.12</a>, <a href="#rfc.xref.RFC7234.21">6.6.2</a></li><li><em>Section 4.3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.4">4.3.2</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.6">4.3.4</a>, <a href="#rfc.xref.RFC7234.7">4.3.5</a></li><li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.22">7.1</a></li><li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.2">4.3.1</a>, <a href="#rfc.xref.RFC7234.3">4.3.2</a>, <a href="#rfc.xref.RFC7234.8">5.1</a>, <a href="#rfc.xref.RFC7234.23">7.1</a>, <a href="#rfc.xref.RFC7234.27">7.1.4</a></li><li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.24">7.1</a></li><li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.9">5.1</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.12">6.3.4</a>, <a href="#rfc.xref.RFC7234.25">7.1</a></li></ul></li><li><em>RFC7235</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">4.3.8</a>, <a href="#rfc.xref.RFC7235.2">5.4</a>, <a href="#rfc.xref.RFC7235.3">5.4</a>, <a href="#rfc.xref.RFC7235.4">5.4</a>, <a href="#rfc.xref.RFC7235.5">6.1</a>, <a href="#rfc.xref.RFC7235.6">6.1</a>, <a href="#rfc.xref.RFC7235.7">6.1</a>, <a href="#rfc.xref.RFC7235.8">7.1.4</a>, <a href="#rfc.xref.RFC7235.9">7.3</a>, <a href="#rfc.xref.RFC7235.10">7.3</a>, <a href="#RFC7235"><b>11.1</b></a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.5">6.1</a></li><li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.6">6.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.7">6.1</a></li><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.9">7.3</a></li><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.3">5.4</a>, <a href="#rfc.xref.RFC7235.8">7.1.4</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.10">7.3</a></li><li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.4">5.4</a></li></ul></li><li><em>RFC7238</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7238.1">6.4.7</a>, <a href="#RFC7238"><b>11.2</b></a></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.2.1</b></a></li><li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3</b></a>, <a href="#rfc.iref.s.8">7.2</a></li><li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.9"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.6</a></li><li>Status Codes Classes&nbsp;&nbsp;<ul><li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.2</b></a></li><li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.3</b></a></li><li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li><li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.5</b></a></li><li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>6.6</b></a></li></ul></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>TRACE method&nbsp;&nbsp;<a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.2</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li></ul></li><li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul><li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.6</a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.4.1</a>, <a href="#rfc.xref.header.vary.2">7.1</a>, <a href="#rfc.iref.v.1"><b>7.1.4</b></a>, <a href="#rfc.xref.header.vary.3">8.3.1</a>, <a href="#rfc.xref.header.vary.4">8.3.2</a></li></ul></li><li><a id="rfc.index.X" href="#rfc.index.X"><b>X</b></a><ul><li>x-compress (content coding)&nbsp;&nbsp;<a href="#rfc.iref.x.1"><b>3.1.2.1</b></a></li><li>x-gzip (content coding)&nbsp;&nbsp;<a href="#rfc.iref.x.2"><b>3.1.2.1</b></a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
    802802      (editor)
    803803    <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p><p><b>Julian F. Reschke</b>
  • specs/rfc7232.html

    r2725 r2726  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Validators" href="#rfc.section.2"><link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"><link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 Evaluation" href="#rfc.section.5"><link rel="Chapter" title="6 Precedence" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7231.html" rel="prev"><link href="rfc7233.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7232.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7232"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7232"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP conditional requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7232"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."></head><body onload="getMeta(7232,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7232</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">greenbytes</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7232">http://www.rfc-editor.org/info/rfc7232</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#validators">Validators</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.last-modified">Last-Modified</a><ul><li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.generation">Generation</a></li><li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.comparison">Comparison</a></li></ul></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.etag">ETag</a><ul><li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li><li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li><li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li></ul></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#preconditions">Precondition Header Fields</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-match">If-Match</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-none-match">If-None-Match</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-modified-since">If-Modified-Since</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-unmodified-since">If-Unmodified-Since</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.304">304 Not Modified</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#evaluation">Evaluation</a></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.</p><p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.</p><p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification (<a href="#preconditions" title="Precondition Header Fields">Section&nbsp;3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section&nbsp;6</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="validators"><div id="rfc.iref.m.1"></div><div id="rfc.iref.v.1"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.</p><div id="weak.and.strong.validators"><div id="rfc.iref.v.2"></div><div id="rfc.iref.v.3"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></h2><p id="rfc.section.2.1.p.1">Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.</p><p id="rfc.section.2.1.p.2">A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to GET.</p><p id="rfc.section.2.1.p.3">A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="rfc7231.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.</p><p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).</p><p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.</p><p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.</p><p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.</p><p id="rfc.section.2.1.p.8">Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.</p><p id="rfc.section.2.1.p.9">Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.</p></div><div id="header.last-modified"><div id="rfc.iref.l.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#header.last-modified">Last-Modified</a></h2><p id="rfc.section.2.2.p.1">The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Validators" href="#rfc.section.2"><link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"><link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 Evaluation" href="#rfc.section.5"><link rel="Chapter" title="6 Precedence" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7231.html" rel="prev"><link href="rfc7233.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7232.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7232"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7232"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP conditional requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7232"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."></head><body onload="getMeta(7232,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7232</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">greenbytes</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7232">http://www.rfc-editor.org/info/rfc7232</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#validators">Validators</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.last-modified">Last-Modified</a><ul><li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.generation">Generation</a></li><li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#lastmod.comparison">Comparison</a></li></ul></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.etag">ETag</a><ul><li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li><li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li><li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li></ul></li><li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#preconditions">Precondition Header Fields</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-match">If-Match</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-none-match">If-None-Match</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-modified-since">If-Modified-Since</a></li><li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-unmodified-since">If-Unmodified-Since</a></li><li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.304">304 Not Modified</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#evaluation">Evaluation</a></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#precedence">Precedence</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p><p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.</p><p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.</p><p id="rfc.section.1.p.4">The conditional request preconditions defined by this specification (<a href="#preconditions" title="Precondition Header Fields">Section&nbsp;3</a>) are evaluated when applicable to the recipient (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>) according to their order of precedence (<a href="#precedence" title="Precedence">Section&nbsp;6</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="validators"><div id="rfc.iref.m.1"></div><div id="rfc.iref.v.1"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1><p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.</p><div id="weak.and.strong.validators"><div id="rfc.iref.v.2"></div><div id="rfc.iref.v.3"></div><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></h2><p id="rfc.section.2.1.p.1">Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.</p><p id="rfc.section.2.1.p.2">A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to GET.</p><p id="rfc.section.2.1.p.3">A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., <a href="rfc7231.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.</p><p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).</p><p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.</p><p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.</p><p id="rfc.section.2.1.p.7">For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.</p><p id="rfc.section.2.1.p.8">Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.</p><p id="rfc.section.2.1.p.9">Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.</p></div><div id="header.last-modified"><div id="rfc.iref.l.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#header.last-modified">Last-Modified</a></h2><p id="rfc.section.2.2.p.1">The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    505505</pre><p id="rfc.section.2.2.p.3">An example of its use is</p><div id="rfc.figure.u.2"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    506506</pre><div id="lastmod.generation"><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a href="#lastmod.generation">Generation</a></h3><p id="rfc.section.2.2.1.p.1">An origin server <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability.</p><p id="rfc.section.2.2.1.p.2">A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can use its value to make conditional requests and test the validity of locally cached responses.</p><p id="rfc.section.2.2.1.p.3">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the <a href="rfc7231.html#header.date" class="smpl">Date</a> field value for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially if the representation changes near the time that the response is generated.</p><p id="rfc.section.2.2.1.p.4">An origin server with a clock <em class="bcp14">MUST NOT</em> send a Last-Modified date that is later than the server's time of message origination (<a href="rfc7231.html#header.date" class="smpl">Date</a>). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's clock, then the origin server <em class="bcp14">MUST</em> replace that value with the message origination date. This prevents a future modification date from having an adverse impact on cache validation.</p><p id="rfc.section.2.2.1.p.5">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Last-Modified values to a response unless these values were associated with the resource by some other system or user with a reliable clock.</p></div><div id="lastmod.comparison"><h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;<a href="#lastmod.comparison">Comparison</a></h3><p id="rfc.section.2.2.2.p.1">A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: </p><ul><li>The validator is being compared by an origin server to the actual current validator for the representation and,</li><li>That origin server reliably knows that the associated representation did not change twice during the second covered by the presented validator.</li></ul><p id="rfc.section.2.2.2.p.2">or </p><ul><li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, or <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> header field, because the client has a cache entry for the associated representation, and</li><li>That cache entry includes a <a href="rfc7231.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and</li><li>The presented Last-Modified time is at least 60 seconds before the Date value.</li></ul><p id="rfc.section.2.2.2.p.3">or </p><ul><li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and</li><li>That cache entry includes a <a href="rfc7231.html#header.date" class="smpl">Date</a> value, which gives the time when the origin server sent the original response, and</li><li>The presented Last-Modified time is at least 60 seconds before the Date value.</li></ul><p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a <a href="rfc7231.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.</p></div></div><div id="header.etag"><div id="rfc.iref.e.1"></div><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a href="#header.etag">ETag</a></h2><p id="rfc.section.2.3.p.1">The "ETag" header field in a response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.</p><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.etag" class="smpl">ETag</a>       = <a href="#header.etag" class="smpl">entity-tag</a>
     
    552552</pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.</p><p id="rfc.section.3.3.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is neither GET nor HEAD.</p><p id="rfc.section.3.3.p.7">A recipient <em class="bcp14">MUST</em> interpret an If-Modified-Since field-value's timestamp in terms of the origin server's clock.</p><p id="rfc.section.3.3.p.8">If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.</p><p id="rfc.section.3.3.p.9">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived backup). However, caches occasionally generate the field value based on other data, such as the <a href="rfc7231.html#header.date" class="smpl">Date</a> header field of the cached message or the local clock time that the message was received, particularly when the cached message does not contain a <a href="#header.last-modified" class="smpl">Last-Modified</a> field.</p><p id="rfc.section.3.3.p.10">When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field value based on either its own local clock or a <a href="rfc7231.html#header.date" class="smpl">Date</a> header field received from the server in a prior response. Origin servers that choose an exact timestamp match based on the selected representation's <a href="#header.last-modified" class="smpl">Last-Modified</a> field will not be able to help the user agent limit its data transfers to only those changed during the specified window.</p><p id="rfc.section.3.3.p.11">An origin server that receives an If-Modified-Since header field <em class="bcp14">SHOULD</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The origin server <em class="bcp14">SHOULD NOT</em> perform the requested method if the selected representation's last modification date is earlier than or equal to the date provided in the field-value; instead, the origin server <em class="bcp14">SHOULD</em> generate a <a href="#status.304" class="smpl">304 (Not Modified)</a> response, including only those metadata that are useful for identifying or updating a previously cached response.</p><p id="rfc.section.3.3.p.12">Requirements on cache handling of a received If-Modified-Since header field are defined in <a href="rfc7234.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.</p></div><div id="header.if-unmodified-since"><div id="rfc.iref.i.4"></div><h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a href="#header.if-unmodified-since">If-Unmodified-Since</a></h2><p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field makes the request method conditional on the selected representation's last modification date being earlier than or equal to the date provided in the field-value. This field accomplishes the same purpose as <a href="#header.if-match" class="smpl">If-Match</a> for cases where the user agent does not have an entity-tag for the representation.</p><div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    553553</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p><div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    554 </pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>.</p><p id="rfc.section.3.4.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.</p><p id="rfc.section.3.4.p.7">A recipient <em class="bcp14">MUST</em> interpret an If-Unmodified-Since field-value's timestamp in terms of the origin server's clock.</p><p id="rfc.section.3.4.p.8">If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the <a href="rfc7231.html#representations" class="smpl">selected representation</a> does not match one already stored (or partially stored) from a prior request.</p><p id="rfc.section.3.4.p.9">An origin server that receives an If-Unmodified-Since header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The origin server <em class="bcp14">MUST NOT</em> perform the requested method if the selected representation's last modification date is more recent than the date provided in the field-value; instead the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code or b) one of the <a href="rfc7231.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.</p><p id="rfc.section.3.4.p.10">The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.</p></div><div id="header.if-range"><h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a href="#header.if-range">If-Range</a></h2><p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but that instructs the recipient to ignore the <a href="rfc7233.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response. If-Range is defined in <a href="rfc7233.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.</p></div></div><div id="status.code.definitions"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#status.code.definitions">Status Code Definitions</a></h1><div id="status.304"><div id="rfc.iref.21"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#status.304">304 Not Modified</a></h2><p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response.</p><p id="rfc.section.4.1.p.2">The server generating a 304 response <em class="bcp14">MUST</em> generate any of the following header fields that would have been sent in a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to the same request: <a href="rfc7234.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="rfc7231.html#header.content-location" class="smpl">Content-Location</a>, <a href="rfc7231.html#header.date" class="smpl">Date</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="rfc7234.html#header.expires" class="smpl">Expires</a>, and <a href="rfc7231.html#header.vary" class="smpl">Vary</a>.</p><p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender <em class="bcp14">SHOULD NOT</em> generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).</p><p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="rfc7234.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.4</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.</p><p id="rfc.section.4.1.p.5">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p></div><div id="status.412"><div id="rfc.iref.21"></div><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#status.412">412 Precondition Failed</a></h2><p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.</p></div></div><div id="evaluation"><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#evaluation">Evaluation</a></h1><p id="rfc.section.5.p.1">Except when excluded below, a recipient cache or origin server <em class="bcp14">MUST</em> evaluate received request preconditions after it has successfully performed its normal request checks and just before it would perform the action associated with the request method. A server <em class="bcp14">MUST</em> ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a <a href="rfc7231.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a>. In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.</p><p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and it <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can provide a current representation. Likewise, a server <em class="bcp14">MUST</em> ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a <a href="rfc7231.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE.</p><p id="rfc.section.5.p.3">Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (<a href="#RFC4918" id="rfc.xref.RFC4918.2"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-10.4">Section 10.4</a>).</p><p id="rfc.section.5.p.4">Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a <a href="#status.304" class="smpl">304 (Not Modified)</a> response and more useful than a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response.</p></div><div id="precedence"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#precedence">Precedence</a></h1><p id="rfc.section.6.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than a partial response, and entity tags are presumed to be more accurate than date validators.</p><p id="rfc.section.6.p.2">A recipient cache or origin server <em class="bcp14">MUST</em> evaluate the request preconditions defined by this specification in the following order: </p><ol><li id="precedence1">When recipient is the origin server and <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate the <a href="#header.if-match" class="smpl">If-Match</a> precondition: <ul><li>if true, continue to step <a href="#precedence3">3</a></li><li>if false, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a> unless it can be determined that the state-changing request has already succeeded (see <a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;3.1</a>)</li></ul> </li><li id="precedence2">When recipient is the origin server, <a href="#header.if-match" class="smpl">If-Match</a> is not present, and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> is present, evaluate the <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> precondition: <ul><li>if true, continue to step <a href="#precedence3">3</a></li><li>if false, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a> unless it can be determined that the state-changing request has already succeeded (see <a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.1" title="If-Unmodified-Since">Section&nbsp;3.4</a>)</li></ul> </li><li id="precedence3">When <a href="#header.if-none-match" class="smpl">If-None-Match</a> is present, evaluate the <a href="#header.if-none-match" class="smpl">If-None-Match</a> precondition: <ul><li>if true, continue to step <a href="#precedence5">5</a></li><li>if false for GET/HEAD, respond <a href="#status.304" class="smpl">304 (Not Modified)</a></li><li>if false for other methods, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a></li></ul> </li><li id="precedence4">When the method is GET or HEAD, <a href="#header.if-none-match" class="smpl">If-None-Match</a> is not present, and <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> is present, evaluate the <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> precondition: <ul><li>if true, continue to step <a href="#precedence5">5</a></li><li>if false, respond <a href="#status.304" class="smpl">304 (Not Modified)</a></li></ul> </li><li id="precedence5">When the method is GET and both <a href="rfc7233.html#header.range" class="smpl">Range</a> and <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> are present, evaluate the <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> precondition: <ul><li>if the validator matches and the Range specification is applicable to the selected representation, respond <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> <a href="#RFC7233" id="rfc.xref.RFC7233.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li></ul> </li><li id="precedencelast">Otherwise, <ul><li>all conditions are met, so perform the requested action and respond according to its success or failure.</li></ul> </li></ol><p id="rfc.section.6.p.3">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.</p></div><div id="IANA.considerations"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#IANA.considerations">IANA Considerations</a></h1><div id="status.code.registration"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#status.code.registration">Status Code Registration</a></h2><p id="rfc.section.7.1.p.1">The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; has been updated with the registrations below:</p><div id="rfc.table.1"><div id="iana.status.code.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead><tbody><tr><td class="left">304</td><td class="left">Not Modified</td><td class="left"><a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section&nbsp;4.1</a> </td></tr><tr><td class="left">412</td><td class="left">Precondition Failed</td><td class="left"><a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section&nbsp;4.2</a> </td></tr></tbody></table></div></div><div id="header.field.registration"><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2><p id="rfc.section.7.2.p.1">HTTP header fields are registered within the "Message Headers" registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/">http://www.iana.org/assignments/message-headers/</a>&gt;.</p><p id="rfc.section.7.2.p.2">This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>):</p><div id="rfc.table.2"><div id="iana.header.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Protocol</th><th>Status</th><th>Reference</th></tr></thead><tbody><tr><td class="left">ETag</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.etag" id="rfc.xref.header.etag.2" title="ETag">Section&nbsp;2.3</a> </td></tr><tr><td class="left">If-Match</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section&nbsp;3.1</a> </td></tr><tr><td class="left">If-Modified-Since</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-modified-since" id="rfc.xref.header.if-modified-since.1" title="If-Modified-Since">Section&nbsp;3.3</a> </td></tr><tr><td class="left">If-None-Match</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;3.2</a> </td></tr><tr><td class="left">If-Unmodified-Since</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.2" title="If-Unmodified-Since">Section&nbsp;3.4</a> </td></tr><tr><td class="left">Last-Modified</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.last-modified" id="rfc.xref.header.last-modified.2" title="Last-Modified">Section&nbsp;2.2</a> </td></tr></tbody></table></div><p id="rfc.section.7.2.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p></div></div><div id="security.considerations"><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP conditional request mechanisms. More general security considerations are addressed in HTTP "Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> and "Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.</p><p id="rfc.section.8.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.</p><p id="rfc.section.8.p.3">An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.</p></div><div id="acks"><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#acks">Acknowledgments</a></h1><p id="rfc.section.9.p.1">See <a href="rfc7230.html#acks" title="Acknowledgments">Section 10</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References</h2><table><tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC5234">[RFC5234]</b></td><td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>&#8221;, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC7230">[RFC7230]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>&#8221;, RFC&nbsp;7230, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7233">[RFC7233]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7233">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>&#8221;, RFC&nbsp;7233, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7234">[RFC7234]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Akamai">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7234">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>&#8221;, RFC&nbsp;7234, June&nbsp;2014.</td></tr></table><h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References</h2><table><tr><td class="reference"><b id="BCP90">[BCP90]</b></td><td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>&#8221;, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC2616">[RFC2616]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2616, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC4918">[RFC4918]</b></td><td class="top"><a href="mailto:ldusseault@commerce.net" title="CommerceNet">Dusseault, L., Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4918">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;4918, June&nbsp;2007.</td></tr></table><div id="changes.from.rfc.2616"><h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1><p id="rfc.section.A.p.1">The definition of validator weakness has been expanded and clarified. (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>)</p><p id="rfc.section.A.p.2">Weak entity-tags are now allowed in all requests except range requests. (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>)</p><p id="rfc.section.A.p.3">The <a href="#header.etag" class="smpl">ETag</a> header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)</p><p id="rfc.section.A.p.4">ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section&nbsp;2.3</a>)</p><p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section&nbsp;6</a>)</p></div><div id="imported.abnf"><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#imported.abnf">Imported ABNF</a></h1><p id="rfc.section.B.p.1">The following core rules are included by reference, as defined in <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></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), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).</p><p id="rfc.section.B.p.2">The rules below are defined in <a href="#RFC7230" id="rfc.xref.RFC7230.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>:</p><div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, see <a href="#RFC7230" id="rfc.xref.RFC7230.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     554</pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>.</p><p id="rfc.section.3.4.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.</p><p id="rfc.section.3.4.p.7">A recipient <em class="bcp14">MUST</em> interpret an If-Unmodified-Since field-value's timestamp in terms of the origin server's clock.</p><p id="rfc.section.3.4.p.8">If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the <a href="rfc7231.html#representations" class="smpl">selected representation</a> does not match one already stored (or partially stored) from a prior request.</p><p id="rfc.section.3.4.p.9">An origin server that receives an If-Unmodified-Since header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The origin server <em class="bcp14">MUST NOT</em> perform the requested method if the selected representation's last modification date is more recent than the date provided in the field-value; instead the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code or b) one of the <a href="rfc7231.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent). In the latter case, the origin server <em class="bcp14">MUST NOT</em> send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.</p><p id="rfc.section.3.4.p.10">The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.</p></div><div id="header.if-range"><h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a href="#header.if-range">If-Range</a></h2><p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but that instructs the recipient to ignore the <a href="rfc7233.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response. If-Range is defined in <a href="rfc7233.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.</p></div></div><div id="status.code.definitions"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#status.code.definitions">Status Code Definitions</a></h1><div id="status.304"><div id="rfc.iref.3.1"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#status.304">304 Not Modified</a></h2><p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD request has been received and would have resulted in a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response.</p><p id="rfc.section.4.1.p.2">The server generating a 304 response <em class="bcp14">MUST</em> generate any of the following header fields that would have been sent in a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to the same request: <a href="rfc7234.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="rfc7231.html#header.content-location" class="smpl">Content-Location</a>, <a href="rfc7231.html#header.date" class="smpl">Date</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="rfc7234.html#header.expires" class="smpl">Expires</a>, and <a href="rfc7231.html#header.vary" class="smpl">Vary</a>.</p><p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender <em class="bcp14">SHOULD NOT</em> generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field).</p><p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="rfc7234.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.3.4</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client.</p><p id="rfc.section.4.1.p.5">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p></div><div id="status.412"><div id="rfc.iref.4.1"></div><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#status.412">412 Precondition Failed</a></h2><p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.</p></div></div><div id="evaluation"><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#evaluation">Evaluation</a></h1><p id="rfc.section.5.p.1">Except when excluded below, a recipient cache or origin server <em class="bcp14">MUST</em> evaluate received request preconditions after it has successfully performed its normal request checks and just before it would perform the action associated with the request method. A server <em class="bcp14">MUST</em> ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a <a href="rfc7231.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a>. In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.</p><p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and it <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can provide a current representation. Likewise, a server <em class="bcp14">MUST</em> ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a <a href="rfc7231.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE.</p><p id="rfc.section.5.p.3">Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (<a href="#RFC4918" id="rfc.xref.RFC4918.2"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, <a href="https://tools.ietf.org/html/rfc4918#section-10.4">Section 10.4</a>).</p><p id="rfc.section.5.p.4">Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a <a href="#status.304" class="smpl">304 (Not Modified)</a> response and more useful than a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> response.</p></div><div id="precedence"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#precedence">Precedence</a></h1><p id="rfc.section.6.p.1">When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than a partial response, and entity tags are presumed to be more accurate than date validators.</p><p id="rfc.section.6.p.2">A recipient cache or origin server <em class="bcp14">MUST</em> evaluate the request preconditions defined by this specification in the following order: </p><ol><li id="precedence1">When recipient is the origin server and <a href="#header.if-match" class="smpl">If-Match</a> is present, evaluate the <a href="#header.if-match" class="smpl">If-Match</a> precondition: <ul><li>if true, continue to step <a href="#precedence3">3</a></li><li>if false, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a> unless it can be determined that the state-changing request has already succeeded (see <a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;3.1</a>)</li></ul> </li><li id="precedence2">When recipient is the origin server, <a href="#header.if-match" class="smpl">If-Match</a> is not present, and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> is present, evaluate the <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> precondition: <ul><li>if true, continue to step <a href="#precedence3">3</a></li><li>if false, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a> unless it can be determined that the state-changing request has already succeeded (see <a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.1" title="If-Unmodified-Since">Section&nbsp;3.4</a>)</li></ul> </li><li id="precedence3">When <a href="#header.if-none-match" class="smpl">If-None-Match</a> is present, evaluate the <a href="#header.if-none-match" class="smpl">If-None-Match</a> precondition: <ul><li>if true, continue to step <a href="#precedence5">5</a></li><li>if false for GET/HEAD, respond <a href="#status.304" class="smpl">304 (Not Modified)</a></li><li>if false for other methods, respond <a href="#status.412" class="smpl">412 (Precondition Failed)</a></li></ul> </li><li id="precedence4">When the method is GET or HEAD, <a href="#header.if-none-match" class="smpl">If-None-Match</a> is not present, and <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> is present, evaluate the <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> precondition: <ul><li>if true, continue to step <a href="#precedence5">5</a></li><li>if false, respond <a href="#status.304" class="smpl">304 (Not Modified)</a></li></ul> </li><li id="precedence5">When the method is GET and both <a href="rfc7233.html#header.range" class="smpl">Range</a> and <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> are present, evaluate the <a href="rfc7233.html#header.if-range" class="smpl">If-Range</a> precondition: <ul><li>if the validator matches and the Range specification is applicable to the selected representation, respond <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> <a href="#RFC7233" id="rfc.xref.RFC7233.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a></li></ul> </li><li id="precedencelast">Otherwise, <ul><li>all conditions are met, so perform the requested action and respond according to its success or failure.</li></ul> </li></ol><p id="rfc.section.6.p.3">Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.</p></div><div id="IANA.considerations"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#IANA.considerations">IANA Considerations</a></h1><div id="status.code.registration"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#status.code.registration">Status Code Registration</a></h2><p id="rfc.section.7.1.p.1">The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; has been updated with the registrations below:</p><div id="rfc.table.1"><div id="iana.status.code.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead><tbody><tr><td class="left">304</td><td class="left">Not Modified</td><td class="left"><a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section&nbsp;4.1</a> </td></tr><tr><td class="left">412</td><td class="left">Precondition Failed</td><td class="left"><a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section&nbsp;4.2</a> </td></tr></tbody></table></div></div><div id="header.field.registration"><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2><p id="rfc.section.7.2.p.1">HTTP header fields are registered within the "Message Headers" registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/">http://www.iana.org/assignments/message-headers/</a>&gt;.</p><p id="rfc.section.7.2.p.2">This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>):</p><div id="rfc.table.2"><div id="iana.header.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Protocol</th><th>Status</th><th>Reference</th></tr></thead><tbody><tr><td class="left">ETag</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.etag" id="rfc.xref.header.etag.2" title="ETag">Section&nbsp;2.3</a> </td></tr><tr><td class="left">If-Match</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section&nbsp;3.1</a> </td></tr><tr><td class="left">If-Modified-Since</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-modified-since" id="rfc.xref.header.if-modified-since.1" title="If-Modified-Since">Section&nbsp;3.3</a> </td></tr><tr><td class="left">If-None-Match</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;3.2</a> </td></tr><tr><td class="left">If-Unmodified-Since</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.2" title="If-Unmodified-Since">Section&nbsp;3.4</a> </td></tr><tr><td class="left">Last-Modified</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.last-modified" id="rfc.xref.header.last-modified.2" title="Last-Modified">Section&nbsp;2.2</a> </td></tr></tbody></table></div><p id="rfc.section.7.2.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p></div></div><div id="security.considerations"><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP conditional request mechanisms. More general security considerations are addressed in HTTP "Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> and "Semantics and Content" <a href="#RFC7231" id="rfc.xref.RFC7231.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.</p><p id="rfc.section.8.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.</p><p id="rfc.section.8.p.3">An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.</p></div><div id="acks"><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#acks">Acknowledgments</a></h1><p id="rfc.section.9.p.1">See <a href="rfc7230.html#acks" title="Acknowledgments">Section 10</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References</h2><table><tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC5234">[RFC5234]</b></td><td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>&#8221;, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC7230">[RFC7230]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>&#8221;, RFC&nbsp;7230, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7233">[RFC7233]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7233">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>&#8221;, RFC&nbsp;7233, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7234">[RFC7234]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Akamai">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7234">Hypertext Transfer Protocol (HTTP/1.1): Caching</a>&#8221;, RFC&nbsp;7234, June&nbsp;2014.</td></tr></table><h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References</h2><table><tr><td class="reference"><b id="BCP90">[BCP90]</b></td><td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>&#8221;, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC2616">[RFC2616]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2616, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC4918">[RFC4918]</b></td><td class="top"><a href="mailto:ldusseault@commerce.net" title="CommerceNet">Dusseault, L., Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc4918">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a>&#8221;, RFC&nbsp;4918, June&nbsp;2007.</td></tr></table><div id="changes.from.rfc.2616"><h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1><p id="rfc.section.A.p.1">The definition of validator weakness has been expanded and clarified. (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section&nbsp;2.1</a>)</p><p id="rfc.section.A.p.2">Weak entity-tags are now allowed in all requests except range requests. (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>)</p><p id="rfc.section.A.p.3">The <a href="#header.etag" class="smpl">ETag</a> header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)</p><p id="rfc.section.A.p.4">ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section&nbsp;2.3</a>)</p><p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section&nbsp;6</a>)</p></div><div id="imported.abnf"><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#imported.abnf">Imported ABNF</a></h1><p id="rfc.section.B.p.1">The following core rules are included by reference, as defined in <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></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), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).</p><p id="rfc.section.B.p.2">The rules below are defined in <a href="#RFC7230" id="rfc.xref.RFC7230.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>:</p><div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, see <a href="#RFC7230" id="rfc.xref.RFC7230.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    555555  <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;obs-text, see <a href="#RFC7230" id="rfc.xref.RFC7230.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#field.components" title="Field Value Components">Section 3.2.6</a>&gt;
    556556</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p><div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, see <a href="#RFC7231" id="rfc.xref.RFC7231.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>, <a href="rfc7231.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
     
    578578
    579579<a href="#header.etag" class="smpl">weak</a> = %x57.2F ; W/
    580 </pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul><li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.21"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.2</a>, <a href="#BCP90"><b>10.2</b></a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a>, <a href="#rfc.xref.header.etag.3">A</a>, <a href="#rfc.xref.header.etag.4">A</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>entity-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>2.3</b></a></li><li><tt>ETag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.3</b></a></li><li><tt>etagc</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>2.3</b></a></li><li><tt>If-Match</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.1</b></a></li><li><tt>If-Modified-Since</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>3.3</b></a></li><li><tt>If-None-Match</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>3.2</b></a></li><li><tt>If-Unmodified-Since</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.4</b></a></li><li><tt>Last-Modified</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2.2</b></a></li><li><tt>opaque-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.3</b></a></li><li><tt>weak</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>2.3</b></a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6</a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li><li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">7.2</a></li><li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">7.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li><li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6</a>, <a href="#rfc.xref.header.if-unmodified-since.2">7.2</a></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">7.2</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>metadata&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>2</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>10.2</b></a><ul><li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a></li></ul></li><li><em>RFC4918</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.1">2</a>, <a href="#rfc.xref.RFC4918.2">5</a>, <a href="#RFC4918"><b>10.2</b></a><ul><li><em>Section 10.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.2">5</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2.3.3</a>, <a href="#rfc.xref.RFC7230.5">8</a>, <a href="#rfc.xref.RFC7230.6">9</a>, <a href="#RFC7230"><b>10.1</b></a>, <a href="#rfc.xref.RFC7230.7">B</a>, <a href="#rfc.xref.RFC7230.8">B</a>, <a href="#rfc.xref.RFC7230.9">B</a>, <a href="#rfc.xref.RFC7230.10">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">C</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">B</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2.3.3</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">9</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">1</a>, <a href="#rfc.xref.RFC7231.2">1</a>, <a href="#rfc.xref.RFC7231.3">2.3.3</a>, <a href="#rfc.xref.RFC7231.4">2.3.3</a>, <a href="#rfc.xref.RFC7231.5">3.2</a>, <a href="#rfc.xref.RFC7231.6">8</a>, <a href="#RFC7231"><b>10.1</b></a>, <a href="#rfc.xref.RFC7231.7">B</a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.2">1</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">2.3.3</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.5">3.2</a></li><li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.4">2.3.3</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.7">B</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.5</a>, <a href="#rfc.xref.RFC7233.2">6</a>, <a href="#RFC7233"><b>10.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.5</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">1</a>, <a href="#rfc.xref.RFC7234.2">2.2.1</a>, <a href="#rfc.xref.RFC7234.3">2.3.1</a>, <a href="#rfc.xref.RFC7234.4">3.2</a>, <a href="#rfc.xref.RFC7234.5">3.3</a>, <a href="#rfc.xref.RFC7234.6">4.1</a>, <a href="#RFC7234"><b>10.1</b></a><ul><li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.4">3.2</a>, <a href="#rfc.xref.RFC7234.5">3.3</a></li><li><em>Section 4.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.6">4.1</a></li></ul></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>1</b></a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1"><b>2</b></a><ul><li>strong&nbsp;&nbsp;<a href="#rfc.iref.v.3"><b>2.1</b></a></li><li>weak&nbsp;&nbsp;<a href="#rfc.iref.v.2"><b>2.1</b></a></li></ul></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
     580</pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul><li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.3.1"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.4.1"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.2</a>, <a href="#BCP90"><b>10.2</b></a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a>, <a href="#rfc.xref.header.etag.3">A</a>, <a href="#rfc.xref.header.etag.4">A</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>entity-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>2.3</b></a></li><li><tt>ETag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.3</b></a></li><li><tt>etagc</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>2.3</b></a></li><li><tt>If-Match</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>3.1</b></a></li><li><tt>If-Modified-Since</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>3.3</b></a></li><li><tt>If-None-Match</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>3.2</b></a></li><li><tt>If-Unmodified-Since</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>3.4</b></a></li><li><tt>Last-Modified</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2.2</b></a></li><li><tt>opaque-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.3</b></a></li><li><tt>weak</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>2.3</b></a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6</a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li><li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">7.2</a></li><li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">7.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li><li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6</a>, <a href="#rfc.xref.header.if-unmodified-since.2">7.2</a></li></ul></li><li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul><li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">7.2</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>metadata&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>2</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>10.2</b></a><ul><li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a></li></ul></li><li><em>RFC4918</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.1">2</a>, <a href="#rfc.xref.RFC4918.2">5</a>, <a href="#RFC4918"><b>10.2</b></a><ul><li><em>Section 10.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.2">5</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2.3.3</a>, <a href="#rfc.xref.RFC7230.5">8</a>, <a href="#rfc.xref.RFC7230.6">9</a>, <a href="#RFC7230"><b>10.1</b></a>, <a href="#rfc.xref.RFC7230.7">B</a>, <a href="#rfc.xref.RFC7230.8">B</a>, <a href="#rfc.xref.RFC7230.9">B</a>, <a href="#rfc.xref.RFC7230.10">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">C</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">B</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2.3.3</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">9</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">1</a>, <a href="#rfc.xref.RFC7231.2">1</a>, <a href="#rfc.xref.RFC7231.3">2.3.3</a>, <a href="#rfc.xref.RFC7231.4">2.3.3</a>, <a href="#rfc.xref.RFC7231.5">3.2</a>, <a href="#rfc.xref.RFC7231.6">8</a>, <a href="#RFC7231"><b>10.1</b></a>, <a href="#rfc.xref.RFC7231.7">B</a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.2">1</a></li><li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">2.3.3</a></li><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.5">3.2</a></li><li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.4">2.3.3</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.7">B</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.5</a>, <a href="#rfc.xref.RFC7233.2">6</a>, <a href="#RFC7233"><b>10.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.5</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">1</a>, <a href="#rfc.xref.RFC7234.2">2.2.1</a>, <a href="#rfc.xref.RFC7234.3">2.3.1</a>, <a href="#rfc.xref.RFC7234.4">3.2</a>, <a href="#rfc.xref.RFC7234.5">3.3</a>, <a href="#rfc.xref.RFC7234.6">4.1</a>, <a href="#RFC7234"><b>10.1</b></a><ul><li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.4">3.2</a>, <a href="#rfc.xref.RFC7234.5">3.3</a></li><li><em>Section 4.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.6">4.1</a></li></ul></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>1</b></a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1"><b>2</b></a><ul><li>strong&nbsp;&nbsp;<a href="#rfc.iref.v.3"><b>2.1</b></a></li><li>weak&nbsp;&nbsp;<a href="#rfc.iref.v.2"><b>2.1</b></a></li></ul></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
    581581      (editor)
    582582    <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p><p><b>Julian F. Reschke</b>
  • specs/rfc7233.html

    r2725 r2726  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Range Units" href="#rfc.section.2"><link rel="Chapter" title="3 Range Requests" href="#rfc.section.3"><link rel="Chapter" title="4 Responses to a Range Request" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Internet Media Type multipart/byteranges" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7232.html" rel="prev"><link href="rfc7234.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7233.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7233"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7233"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Range Requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Lafon, Y."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7233"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."></head><body onload="getMeta(7233,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7233</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">Y. Lafon, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">W3C</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7233">http://www.rfc-editor.org/info/rfc7233</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#range.units">Range Units</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#byte.ranges">Byte Ranges</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.units.other">Other Range Units</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-ranges">Accept-Ranges</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#range.requests">Range Requests</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.range">Range</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#range.response">Responses to a Range Request</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.206">206 Partial Content</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-range">Content-Range</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry">Range Unit Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges.reg">Internet Media Type multipart/byteranges</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Denial-of-Service Attacks Using Range</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.</p><p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.</p><p id="rfc.section.1.p.3">Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="range.units"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#range.units">Range Units</a></h1><p id="rfc.section.2.p.1">A representation can be partitioned into subranges according to various structural units, depending on the structure inherent in the representation's media type. This "<dfn>range unit</dfn>" is used in the <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> (<a href="#header.accept-ranges" id="rfc.xref.header.accept-ranges.1" title="Accept-Ranges">Section&nbsp;2.3</a>) response header field to advertise support for range requests, the <a href="#header.range" class="smpl">Range</a> (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;3.1</a>) request header field to delineate the parts of a representation that are requested, and the <a href="#header.content-range" class="smpl">Content-Range</a> (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;4.2</a>) payload header field to describe which part of a representation is being transferred.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#range.units" class="smpl">range-unit</a>       = <a href="#byte.ranges" class="smpl">bytes-unit</a> / <a href="#range.units.other" class="smpl">other-range-unit</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Range Units" href="#rfc.section.2"><link rel="Chapter" title="3 Range Requests" href="#rfc.section.3"><link rel="Chapter" title="4 Responses to a Range Request" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Internet Media Type multipart/byteranges" href="#rfc.section.A"><link rel="Appendix" title="B Changes from RFC 2616" href="#rfc.section.B"><link rel="Appendix" title="C Imported ABNF" href="#rfc.section.C"><link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"><link href="rfc7232.html" rel="prev"><link href="rfc7234.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7233.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7233"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7233"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Range Requests"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Lafon, Y."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7233"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."></head><body onload="getMeta(7233,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7233</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">Y. Lafon, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">W3C</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7233">http://www.rfc-editor.org/info/rfc7233</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#range.units">Range Units</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#byte.ranges">Byte Ranges</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.units.other">Other Range Units</a></li><li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-ranges">Accept-Ranges</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#range.requests">Range Requests</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.range">Range</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.if-range">If-Range</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#range.response">Responses to a Range Request</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.206">206 Partial Content</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-range">Content-Range</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry">Range Unit Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#range.unit.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.http">Internet Media Type Registration</a><ul><li><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges.reg">Internet Media Type multipart/byteranges</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#overlapping.ranges">Denial-of-Service Attacks Using Range</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.</p><p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests are an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.</p><p id="rfc.section.1.p.3">Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;C</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="range.units"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#range.units">Range Units</a></h1><p id="rfc.section.2.p.1">A representation can be partitioned into subranges according to various structural units, depending on the structure inherent in the representation's media type. This "<dfn>range unit</dfn>" is used in the <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> (<a href="#header.accept-ranges" id="rfc.xref.header.accept-ranges.1" title="Accept-Ranges">Section&nbsp;2.3</a>) response header field to advertise support for range requests, the <a href="#header.range" class="smpl">Range</a> (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;3.1</a>) request header field to delineate the parts of a representation that are requested, and the <a href="#header.content-range" class="smpl">Content-Range</a> (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;4.2</a>) payload header field to describe which part of a representation is being transferred.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#range.units" class="smpl">range-unit</a>       = <a href="#byte.ranges" class="smpl">bytes-unit</a> / <a href="#range.units.other" class="smpl">other-range-unit</a>
    505505</pre><div id="byte.ranges"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#byte.ranges">Byte Ranges</a></h2><p id="rfc.section.2.1.p.1">Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for any representation transferable over HTTP (<a href="rfc7231.html#representations" title="Representations">Section 3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). The "bytes" range unit is defined for expressing subranges of the data's octet sequence.</p><div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#byte.ranges" class="smpl">bytes-unit</a>       = "bytes"
    506506</pre><div id="rule.ranges-specifier"><p id="rfc.section.2.1.p.3">        A byte-range request can specify a single range of bytes or a set of ranges within a single representation.</p></div><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> = <a href="#byte.ranges" class="smpl">bytes-unit</a> "=" <a href="#rule.ranges-specifier" class="smpl">byte-range-set</a>
     
    527527  <a href="#header.range" class="smpl">other-range-set</a> = 1*<a href="#imported.abnf" class="smpl">VCHAR</a>
    528528</pre><p id="rfc.section.3.1.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations. A server <em class="bcp14">MUST</em> ignore a Range header field received with a request method other than GET.</p><p id="rfc.section.3.1.p.4">An origin server <em class="bcp14">MUST</em> ignore a Range header field that contains a range unit it does not understand. A proxy <em class="bcp14">MAY</em> discard a Range header field that contains a range unit it does not understand.</p><p id="rfc.section.3.1.p.5">A server that supports range requests <em class="bcp14">MAY</em> ignore or reject a <a href="#header.range" class="smpl">Range</a> header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since both are indications of either a broken client or a deliberate denial-of-service attack (<a href="#overlapping.ranges" title="Denial-of-Service Attacks Using Range">Section&nbsp;6.1</a>). A client <em class="bcp14">SHOULD NOT</em> request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data.</p><p id="rfc.section.3.1.p.6">A client that is requesting multiple ranges <em class="bcp14">SHOULD</em> list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier. For example, a user agent processing a large representation with an internal catalog of parts might need to request later parts first, particularly if the representation consists of pages stored in reverse order and the user agent wishes to transfer one page at a time.</p><p id="rfc.section.3.1.p.7">The Range header field is evaluated after evaluating the precondition header fields defined in <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>, and only if the result in absence of the Range header field would be a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response. In other words, Range is ignored when a conditional GET would result in a <a href="rfc7232.html#status.304" class="smpl">304 (Not Modified)</a> response.</p><p id="rfc.section.3.1.p.8">The If-Range header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;3.2</a>) can be used as a precondition to applying the Range header field.</p><p id="rfc.section.3.1.p.9">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are valid and satisfiable (as defined in <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;2.1</a>), the server <em class="bcp14">SHOULD</em> send a <a href="#status.206" class="smpl">206 (Partial Content)</a> response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested, as defined in <a href="#range.response" title="Responses to a Range Request">Section&nbsp;4</a>.</p><p id="rfc.section.3.1.p.10">If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server <em class="bcp14">SHOULD</em> send a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> response.</p></div><div id="header.if-range"><div id="rfc.iref.i.1"></div><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#header.if-range">If-Range</a></h2><p id="rfc.section.3.2.p.1">If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the <a href="#header.range" class="smpl">Range</a> header field with a conditional GET (using either or both of <a href="rfc7232.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="rfc7232.html#header.if-match" class="smpl">If-Match</a>.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation.</p><p id="rfc.section.3.2.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is as follows: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.</p><div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.17"></span>  <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#imported.abnf" class="smpl">entity-tag</a> / <a href="#imported.abnf" class="smpl">HTTP-date</a>
    529 </pre><p id="rfc.section.3.2.p.4">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. A server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. An origin server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request for a target resource that does not support Range requests.</p><p id="rfc.section.3.2.p.5">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field containing an entity-tag that is marked as weak. A client <em class="bcp14">MUST NOT</em> generate an If-Range header field containing an <a href="#imported.abnf" class="smpl">HTTP-date</a> unless the client has no entity-tag for the corresponding representation and the date is a strong validator in the sense defined by <a href="rfc7232.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>.</p><p id="rfc.section.3.2.p.6">A server that evaluates an If-Range precondition <em class="bcp14">MUST</em> use the strong comparison function when comparing entity-tags (<a href="rfc7232.html#entity.tag.comparison" title="Comparison">Section 2.3.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>) and <em class="bcp14">MUST</em> evaluate the condition as false if an <a href="#imported.abnf" class="smpl">HTTP-date</a> validator is provided that is not a strong validator in the sense defined by <a href="rfc7232.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>. A valid <a href="#imported.abnf" class="smpl">entity-tag</a> can be distinguished from a valid <a href="#imported.abnf" class="smpl">HTTP-date</a> by examining the first two characters for a DQUOTE.</p><p id="rfc.section.3.2.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server <em class="bcp14">SHOULD</em> process the <a href="#header.range" class="smpl">Range</a> header field as requested. If the validator does not match, the server <em class="bcp14">MUST</em> ignore the <a href="#header.range" class="smpl">Range</a> header field. Note that this comparison by exact match, including when the validator is an <a href="#imported.abnf" class="smpl">HTTP-date</a>, differs from the "earlier than or equal to" comparison used when evaluating an <a href="rfc7232.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> conditional.</p></div></div><div id="range.response"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#range.response">Responses to a Range Request</a></h1><div id="status.206"><div id="rfc.iref.20"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#status.206">206 Partial Content</a></h2><p id="rfc.section.4.1.p.1">The <dfn>206 (Partial Content)</dfn> status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;3.1</a>).</p><p id="rfc.section.4.1.p.2">If a single part is being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example:</p><div id="rfc.figure.u.17"></div><pre class="text">HTTP/1.1 206 Partial Content
     529</pre><p id="rfc.section.3.2.p.4">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. A server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request that does not contain a <a href="#header.range" class="smpl">Range</a> header field. An origin server <em class="bcp14">MUST</em> ignore an If-Range header field received in a request for a target resource that does not support Range requests.</p><p id="rfc.section.3.2.p.5">A client <em class="bcp14">MUST NOT</em> generate an If-Range header field containing an entity-tag that is marked as weak. A client <em class="bcp14">MUST NOT</em> generate an If-Range header field containing an <a href="#imported.abnf" class="smpl">HTTP-date</a> unless the client has no entity-tag for the corresponding representation and the date is a strong validator in the sense defined by <a href="rfc7232.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>.</p><p id="rfc.section.3.2.p.6">A server that evaluates an If-Range precondition <em class="bcp14">MUST</em> use the strong comparison function when comparing entity-tags (<a href="rfc7232.html#entity.tag.comparison" title="Comparison">Section 2.3.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>) and <em class="bcp14">MUST</em> evaluate the condition as false if an <a href="#imported.abnf" class="smpl">HTTP-date</a> validator is provided that is not a strong validator in the sense defined by <a href="rfc7232.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>. A valid <a href="#imported.abnf" class="smpl">entity-tag</a> can be distinguished from a valid <a href="#imported.abnf" class="smpl">HTTP-date</a> by examining the first two characters for a DQUOTE.</p><p id="rfc.section.3.2.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server <em class="bcp14">SHOULD</em> process the <a href="#header.range" class="smpl">Range</a> header field as requested. If the validator does not match, the server <em class="bcp14">MUST</em> ignore the <a href="#header.range" class="smpl">Range</a> header field. Note that this comparison by exact match, including when the validator is an <a href="#imported.abnf" class="smpl">HTTP-date</a>, differs from the "earlier than or equal to" comparison used when evaluating an <a href="rfc7232.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> conditional.</p></div></div><div id="range.response"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#range.response">Responses to a Range Request</a></h1><div id="status.206"><div id="rfc.iref.2.1"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#status.206">206 Partial Content</a></h2><p id="rfc.section.4.1.p.1">The <dfn>206 (Partial Content)</dfn> status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section&nbsp;3.1</a>).</p><p id="rfc.section.4.1.p.2">If a single part is being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example:</p><div id="rfc.figure.u.17"></div><pre class="text">HTTP/1.1 206 Partial Content
    530530Date: Wed, 15 Nov 1995 06:25:24 GMT
    531531Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
     
    573573</pre> </li><li>All except for the first 500 bytes: <span id="rfc.figure.u.25"></span><pre class="text">  Content-Range: bytes 500-1233/1234
    574574</pre> </li><li>The last 500 bytes: <span id="rfc.figure.u.26"></span><pre class="text">  Content-Range: bytes 734-1233/1234
    575 </pre> </li></ul></div><div id="combining.byte.ranges"><h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></h2><p id="rfc.section.4.3.p.1">A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. These ranges can only be safely combined if they all have in common the same strong validator (<a href="rfc7232.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>).</p><p id="rfc.section.4.3.p.2">A client that has received multiple partial responses to GET requests on a target resource <em class="bcp14">MAY</em> combine those responses into a larger continuous range if they share the same strong validator.</p><p id="rfc.section.4.3.p.3">If the most recent response is an incomplete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that response are used for any combined response and replace those of the matching stored responses.</p><p id="rfc.section.4.3.p.4">If the most recent response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header fields for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from <a href="#header.content-range" class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response.</p><p id="rfc.section.4.3.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected responses. If the union consists of the entire range of the representation, then the client <em class="bcp14">MUST</em> process the combined response as if it were a complete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response, including a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the client <em class="bcp14">MUST</em> process the set of continuous ranges as one of the following: an incomplete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response if the combined response is a prefix of the representation, a single <a href="#status.206" class="smpl">206 (Partial Content)</a> response containing a multipart/byteranges body, or multiple <a href="#status.206" class="smpl">206 (Partial Content)</a> responses, each with one continuous range that is indicated by a <a href="#header.content-range" class="smpl">Content-Range</a> header field.</p></div><div id="status.416"><div id="rfc.iref.29"></div><h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></h2><p id="rfc.section.4.4.p.1">The <dfn>416 (Range Not Satisfiable)</dfn> status code indicates that none of the ranges in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;3.1</a>) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges.</p><p id="rfc.section.4.4.p.2">For byte ranges, failing to overlap the current extent means that the <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> of all of the <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> values were greater than the current length of the selected representation. When this status code is generated in response to a byte-range request, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the selected representation (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;4.2</a>).</p><div id="rfc.figure.u.27"></div><p>For example:</p><pre class="text">HTTP/1.1 416 Range Not Satisfiable
     575</pre> </li></ul></div><div id="combining.byte.ranges"><h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#combining.byte.ranges">Combining Ranges</a></h2><p id="rfc.section.4.3.p.1">A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. These ranges can only be safely combined if they all have in common the same strong validator (<a href="rfc7232.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#RFC7232" id="rfc.xref.RFC7232.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a>).</p><p id="rfc.section.4.3.p.2">A client that has received multiple partial responses to GET requests on a target resource <em class="bcp14">MAY</em> combine those responses into a larger continuous range if they share the same strong validator.</p><p id="rfc.section.4.3.p.3">If the most recent response is an incomplete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that response are used for any combined response and replace those of the matching stored responses.</p><p id="rfc.section.4.3.p.4">If the most recent response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header fields for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from <a href="#header.content-range" class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response.</p><p id="rfc.section.4.3.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected responses. If the union consists of the entire range of the representation, then the client <em class="bcp14">MUST</em> process the combined response as if it were a complete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response, including a <a href="rfc7230.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the client <em class="bcp14">MUST</em> process the set of continuous ranges as one of the following: an incomplete <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response if the combined response is a prefix of the representation, a single <a href="#status.206" class="smpl">206 (Partial Content)</a> response containing a multipart/byteranges body, or multiple <a href="#status.206" class="smpl">206 (Partial Content)</a> responses, each with one continuous range that is indicated by a <a href="#header.content-range" class="smpl">Content-Range</a> header field.</p></div><div id="status.416"><div id="rfc.iref.4.1"></div><h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#status.416">416 Range Not Satisfiable</a></h2><p id="rfc.section.4.4.p.1">The <dfn>416 (Range Not Satisfiable)</dfn> status code indicates that none of the ranges in the request's <a href="#header.range" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;3.1</a>) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges.</p><p id="rfc.section.4.4.p.2">For byte ranges, failing to overlap the current extent means that the <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a> of all of the <a href="#rule.ranges-specifier" class="smpl">byte-range-spec</a> values were greater than the current length of the selected representation. When this status code is generated in response to a byte-range request, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the selected representation (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;4.2</a>).</p><div id="rfc.figure.u.27"></div><p>For example:</p><pre class="text">HTTP/1.1 416 Range Not Satisfiable
    576576Date: Fri, 20 Jan 2012 15:41:54 GMT
    577577Content-Range: bytes */47022
     
    645645
    646646<a href="#header.content-range" class="smpl">unsatisfied-range</a> = "*/" complete-length
    647 </pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.R">R</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>206 Partial Content (status code)&nbsp;&nbsp;<a href="#rfc.iref.20"><b>4.1</b></a>, <a href="#rfc.xref.status.206.1">5.2</a>, <a href="#rfc.xref.status.206.2">B</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>416 Range Not Satisfiable (status code)&nbsp;&nbsp;<a href="#rfc.iref.29"><b>4.4</b></a>, <a href="#rfc.xref.status.416.1">5.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Accept-Ranges header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-ranges.1">2</a>, <a href="#rfc.iref.a.1"><b>2.3</b></a>, <a href="#rfc.xref.header.accept-ranges.2">5.1.2</a>, <a href="#rfc.xref.header.accept-ranges.3">5.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP13</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP13.1">5.4</a>, <a href="#BCP13"><b>8.2</b></a></li><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">5.3</a>, <a href="#BCP90"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Content-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-range.1">2</a>, <a href="#rfc.iref.c.1"><b>4.2</b></a>, <a href="#rfc.xref.header.content-range.2">4.4</a>, <a href="#rfc.xref.header.content-range.3">5.3</a>, <a href="#rfc.xref.header.content-range.4">B</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Accept-Ranges</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.3</b></a></li><li><tt>acceptable-ranges</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.3</b></a></li><li><tt>byte-content-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>4.2</b></a></li><li><tt>byte-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>4.2</b></a></li><li><tt>byte-range-resp</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>4.2</b></a></li><li><tt>byte-range-set</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>2.1</b></a></li><li><tt>byte-range-spec</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>2.1</b></a></li><li><tt>byte-ranges-specifier</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>2.1</b></a></li><li><tt>bytes-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2">2</a>, <a href="#rfc.iref.g.4"><b>2.1</b></a></li><li><tt>complete-length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>4.2</b></a></li><li><tt>Content-Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>4.2</b></a></li><li><tt>first-byte-pos</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>2.1</b></a></li><li><tt>If-Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>3.2</b></a></li><li><tt>last-byte-pos</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>2.1</b></a></li><li><tt>other-content-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>4.2</b></a></li><li><tt>other-range-resp</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>4.2</b></a></li><li><tt>other-range-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3">2</a>, <a href="#rfc.iref.g.13"><b>2.2</b></a></li><li><tt>Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>3.1</b></a></li><li><tt>range-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2</b></a></li><li><tt>ranges-specifier</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.1</b></a></li><li><tt>suffix-byte-range-spec</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>2.1</b></a></li><li><tt>suffix-length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>2.1</b></a></li><li><tt>unsatisfied-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>4.2</b></a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.if-range.1">3.1</a>, <a href="#rfc.iref.i.1"><b>3.2</b></a>, <a href="#rfc.xref.header.if-range.2">5.3</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Media Type&nbsp;&nbsp;<ul><li>multipart/byteranges&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>5.4.1</b></a>, <a href="#rfc.iref.m.3"><b>A</b></a></li><li>multipart/x-byteranges&nbsp;&nbsp;<a href="#rfc.iref.m.6">A</a></li></ul></li><li>multipart/byteranges Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>5.4.1</b></a>, <a href="#rfc.iref.m.4"><b>A</b></a></li><li>multipart/x-byteranges Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.5">A</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.range.1">2</a>, <a href="#rfc.iref.r.1"><b>3.1</b></a>, <a href="#rfc.xref.header.range.2">4.1</a>, <a href="#rfc.xref.header.range.3">4.4</a>, <a href="#rfc.xref.header.range.4">5.3</a>, <a href="#rfc.xref.header.range.5">B</a></li><li><em>RFC2046</em>&nbsp;&nbsp;<a href="#RFC2046"><b>8.1</b></a>, <a href="#rfc.xref.RFC2046.1">A</a>, <a href="#rfc.xref.RFC2046.2">A</a><ul><li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">A</a></li></ul></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#RFC2616"><b>8.2</b></a></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>8.1</b></a>, <a href="#rfc.xref.RFC5234.2">C</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">C</a></li></ul></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a>, <a href="#rfc.xref.RFC7230.2">1.2</a>, <a href="#rfc.xref.RFC7230.3">6</a>, <a href="#rfc.xref.RFC7230.4">7</a>, <a href="#RFC7230"><b>8.1</b></a>, <a href="#rfc.xref.RFC7230.5">C</a>, <a href="#rfc.xref.RFC7230.6">C</a>, <a href="#rfc.xref.RFC7230.7">C</a>, <a href="#rfc.xref.RFC7230.8">D</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">D</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">C</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.7">C</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">7</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a>, <a href="#rfc.xref.RFC7231.2">6</a>, <a href="#RFC7231"><b>8.1</b></a>, <a href="#rfc.xref.RFC7231.3">C</a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">C</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">3.1</a>, <a href="#rfc.xref.RFC7232.2">3.2</a>, <a href="#rfc.xref.RFC7232.3">3.2</a>, <a href="#rfc.xref.RFC7232.4">3.2</a>, <a href="#rfc.xref.RFC7232.5">4.3</a>, <a href="#RFC7232"><b>8.1</b></a>, <a href="#rfc.xref.RFC7232.6">C</a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">4.3</a></li><li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.2">3.2</a>, <a href="#rfc.xref.RFC7232.4">3.2</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">C</a></li><li><em>Section 2.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.3">3.2</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.1</a>, <a href="#RFC7234"><b>8.1</b></a><ul><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.1</a></li></ul></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
     647</pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.R">R</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>206 Partial Content (status code)&nbsp;&nbsp;<a href="#rfc.iref.2.1"><b>4.1</b></a>, <a href="#rfc.xref.status.206.1">5.2</a>, <a href="#rfc.xref.status.206.2">B</a></li></ul></li><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>416 Range Not Satisfiable (status code)&nbsp;&nbsp;<a href="#rfc.iref.4.1"><b>4.4</b></a>, <a href="#rfc.xref.status.416.1">5.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Accept-Ranges header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-ranges.1">2</a>, <a href="#rfc.iref.a.1"><b>2.3</b></a>, <a href="#rfc.xref.header.accept-ranges.2">5.1.2</a>, <a href="#rfc.xref.header.accept-ranges.3">5.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP13</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP13.1">5.4</a>, <a href="#BCP13"><b>8.2</b></a></li><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">5.3</a>, <a href="#BCP90"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Content-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-range.1">2</a>, <a href="#rfc.iref.c.1"><b>4.2</b></a>, <a href="#rfc.xref.header.content-range.2">4.4</a>, <a href="#rfc.xref.header.content-range.3">5.3</a>, <a href="#rfc.xref.header.content-range.4">B</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Accept-Ranges</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>2.3</b></a></li><li><tt>acceptable-ranges</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.15"><b>2.3</b></a></li><li><tt>byte-content-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>4.2</b></a></li><li><tt>byte-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>4.2</b></a></li><li><tt>byte-range-resp</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>4.2</b></a></li><li><tt>byte-range-set</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>2.1</b></a></li><li><tt>byte-range-spec</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>2.1</b></a></li><li><tt>byte-ranges-specifier</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>2.1</b></a></li><li><tt>bytes-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2">2</a>, <a href="#rfc.iref.g.4"><b>2.1</b></a></li><li><tt>complete-length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>4.2</b></a></li><li><tt>Content-Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>4.2</b></a></li><li><tt>first-byte-pos</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>2.1</b></a></li><li><tt>If-Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>3.2</b></a></li><li><tt>last-byte-pos</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>2.1</b></a></li><li><tt>other-content-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>4.2</b></a></li><li><tt>other-range-resp</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>4.2</b></a></li><li><tt>other-range-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3">2</a>, <a href="#rfc.iref.g.13"><b>2.2</b></a></li><li><tt>Range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>3.1</b></a></li><li><tt>range-unit</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2</b></a></li><li><tt>ranges-specifier</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.1</b></a></li><li><tt>suffix-byte-range-spec</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>2.1</b></a></li><li><tt>suffix-length</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>2.1</b></a></li><li><tt>unsatisfied-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.22"><b>4.2</b></a></li></ul></li></ul></li><li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul><li>If-Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.if-range.1">3.1</a>, <a href="#rfc.iref.i.1"><b>3.2</b></a>, <a href="#rfc.xref.header.if-range.2">5.3</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>Media Type&nbsp;&nbsp;<ul><li>multipart/byteranges&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>5.4.1</b></a>, <a href="#rfc.iref.m.3"><b>A</b></a></li><li>multipart/x-byteranges&nbsp;&nbsp;<a href="#rfc.iref.m.6">A</a></li></ul></li><li>multipart/byteranges Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>5.4.1</b></a>, <a href="#rfc.iref.m.4"><b>A</b></a></li><li>multipart/x-byteranges Media Type&nbsp;&nbsp;<a href="#rfc.iref.m.5">A</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Range header field&nbsp;&nbsp;<a href="#rfc.xref.header.range.1">2</a>, <a href="#rfc.iref.r.1"><b>3.1</b></a>, <a href="#rfc.xref.header.range.2">4.1</a>, <a href="#rfc.xref.header.range.3">4.4</a>, <a href="#rfc.xref.header.range.4">5.3</a>, <a href="#rfc.xref.header.range.5">B</a></li><li><em>RFC2046</em>&nbsp;&nbsp;<a href="#RFC2046"><b>8.1</b></a>, <a href="#rfc.xref.RFC2046.1">A</a>, <a href="#rfc.xref.RFC2046.2">A</a><ul><li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">A</a></li></ul></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#RFC2616"><b>8.2</b></a></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>8.1</b></a>, <a href="#rfc.xref.RFC5234.2">C</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">C</a></li></ul></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a>, <a href="#rfc.xref.RFC7230.2">1.2</a>, <a href="#rfc.xref.RFC7230.3">6</a>, <a href="#rfc.xref.RFC7230.4">7</a>, <a href="#RFC7230"><b>8.1</b></a>, <a href="#rfc.xref.RFC7230.5">C</a>, <a href="#rfc.xref.RFC7230.6">C</a>, <a href="#rfc.xref.RFC7230.7">C</a>, <a href="#rfc.xref.RFC7230.8">D</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">D</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">C</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.7">C</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">7</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a>, <a href="#rfc.xref.RFC7231.2">6</a>, <a href="#RFC7231"><b>8.1</b></a>, <a href="#rfc.xref.RFC7231.3">C</a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">C</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">3.1</a>, <a href="#rfc.xref.RFC7232.2">3.2</a>, <a href="#rfc.xref.RFC7232.3">3.2</a>, <a href="#rfc.xref.RFC7232.4">3.2</a>, <a href="#rfc.xref.RFC7232.5">4.3</a>, <a href="#RFC7232"><b>8.1</b></a>, <a href="#rfc.xref.RFC7232.6">C</a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">4.3</a></li><li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.2">3.2</a>, <a href="#rfc.xref.RFC7232.4">3.2</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">C</a></li><li><em>Section 2.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.3">3.2</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.1</a>, <a href="#RFC7234"><b>8.1</b></a><ul><li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.1</a></li></ul></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
    648648      (editor)
    649649    <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p><p><b>Yves Lafon</b>
  • specs/rfc7234.html

    r2725 r2726  
    606606    }
    607607}
    608 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Overview of Cache Operation" href="#rfc.section.2"><link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3"><link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4"><link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"><link rel="Chapter" title="6 History Lists" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7233.html" rel="prev"><link href="rfc7235.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7234.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7234"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7234"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Caching"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Nottingham, M."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7234"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."></head><body onload="getMeta(7234,&#34;rfc.meta&#34;);initFeedback();"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7234</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">M. Nottingham, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">Akamai</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Caching</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7234">http://www.rfc-editor.org/info/rfc7234</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#caching">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul><li><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li></ul></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li><li><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#validation.sent">Sending a Validation Request</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.received">Handling a Received Validation Request</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.response">Handling a Validation Response</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Freshening Responses via HEAD</a></li></ul></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation">Invalidation</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul><li><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li></ul></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></li><li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></li><li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></li><li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></li><li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul><li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.</p><div id="rfc.iref.c.1"></div><p id="rfc.section.1.p.2">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.</p><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.</p></div><p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="delta-seconds"><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a href="#delta-seconds">Delta Seconds</a></h3><p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
     608</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Overview of Cache Operation" href="#rfc.section.2"><link rel="Chapter" title="3 Storing Responses in Caches" href="#rfc.section.3"><link rel="Chapter" title="4 Constructing Responses from Caches" href="#rfc.section.4"><link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"><link rel="Chapter" title="6 History Lists" href="#rfc.section.6"><link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7233.html" rel="prev"><link href="rfc7235.html" rel="next"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7234.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7234"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7234"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP Caching"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Nottingham, M."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7234"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."></head><body onload="getMeta(7234,&#34;rfc.meta&#34;);initFeedback();"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7234</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">M. Nottingham, Editor</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">Akamai</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left"></td><td class="right">greenbytes</td></tr><tr><td class="left"></td><td class="right">June 2014</td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Caching</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7234">http://www.rfc-editor.org/info/rfc7234</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#caching">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul><li><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li></ul></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></li><li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul><li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li><li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li><li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li><li><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li></ul></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul><li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#validation.sent">Sending a Validation Request</a></li><li><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.received">Handling a Received Validation Request</a></li><li><a href="#rfc.section.4.3.3">4.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.response">Handling a Validation Response</a></li><li><a href="#rfc.section.4.3.4">4.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li><li><a href="#rfc.section.4.3.5">4.3.5</a>&nbsp;&nbsp;&nbsp;<a href="#head.effects">Freshening Responses via HEAD</a></li></ul></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#invalidation">Invalidation</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.age">Age</a></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.cache-control">Cache-Control</a><ul><li><a href="#rfc.section.5.2.1">5.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache-request-directive">Request Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache-response-directive">Response Cache-Control Directives</a></li><li><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></li></ul></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.expires">Expires</a></li><li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.pragma">Pragma</a></li><li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a><ul><li><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></li><li><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></li><li><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;&nbsp;&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></li><li><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;&nbsp;&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></li><li><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;&nbsp;&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></li><li><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;&nbsp;&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></li><li><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;&nbsp;&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></li></ul></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#history.lists">History Lists</a></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a><ul><li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></li><li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#cache.directive.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry">Warn Code Registry</a><ul><li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></li><li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#warn.code.registration">Registrations</a></li></ul></li><li><a href="#rfc.section.7.3">7.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li><li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="caching"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#caching">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. This document defines aspects of HTTP/1.1 related to caching and reusing response messages.</p><div id="rfc.iref.c.1"></div><p id="rfc.section.1.p.2">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.</p><div id="rfc.iref.s.1"></div><div id="rfc.iref.p.1"></div><div id="shared.and.private.caches"><p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.</p></div><p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p><div id="delta-seconds"><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a href="#delta-seconds">Delta Seconds</a></h3><p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    609609</pre><p id="rfc.section.1.2.1.p.3">A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache <em class="bcp14">MUST</em> consider the value to be either 2147483648 (2<sup>31</sup>) or the greatest positive integer it can conveniently represent.</p><div class="note" id="rfc.section.1.2.1.p.4"><p><b>Note:</b> The value 2147483648 is here for historical reasons, effectively represents infinity (over 68 years), and does not need to be stored in binary form; an implementation could produce it as a canned string if any overflow occurs, even if the calculations are performed with an arithmetic type incapable of directly representing that number. What matters here is that an overflow be detected and not treated as a negative value in later calculations.</p> </div></div></div></div><div id="caching.overview"><div id="rfc.iref.c.2"></div><div id="rfc.iref.c.3"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></h1><p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.</p><p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common form of cache entry is a successful result of a retrieval request: i.e., a <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a> response to a GET request, which contains a representation of the resource identified by the request target (<a href="rfc7231.html#GET" title="GET">Section 4.3.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>). However, it is also possible to cache permanent redirects, negative results (e.g., <a href="rfc7231.html#status.404" class="smpl">404 (Not Found)</a>), incomplete results (e.g., <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to methods other than GET if the method's definition allows such caching and defines something suitable for use as a cache key.</p><div id="rfc.iref.c.4"></div><p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.</p><p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>).</p></div><div id="response.cacheability"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#response.cacheability">Storing Responses in Caches</a></h1><p id="rfc.section.3.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: </p><ul><li>The request method is understood by the cache and defined as being cacheable, and</li><li>the response status code is understood by the cache, and</li><li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;5.2</a>) does not appear in request or response header fields, and</li><li>the "private" response directive (see <a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a>) does not appear in the response, if the cache is shared, and</li><li>the <a href="rfc7235.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="rfc7235.html#header.authorization" title="Authorization">Section 4.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>), and</li><li>the response either: <ul><li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;5.3</a>), or</li><li>contains a max-age response directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>), or</li><li>contains a s-maxage response directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a>) and the cache is shared, or</li><li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>) that allows it to be cached, or</li><li>has a status code that is defined as cacheable by default (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>), or</li><li>contains a public response directive (see <a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a>).</li></ul> </li></ul><p id="rfc.section.3.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p><p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all specified caching-related behavior.</p><p id="rfc.section.3.p.4">Note that, in normal operation, some caches will not store a response that has neither a cache validator nor an explicit expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.</p><div id="incomplete.responses"><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#incomplete.responses">Storing Incomplete Responses</a></h2><p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="rfc7231.html#status.200" class="smpl">200 (OK)</a>, and the entire response header section has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="rfc7231.html#status.200" class="smpl">200
    610610   (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial-content responses if it does not support the <a href="rfc7233.html#header.range" class="smpl">Range</a> and <a href="rfc7233.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.</p><p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;3.3</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="rfc7233.html#status.206" class="smpl">206 (Partial Content)</a> status code.</p></div><div id="caching.authenticated.responses"><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#caching.authenticated.responses">Storing Responses to Authenticated Requests</a></h2><p id="rfc.section.3.2.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="rfc7235.html#header.authorization" class="smpl">Authorization</a> header field (<a href="rfc7235.html#header.authorization" title="Authorization">Section 4.2</a> of <a href="#RFC7235" id="rfc.xref.RFC7235.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[RFC7235]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.</p><p id="rfc.section.3.2.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>) have such an effect: must-revalidate, public, and s-maxage.</p><p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server.</p></div><div id="combining.responses"><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a href="#combining.responses">Combining Partial Content</a></h2><p id="rfc.section.3.3.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (<a href="#RFC7233" id="rfc.xref.RFC7233.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in <a href="rfc7233.html#combining.byte.ranges" title="Combining Ranges">Section 4.3</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.</p><p id="rfc.section.3.3.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: </p><ul><li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;5.5</a>);</li><li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,</li><li>use other header fields provided in the new response, aside from <a href="rfc7233.html#header.content-range" class="smpl">Content-Range</a>, to replace all instances of the corresponding header fields in the stored response.</li></ul></div></div><div id="constructing.responses.from.caches"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h1><p id="rfc.section.4.p.1">When presented with a request, a cache <em class="bcp14">MUST NOT</em> reuse a stored response, unless: </p><ul><li>The presented effective request URI (<a href="rfc7230.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) and that of the stored response match, and</li><li>the request method associated with the stored response allows it to be used for the presented request, and</li><li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), and</li><li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;5.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;5.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and</li><li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and</li><li>the stored response is either: <ul><li>fresh (see <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>), or</li><li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>), or</li><li>successfully validated (see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>).</li></ul> </li></ul><p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p><p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;5.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.</p><p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="rfc7231.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.</p><p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already-stored responses; see <a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>.</p><p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="rfc7231.html#header.date" class="smpl">Date</a> header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.</p><p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them upon every use.</p><div id="caching.negotiated.responses"><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2><p id="rfc.section.4.1.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="rfc7231.html#header.vary" class="smpl">Vary</a> header field (<a href="rfc7231.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request.</p><p id="rfc.section.4.1.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following: </p><ul><li>adding or removing whitespace, where allowed in the header field's syntax</li><li>combining multiple header fields with the same field name (see <a href="rfc7230.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>)</li><li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)</li></ul><p id="rfc.section.4.1.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request if it is also absent there.</p><p id="rfc.section.4.1.p.4">A <a href="rfc7231.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.</p><p id="rfc.section.4.1.p.5">The stored response with matching selecting header fields is known as the selected response.</p><p id="rfc.section.4.1.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="rfc7231.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="rfc7231.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.</p><p id="rfc.section.4.1.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) request.</p></div><div id="expiration.model"><div id="rfc.iref.f.1"></div><div id="rfc.iref.s.2"></div><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#expiration.model">Freshness</a></h2><p id="rfc.section.4.2.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.</p><div id="rfc.iref.f.2"></div><div id="rfc.iref.e.1"></div><div id="rfc.iref.h.1"></div><p id="rfc.section.4.2.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation, whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiration time is available.</p><div id="rfc.iref.a.1"></div><p id="rfc.section.4.2.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.</p><p id="rfc.section.4.2.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency.</p><p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;5.3</a>) or the max-age response directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation is not likely to change in a semantically significant way before the expiration time is reached.</p><p id="rfc.section.4.2.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).</p><p id="rfc.section.4.2.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>).</p><div id="rfc.figure.u.2"></div><p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
     
    648648Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
    649649
    650 </pre><p id="rfc.section.5.5.p.10">Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.</p><p id="rfc.section.5.5.p.11">If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the <a href="rfc7231.html#header.date" class="smpl">Date</a> value in the same message, the recipient <em class="bcp14">MUST</em> exclude the warning-value containing that warn-date before storing, forwarding, or using the message. This allows recipients to exclude warning-values that were improperly retained after a cache validation. If all of the warning-values are excluded, the recipient <em class="bcp14">MUST</em> exclude the Warning header field as well.</p><p id="rfc.section.5.5.p.12">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in <a href="#warn.code.registry.procedure" title="Procedure">Section&nbsp;7.2.1</a>.</p><div id="warn.110"><div id="rfc.iref.49"></div><div id="rfc.iref.r.1"></div><h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></h3><p id="rfc.section.5.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.</p></div><div id="warn.111"><div id="rfc.iref.50"></div><div id="rfc.iref.r.2"></div><h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></h3><p id="rfc.section.5.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server.</p></div><div id="warn.112"><div id="rfc.iref.51"></div><div id="rfc.iref.d.1"></div><h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></h3><p id="rfc.section.5.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.</p></div><div id="warn.113"><div id="rfc.iref.52"></div><div id="rfc.iref.h.2"></div><h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></h3><p id="rfc.section.5.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.</p></div><div id="warn.199"><div id="rfc.iref.53"></div><div id="rfc.iref.m.6"></div><h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></h3><p id="rfc.section.5.5.5.p.1">The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.</p></div><div id="warn.214"><div id="rfc.iref.54"></div><div id="rfc.iref.t.1"></div><h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></h3><p id="rfc.section.5.5.6.p.1">This Warning code <em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response.</p></div><div id="warn.299"><div id="rfc.iref.55"></div><div id="rfc.iref.m.7"></div><h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></h3><p id="rfc.section.5.5.7.p.1">The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.</p></div></div></div><div id="history.lists"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#history.lists">History Lists</a></h1><p id="rfc.section.6.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.</p><p id="rfc.section.6.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.</p><p id="rfc.section.6.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).</p></div><div id="iana.considerations"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><div id="cache.directive.registry"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a></h2><p id="rfc.section.7.1.p.1">The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.</p><div id="cache.directive.registry.procedure"><h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></h3><p id="rfc.section.7.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: </p><ul><li>Cache Directive Name</li><li>Pointer to specification text</li></ul><p id="rfc.section.7.1.1.p.2">Values to be added to this namespace require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).</p></div><div id="cache.directive.considerations"><h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3><p id="rfc.section.7.1.2.p.1">New extension directives ought to consider defining:</p><p id="rfc.section.7.1.2.p.2"></p><ul><li>What it means for a directive to be specified multiple times,</li><li>When the directive does not take an argument, what it means when an argument is present,</li><li>When the directive requires an argument, what it means when it is missing,</li><li>Whether the directive is specific to requests, responses, or able to be used in either.</li></ul><p id="rfc.section.7.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p></div><div id="cache.directive.registration"><h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a href="#cache.directive.registration">Registrations</a></h3><p id="rfc.section.7.1.3.p.1">The registry has been populated with the registrations below:</p><div id="rfc.table.1"><div id="iana.cache.directive.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Cache Directive</th><th>Reference</th></tr></thead><tbody><tr><td class="left">max-age</td><td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section&nbsp;5.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a> </td></tr><tr><td class="left">max-stale</td><td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section&nbsp;5.2.1.2</a> </td></tr><tr><td class="left">min-fresh</td><td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section&nbsp;5.2.1.3</a> </td></tr><tr><td class="left">must-revalidate</td><td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section&nbsp;5.2.2.1</a> </td></tr><tr><td class="left">no-cache</td><td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section&nbsp;5.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a> </td></tr><tr><td class="left">no-store</td><td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section&nbsp;5.2.2.3</a> </td></tr><tr><td class="left">no-transform</td><td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section&nbsp;5.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section&nbsp;5.2.2.4</a> </td></tr><tr><td class="left">only-if-cached</td><td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section&nbsp;5.2.1.7</a> </td></tr><tr><td class="left">private</td><td class="left"><a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a> </td></tr><tr><td class="left">proxy-revalidate</td><td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section&nbsp;5.2.2.7</a> </td></tr><tr><td class="left">public</td><td class="left"><a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a> </td></tr><tr><td class="left">s-maxage</td><td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a> </td></tr><tr><td class="left">stale-if-error</td><td class="left"><a href="#RFC5861" id="rfc.xref.RFC5861.1"><cite title="HTTP Cache-Control Extensions for Stale Content">[RFC5861]</cite></a>, <a href="https://tools.ietf.org/html/rfc5861#section-4">Section 4</a> </td></tr><tr><td class="left">stale-while-revalidate</td><td class="left"><a href="#RFC5861" id="rfc.xref.RFC5861.2"><cite title="HTTP Cache-Control Extensions for Stale Content">[RFC5861]</cite></a>, <a href="https://tools.ietf.org/html/rfc5861#section-3">Section 3</a> </td></tr></tbody></table></div></div></div><div id="warn.code.registry"><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#warn.code.registry">Warn Code Registry</a></h2><p id="rfc.section.7.2.p.1">The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at &lt;<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>&gt;.</p><div id="warn.code.registry.procedure"><h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></h3><p id="rfc.section.7.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: </p><ul><li>Warn Code (3 digits)</li><li>Short Description</li><li>Pointer to specification text</li></ul><p id="rfc.section.7.2.1.p.2">Values to be added to this namespace require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).</p></div><div id="warn.code.registration"><h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a href="#warn.code.registration">Registrations</a></h3><p id="rfc.section.7.2.2.p.1">The registry has been populated with the registrations below:</p><div id="rfc.table.2"><div id="iana.warn.code.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Warn Code</th><th>Short Description</th><th>Reference</th></tr></thead><tbody><tr><td class="left">110</td><td class="left">Response is Stale</td><td class="left"><a href="#warn.110" id="rfc.xref.warn.110.2" title="Warning: 110 - &#34;Response is Stale&#34;">Section&nbsp;5.5.1</a> </td></tr><tr><td class="left">111</td><td class="left">Revalidation Failed</td><td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="Warning: 111 - &#34;Revalidation Failed&#34;">Section&nbsp;5.5.2</a> </td></tr><tr><td class="left">112</td><td class="left">Disconnected Operation</td><td class="left"><a href="#warn.112" id="rfc.xref.warn.112.2" title="Warning: 112 - &#34;Disconnected Operation&#34;">Section&nbsp;5.5.3</a> </td></tr><tr><td class="left">113</td><td class="left">Heuristic Expiration</td><td class="left"><a href="#warn.113" id="rfc.xref.warn.113.2" title="Warning: 113 - &#34;Heuristic Expiration&#34;">Section&nbsp;5.5.4</a> </td></tr><tr><td class="left">199</td><td class="left">Miscellaneous Warning</td><td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="Warning: 199 - &#34;Miscellaneous Warning&#34;">Section&nbsp;5.5.5</a> </td></tr><tr><td class="left">214</td><td class="left">Transformation Applied</td><td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="Warning: 214 - &#34;Transformation Applied&#34;">Section&nbsp;5.5.6</a> </td></tr><tr><td class="left">299</td><td class="left">Miscellaneous Persistent Warning</td><td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="Warning: 299 - &#34;Miscellaneous Persistent Warning&#34;">Section&nbsp;5.5.7</a> </td></tr></tbody></table></div></div></div><div id="header.field.registration"><h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2><p id="rfc.section.7.3.p.1">HTTP header fields are registered within the "Message Headers" registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/">http://www.iana.org/assignments/message-headers/</a>&gt;.</p><p id="rfc.section.7.3.p.2">This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>).</p><div id="rfc.table.3"><div id="iana.header.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Protocol</th><th>Status</th><th>Reference</th></tr></thead><tbody><tr><td class="left">Age</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section&nbsp;5.1</a> </td></tr><tr><td class="left">Cache-Control</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;5.2</a> </td></tr><tr><td class="left">Expires</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section&nbsp;5.3</a> </td></tr><tr><td class="left">Pragma</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;5.4</a> </td></tr><tr><td class="left">Warning</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;5.5</a> </td></tr></tbody></table></div><p id="rfc.section.7.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p></div></div><div id="security.considerations"><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in HTTP messaging <a href="#RFC7230" id="rfc.xref.RFC7230.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> and semantics <a href="#RFC7231" id="rfc.xref.RFC7231.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.</p><p id="rfc.section.8.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.</p><p id="rfc.section.8.p.3">In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see <a href="rfc7230.html#message.body.length" title="Message Body Length">Section 3.3.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> for the relevant requirements.</p><p id="rfc.section.8.p.4">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.</p><p id="rfc.section.8.p.5">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache.</p><p id="rfc.section.8.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.</p></div><div id="acks"><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#acks">Acknowledgments</a></h1><p id="rfc.section.9.p.1">See <a href="rfc7230.html#acks" title="Acknowledgments">Section 10</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References</h2><table><tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC5234">[RFC5234]</b></td><td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>&#8221;, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC7230">[RFC7230]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>&#8221;, RFC&nbsp;7230, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7232">[RFC7232]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7232">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</a>&#8221;, RFC&nbsp;7232, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7233">[RFC7233]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7233">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>&#8221;, RFC&nbsp;7233, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7235">[RFC7235]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7235">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>&#8221;, RFC&nbsp;7235, June&nbsp;2014.</td></tr></table><h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References</h2><table><tr><td class="reference"><b id="BCP90">[BCP90]</b></td><td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>&#8221;, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC2616">[RFC2616]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2616, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC5226">[RFC5226]</b></td><td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>&#8221;, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC5861">[RFC5861]</b></td><td class="top"><a href="mailto:mnot@yahoo-inc.com" title="Yahoo! Inc.">Nottingham, M.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5861">HTTP Cache-Control Extensions for Stale Content</a>&#8221;, RFC&nbsp;5861, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC5905">[RFC5905]</b></td><td class="top">Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, &#8220;<a href="https://tools.ietf.org/html/rfc5905">Network Time Protocol Version 4: Protocol and Algorithms Specification</a>&#8221;, RFC&nbsp;5905, June&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC6265">[RFC6265]</b></td><td class="top"><a href="mailto:abarth@eecs.berkeley.edu" title="&#xA;          University of California, Berkeley&#xA;        ">Barth, A.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a>&#8221;, RFC&nbsp;6265, April&nbsp;2011.</td></tr></table><div id="changes.from.rfc.2616"><h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1><p id="rfc.section.A.p.1">The specification has been substantially rewritten for clarity.</p><p id="rfc.section.A.p.2">The conditions under which an authenticated response can be cached have been clarified. (<a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>)</p><p id="rfc.section.A.p.3">New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>)</p><p id="rfc.section.A.p.4">The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>)</p><p id="rfc.section.A.p.5">The <a href="rfc7231.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>)</p><p id="rfc.section.A.p.6">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>)</p><p id="rfc.section.A.p.7">Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)</p><p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)</p><p id="rfc.section.A.p.9">Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;5.2</a>)</p><p id="rfc.section.A.p.10">The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>)</p><p id="rfc.section.A.p.11">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>)</p><p id="rfc.section.A.p.12">The "no-cache" response directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>)</p><p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section&nbsp;5.3</a>)</p><p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;5.4</a>)</p><p id="rfc.section.A.p.15">Some requirements regarding production and processing of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;5.5</a>)</p><p id="rfc.section.A.p.16">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (<a href="#cache.directive.registry" title="Cache Directive Registry">Section&nbsp;7.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section&nbsp;7.2</a>)</p></div><div id="imported.abnf"><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#imported.abnf">Imported ABNF</a></h1><p id="rfc.section.B.p.1">The following core rules are included by reference, as defined in <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></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), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).</p><p id="rfc.section.B.p.2">The rules below are defined in <a href="#RFC7230" id="rfc.xref.RFC7230.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>:</p><div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, see <a href="#RFC7230" id="rfc.xref.RFC7230.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     650</pre><p id="rfc.section.5.5.p.10">Warnings have accompanying warn-text that describes the error, e.g., for logging. It is advisory only, and its content does not affect interpretation of the warn-code.</p><p id="rfc.section.5.5.p.11">If a recipient that uses, evaluates, or displays Warning header fields receives a warn-date that is different from the <a href="rfc7231.html#header.date" class="smpl">Date</a> value in the same message, the recipient <em class="bcp14">MUST</em> exclude the warning-value containing that warn-date before storing, forwarding, or using the message. This allows recipients to exclude warning-values that were improperly retained after a cache validation. If all of the warning-values are excluded, the recipient <em class="bcp14">MUST</em> exclude the Warning header field as well.</p><p id="rfc.section.5.5.p.12">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description of its meaning. The procedure for defining additional warn codes is described in <a href="#warn.code.registry.procedure" title="Procedure">Section&nbsp;7.2.1</a>.</p><div id="warn.110"><div id="rfc.iref.1.1"></div><div id="rfc.iref.r.1"></div><h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a href="#warn.110">Warning: 110 - "Response is Stale"</a></h3><p id="rfc.section.5.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.</p></div><div id="warn.111"><div id="rfc.iref.1.2"></div><div id="rfc.iref.r.2"></div><h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<a href="#warn.111">Warning: 111 - "Revalidation Failed"</a></h3><p id="rfc.section.5.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server.</p></div><div id="warn.112"><div id="rfc.iref.1.3"></div><div id="rfc.iref.d.1"></div><h3 id="rfc.section.5.5.3"><a href="#rfc.section.5.5.3">5.5.3</a>&nbsp;<a href="#warn.112">Warning: 112 - "Disconnected Operation"</a></h3><p id="rfc.section.5.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.</p></div><div id="warn.113"><div id="rfc.iref.1.4"></div><div id="rfc.iref.h.2"></div><h3 id="rfc.section.5.5.4"><a href="#rfc.section.5.5.4">5.5.4</a>&nbsp;<a href="#warn.113">Warning: 113 - "Heuristic Expiration"</a></h3><p id="rfc.section.5.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.</p></div><div id="warn.199"><div id="rfc.iref.1.5"></div><div id="rfc.iref.m.6"></div><h3 id="rfc.section.5.5.5"><a href="#rfc.section.5.5.5">5.5.5</a>&nbsp;<a href="#warn.199">Warning: 199 - "Miscellaneous Warning"</a></h3><p id="rfc.section.5.5.5.p.1">The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.</p></div><div id="warn.214"><div id="rfc.iref.2.1"></div><div id="rfc.iref.t.1"></div><h3 id="rfc.section.5.5.6"><a href="#rfc.section.5.5.6">5.5.6</a>&nbsp;<a href="#warn.214">Warning: 214 - "Transformation Applied"</a></h3><p id="rfc.section.5.5.6.p.1">This Warning code <em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type, or modifying the representation data, unless this Warning code already appears in the response.</p></div><div id="warn.299"><div id="rfc.iref.2.2"></div><div id="rfc.iref.m.7"></div><h3 id="rfc.section.5.5.7"><a href="#rfc.section.5.5.7">5.5.7</a>&nbsp;<a href="#warn.299">Warning: 299 - "Miscellaneous Persistent Warning"</a></h3><p id="rfc.section.5.5.7.p.1">The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.</p></div></div></div><div id="history.lists"><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#history.lists">History Lists</a></h1><p id="rfc.section.6.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.</p><p id="rfc.section.6.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.</p><p id="rfc.section.6.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).</p></div><div id="iana.considerations"><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1><div id="cache.directive.registry"><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#cache.directive.registry">Cache Directive Registry</a></h2><p id="rfc.section.7.1.p.1">The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the cache directives. It has been created and is now maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.</p><div id="cache.directive.registry.procedure"><h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a href="#cache.directive.registry.procedure">Procedure</a></h3><p id="rfc.section.7.1.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: </p><ul><li>Cache Directive Name</li><li>Pointer to specification text</li></ul><p id="rfc.section.7.1.1.p.2">Values to be added to this namespace require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).</p></div><div id="cache.directive.considerations"><h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a href="#cache.directive.considerations">Considerations for New Cache Control Directives</a></h3><p id="rfc.section.7.1.2.p.1">New extension directives ought to consider defining:</p><p id="rfc.section.7.1.2.p.2"></p><ul><li>What it means for a directive to be specified multiple times,</li><li>When the directive does not take an argument, what it means when an argument is present,</li><li>When the directive requires an argument, what it means when it is missing,</li><li>Whether the directive is specific to requests, responses, or able to be used in either.</li></ul><p id="rfc.section.7.1.2.p.3">See also <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;5.2.3</a>.</p></div><div id="cache.directive.registration"><h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a href="#cache.directive.registration">Registrations</a></h3><p id="rfc.section.7.1.3.p.1">The registry has been populated with the registrations below:</p><div id="rfc.table.1"><div id="iana.cache.directive.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Cache Directive</th><th>Reference</th></tr></thead><tbody><tr><td class="left">max-age</td><td class="left"><a href="#cache-request-directive.max-age" title="max-age">Section&nbsp;5.2.1.1</a>, <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;5.2.2.8</a> </td></tr><tr><td class="left">max-stale</td><td class="left"><a href="#cache-request-directive.max-stale" title="max-stale">Section&nbsp;5.2.1.2</a> </td></tr><tr><td class="left">min-fresh</td><td class="left"><a href="#cache-request-directive.min-fresh" title="min-fresh">Section&nbsp;5.2.1.3</a> </td></tr><tr><td class="left">must-revalidate</td><td class="left"><a href="#cache-response-directive.must-revalidate" title="must-revalidate">Section&nbsp;5.2.2.1</a> </td></tr><tr><td class="left">no-cache</td><td class="left"><a href="#cache-request-directive.no-cache" title="no-cache">Section&nbsp;5.2.1.4</a>, <a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a> </td></tr><tr><td class="left">no-store</td><td class="left"><a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>, <a href="#cache-response-directive.no-store" title="no-store">Section&nbsp;5.2.2.3</a> </td></tr><tr><td class="left">no-transform</td><td class="left"><a href="#cache-request-directive.no-transform" title="no-transform">Section&nbsp;5.2.1.6</a>, <a href="#cache-response-directive.no-transform" title="no-transform">Section&nbsp;5.2.2.4</a> </td></tr><tr><td class="left">only-if-cached</td><td class="left"><a href="#cache-request-directive.only-if-cached" title="only-if-cached">Section&nbsp;5.2.1.7</a> </td></tr><tr><td class="left">private</td><td class="left"><a href="#cache-response-directive.private" title="private">Section&nbsp;5.2.2.6</a> </td></tr><tr><td class="left">proxy-revalidate</td><td class="left"><a href="#cache-response-directive.proxy-revalidate" title="proxy-revalidate">Section&nbsp;5.2.2.7</a> </td></tr><tr><td class="left">public</td><td class="left"><a href="#cache-response-directive.public" title="public">Section&nbsp;5.2.2.5</a> </td></tr><tr><td class="left">s-maxage</td><td class="left"><a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;5.2.2.9</a> </td></tr><tr><td class="left">stale-if-error</td><td class="left"><a href="#RFC5861" id="rfc.xref.RFC5861.1"><cite title="HTTP Cache-Control Extensions for Stale Content">[RFC5861]</cite></a>, <a href="https://tools.ietf.org/html/rfc5861#section-4">Section 4</a> </td></tr><tr><td class="left">stale-while-revalidate</td><td class="left"><a href="#RFC5861" id="rfc.xref.RFC5861.2"><cite title="HTTP Cache-Control Extensions for Stale Content">[RFC5861]</cite></a>, <a href="https://tools.ietf.org/html/rfc5861#section-3">Section 3</a> </td></tr></tbody></table></div></div></div><div id="warn.code.registry"><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#warn.code.registry">Warn Code Registry</a></h2><p id="rfc.section.7.2.p.1">The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes. It has been created and is now maintained at &lt;<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>&gt;.</p><div id="warn.code.registry.procedure"><h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a href="#warn.code.registry.procedure">Procedure</a></h3><p id="rfc.section.7.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: </p><ul><li>Warn Code (3 digits)</li><li>Short Description</li><li>Pointer to specification text</li></ul><p id="rfc.section.7.2.1.p.2">Values to be added to this namespace require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).</p></div><div id="warn.code.registration"><h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a href="#warn.code.registration">Registrations</a></h3><p id="rfc.section.7.2.2.p.1">The registry has been populated with the registrations below:</p><div id="rfc.table.2"><div id="iana.warn.code.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Warn Code</th><th>Short Description</th><th>Reference</th></tr></thead><tbody><tr><td class="left">110</td><td class="left">Response is Stale</td><td class="left"><a href="#warn.110" id="rfc.xref.warn.110.2" title="Warning: 110 - &#34;Response is Stale&#34;">Section&nbsp;5.5.1</a> </td></tr><tr><td class="left">111</td><td class="left">Revalidation Failed</td><td class="left"><a href="#warn.111" id="rfc.xref.warn.111.1" title="Warning: 111 - &#34;Revalidation Failed&#34;">Section&nbsp;5.5.2</a> </td></tr><tr><td class="left">112</td><td class="left">Disconnected Operation</td><td class="left"><a href="#warn.112" id="rfc.xref.warn.112.2" title="Warning: 112 - &#34;Disconnected Operation&#34;">Section&nbsp;5.5.3</a> </td></tr><tr><td class="left">113</td><td class="left">Heuristic Expiration</td><td class="left"><a href="#warn.113" id="rfc.xref.warn.113.2" title="Warning: 113 - &#34;Heuristic Expiration&#34;">Section&nbsp;5.5.4</a> </td></tr><tr><td class="left">199</td><td class="left">Miscellaneous Warning</td><td class="left"><a href="#warn.199" id="rfc.xref.warn.199.1" title="Warning: 199 - &#34;Miscellaneous Warning&#34;">Section&nbsp;5.5.5</a> </td></tr><tr><td class="left">214</td><td class="left">Transformation Applied</td><td class="left"><a href="#warn.214" id="rfc.xref.warn.214.1" title="Warning: 214 - &#34;Transformation Applied&#34;">Section&nbsp;5.5.6</a> </td></tr><tr><td class="left">299</td><td class="left">Miscellaneous Persistent Warning</td><td class="left"><a href="#warn.299" id="rfc.xref.warn.299.1" title="Warning: 299 - &#34;Miscellaneous Persistent Warning&#34;">Section&nbsp;5.5.7</a> </td></tr></tbody></table></div></div></div><div id="header.field.registration"><h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2><p id="rfc.section.7.3.p.1">HTTP header fields are registered within the "Message Headers" registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/">http://www.iana.org/assignments/message-headers/</a>&gt;.</p><p id="rfc.section.7.3.p.2">This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>).</p><div id="rfc.table.3"><div id="iana.header.registration.table"></div><table class="tt full left" cellpadding="3" cellspacing="0"><thead><tr><th>Header Field Name</th><th>Protocol</th><th>Status</th><th>Reference</th></tr></thead><tbody><tr><td class="left">Age</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.age" id="rfc.xref.header.age.3" title="Age">Section&nbsp;5.1</a> </td></tr><tr><td class="left">Cache-Control</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;5.2</a> </td></tr><tr><td class="left">Expires</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.expires" id="rfc.xref.header.expires.4" title="Expires">Section&nbsp;5.3</a> </td></tr><tr><td class="left">Pragma</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;5.4</a> </td></tr><tr><td class="left">Warning</td><td class="left">http</td><td class="left">standard</td><td class="left"><a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;5.5</a> </td></tr></tbody></table></div><p id="rfc.section.7.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p></div></div><div id="security.considerations"><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1><p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP caching. More general security considerations are addressed in HTTP messaging <a href="#RFC7230" id="rfc.xref.RFC7230.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> and semantics <a href="#RFC7231" id="rfc.xref.RFC7231.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>.</p><p id="rfc.section.8.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected as sensitive information.</p><p id="rfc.section.8.p.3">In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see <a href="rfc7230.html#message.body.length" title="Message Body Length">Section 3.3.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> for the relevant requirements.</p><p id="rfc.section.8.p.4">Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties.</p><p id="rfc.section.8.p.5">Furthermore, the very use of a cache can bring about privacy concerns. For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache.</p><p id="rfc.section.8.p.6">Note that the Set-Cookie response header field <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches. Servers who wish to control caching of these responses are encouraged to emit appropriate Cache-Control response header fields.</p></div><div id="acks"><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#acks">Acknowledgments</a></h1><p id="rfc.section.9.p.1">See <a href="rfc7230.html#acks" title="Acknowledgments">Section 10</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References</h1><h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References</h2><table><tr><td class="reference"><b id="RFC2119">[RFC2119]</b></td><td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>&#8221;, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.</td></tr><tr><td class="reference"><b id="RFC5234">[RFC5234]</b></td><td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>&#8221;, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC7230">[RFC7230]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>&#8221;, RFC&nbsp;7230, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7231">[RFC7231]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>&#8221;, RFC&nbsp;7231, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7232">[RFC7232]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7232">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</a>&#8221;, RFC&nbsp;7232, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7233">[RFC7233]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7233">Hypertext Transfer Protocol (HTTP/1.1): Range Requests</a>&#8221;, RFC&nbsp;7233, June&nbsp;2014.</td></tr><tr><td class="reference"><b id="RFC7235">[RFC7235]</b></td><td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a> and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc7235">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>&#8221;, RFC&nbsp;7235, June&nbsp;2014.</td></tr></table><h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References</h2><table><tr><td class="reference"><b id="BCP90">[BCP90]</b></td><td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, &#8220;<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>&#8221;, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.</td></tr><tr><td class="reference"><b id="RFC2616">[RFC2616]</b></td><td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, &#8220;<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>&#8221;, RFC&nbsp;2616, June&nbsp;1999.</td></tr><tr><td class="reference"><b id="RFC5226">[RFC5226]</b></td><td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>&#8221;, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.</td></tr><tr><td class="reference"><b id="RFC5861">[RFC5861]</b></td><td class="top"><a href="mailto:mnot@yahoo-inc.com" title="Yahoo! Inc.">Nottingham, M.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc5861">HTTP Cache-Control Extensions for Stale Content</a>&#8221;, RFC&nbsp;5861, April&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC5905">[RFC5905]</b></td><td class="top">Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, &#8220;<a href="https://tools.ietf.org/html/rfc5905">Network Time Protocol Version 4: Protocol and Algorithms Specification</a>&#8221;, RFC&nbsp;5905, June&nbsp;2010.</td></tr><tr><td class="reference"><b id="RFC6265">[RFC6265]</b></td><td class="top"><a href="mailto:abarth@eecs.berkeley.edu" title="&#xA;          University of California, Berkeley&#xA;        ">Barth, A.</a>, &#8220;<a href="https://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a>&#8221;, RFC&nbsp;6265, April&nbsp;2011.</td></tr></table><div id="changes.from.rfc.2616"><h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1><p id="rfc.section.A.p.1">The specification has been substantially rewritten for clarity.</p><p id="rfc.section.A.p.2">The conditions under which an authenticated response can be cached have been clarified. (<a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a>)</p><p id="rfc.section.A.p.3">New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>)</p><p id="rfc.section.A.p.4">The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>)</p><p id="rfc.section.A.p.5">The <a href="rfc7231.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>)</p><p id="rfc.section.A.p.6">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>)</p><p id="rfc.section.A.p.7">Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)</p><p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation" title="Invalidation">Section&nbsp;4.4</a>)</p><p id="rfc.section.A.p.9">Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;5.2</a>)</p><p id="rfc.section.A.p.10">The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section&nbsp;5.2.1.5</a>)</p><p id="rfc.section.A.p.11">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;5.2.2</a>)</p><p id="rfc.section.A.p.12">The "no-cache" response directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;5.2.2.2</a>)</p><p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section&nbsp;5.3</a>)</p><p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;5.4</a>)</p><p id="rfc.section.A.p.15">Some requirements regarding production and processing of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;5.5</a>)</p><p id="rfc.section.A.p.16">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (<a href="#cache.directive.registry" title="Cache Directive Registry">Section&nbsp;7.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section&nbsp;7.2</a>)</p></div><div id="imported.abnf"><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#imported.abnf">Imported ABNF</a></h1><p id="rfc.section.B.p.1">The following core rules are included by reference, as defined in <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></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), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).</p><p id="rfc.section.B.p.2">The rules below are defined in <a href="#RFC7230" id="rfc.xref.RFC7230.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>:</p><div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, see <a href="#RFC7230" id="rfc.xref.RFC7230.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    651651  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;field-name, see <a href="#RFC7230" id="rfc.xref.RFC7230.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    652652  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, see <a href="#RFC7230" id="rfc.xref.RFC7230.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, <a href="rfc7230.html#field.components" title="Field Value Components">Section 3.2.6</a>&gt;
     
    698698<a href="#header.warning" class="smpl">warning-value</a> = warn-code SP warn-agent SP warn-text [ SP warn-date
    699699 ]
    700 </pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>110 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.110.1">4.2.4</a>, <a href="#rfc.iref.49"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.2">7.2.2</a></li><li>111 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li><li>112 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.112.1">4.2.4</a>, <a href="#rfc.iref.51"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.2">7.2.2</a></li><li>113 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.113.1">4.2.2</a>, <a href="#rfc.iref.52"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.2">7.2.2</a></li><li>199 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.53"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>214 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.54"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li><li>299 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.55"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.2</a></li><li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>5.1</b></a>, <a href="#rfc.xref.header.age.3">7.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.3</a>, <a href="#BCP90"><b>10.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li><li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.2">2</a></li><li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li><li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>5.2</b></a>, <a href="#rfc.xref.header.cache-control.2">7.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>Disconnected Operation (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.112.1">4.2.4</a>, <a href="#rfc.iref.d.1"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.2">7.2.2</a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>5.3</b></a>, <a href="#rfc.xref.header.expires.4">7.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li><li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.2</a></li></ul></li><li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul><li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.1">4.2</a></li><li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">4.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>5.1</b></a></li><li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>5.2</b></a></li><li><tt>cache-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>5.2</b></a></li><li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2.1</b></a></li><li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>5.3</b></a></li><li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>5.4</b></a></li><li><tt>Pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>5.4</b></a></li><li><tt>pragma-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>5.4</b></a></li><li><tt>warn-agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>5.5</b></a></li><li><tt>warn-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>5.5</b></a></li><li><tt>warn-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>5.5</b></a></li><li><tt>warn-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>5.5</b></a></li><li><tt>Warning</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>5.5</b></a></li><li><tt>warning-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>5.5</b></a></li></ul></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>Heuristic Expiration (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.113.1">4.2.2</a>, <a href="#rfc.iref.h.2"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.2">7.2.2</a></li><li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">4.2</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>max-age (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>5.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>5.2.2.8</b></a></li><li>max-stale (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>5.2.1.2</b></a></li><li>min-fresh (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>5.2.1.3</b></a></li><li>Miscellaneous Persistent Warning (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.m.7"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li><li>Miscellaneous Warning (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.m.6"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li><li>must-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>5.2.2.1</b></a></li></ul></li><li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul><li>no-cache (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>5.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>5.2.2.2</b></a></li><li>no-store (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.2"><b>5.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>5.2.2.3</b></a></li><li>no-transform (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.3"><b>5.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>5.2.2.4</b></a></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>only-if-cached (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>5.2.1.7</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>5.4</b></a>, <a href="#rfc.xref.header.pragma.2">7.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li><li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>5.2.2.6</b></a></li><li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1</a></li><li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>5.2.2.7</b></a></li><li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>5.2.2.5</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Response is Stale (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.110.1">4.2.4</a>, <a href="#rfc.iref.r.1"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.2">7.2.2</a></li><li>Revalidation Failed (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>10.2</b></a><ul><li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a></li></ul></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC5861</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a>, <a href="#rfc.xref.RFC5861.2">7.1.3</a>, <a href="#RFC5861"><b>10.2</b></a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.2">7.1.3</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a></li></ul></li><li><em>RFC5905</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5905.1">4.2.3</a>, <a href="#RFC5905"><b>10.2</b></a></li><li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">8</a>, <a href="#RFC6265"><b>10.2</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a>, <a href="#rfc.xref.RFC7230.2">1.2</a>, <a href="#rfc.xref.RFC7230.3">3.1</a>, <a href="#rfc.xref.RFC7230.4">4</a>, <a href="#rfc.xref.RFC7230.5">4.1</a>, <a href="#rfc.xref.RFC7230.6">4.4</a>, <a href="#rfc.xref.RFC7230.7">4.4</a>, <a href="#rfc.xref.RFC7230.8">4.4</a>, <a href="#rfc.xref.RFC7230.9">5.2.1.6</a>, <a href="#rfc.xref.RFC7230.10">5.2.2.4</a>, <a href="#rfc.xref.RFC7230.11">8</a>, <a href="#rfc.xref.RFC7230.12">8</a>, <a href="#rfc.xref.RFC7230.13">9</a>, <a href="#RFC7230"><b>10.1</b></a>, <a href="#rfc.xref.RFC7230.14">B</a>, <a href="#rfc.xref.RFC7230.15">B</a>, <a href="#rfc.xref.RFC7230.16">B</a>, <a href="#rfc.xref.RFC7230.17">B</a>, <a href="#rfc.xref.RFC7230.18">B</a>, <a href="#rfc.xref.RFC7230.19">B</a>, <a href="#rfc.xref.RFC7230.20">B</a>, <a href="#rfc.xref.RFC7230.21">B</a>, <a href="#rfc.xref.RFC7230.22">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.22">C</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a></li><li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.19">B</a>, <a href="#rfc.xref.RFC7230.21">B</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.5">4.1</a>, <a href="#rfc.xref.RFC7230.16">B</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.15">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.17">B</a>, <a href="#rfc.xref.RFC7230.18">B</a></li><li><em>Section 3.3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.12">8</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">4</a>, <a href="#rfc.xref.RFC7230.6">4.4</a>, <a href="#rfc.xref.RFC7230.7">4.4</a>, <a href="#rfc.xref.RFC7230.8">4.4</a></li><li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.20">B</a></li><li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">5.2.1.6</a>, <a href="#rfc.xref.RFC7230.10">5.2.2.4</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.13">9</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2</a>, <a href="#rfc.xref.RFC7231.2">2</a>, <a href="#rfc.xref.RFC7231.3">4</a>, <a href="#rfc.xref.RFC7231.4">4.1</a>, <a href="#rfc.xref.RFC7231.5">4.2.2</a>, <a href="#rfc.xref.RFC7231.6">4.2.3</a>, <a href="#rfc.xref.RFC7231.7">4.4</a>, <a href="#rfc.xref.RFC7231.8">5.3</a>, <a href="#rfc.xref.RFC7231.9">8</a>, <a href="#RFC7231"><b>10.1</b></a>, <a href="#rfc.xref.RFC7231.10">B</a><ul><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">4</a>, <a href="#rfc.xref.RFC7231.7">4.4</a></li><li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.2">2</a></li><li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.5">4.2.2</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.8">5.3</a>, <a href="#rfc.xref.RFC7231.10">B</a></li><li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.6">4.2.3</a></li><li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.4">4.1</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">4.2.2</a>, <a href="#rfc.xref.RFC7232.2">4.3</a>, <a href="#rfc.xref.RFC7232.3">4.3.1</a>, <a href="#rfc.xref.RFC7232.4">4.3.1</a>, <a href="#rfc.xref.RFC7232.5">4.3.2</a>, <a href="#rfc.xref.RFC7232.6">4.3.2</a>, <a href="#rfc.xref.RFC7232.7">4.3.2</a>, <a href="#rfc.xref.RFC7232.8">4.3.4</a>, <a href="#RFC7232"><b>10.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.8">4.3.4</a></li><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">4.2.2</a>, <a href="#rfc.xref.RFC7232.3">4.3.1</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.4">4.3.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">4.3.2</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.7">4.3.2</a></li><li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">4.3.2</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.1</a>, <a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.3">3.3</a>, <a href="#rfc.xref.RFC7233.4">4.3.2</a>, <a href="#rfc.xref.RFC7233.5">4.3.2</a>, <a href="#RFC7233"><b>10.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.5">4.3.2</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.3">3.3</a></li></ul></li><li><em>RFC7235</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">3</a>, <a href="#rfc.xref.RFC7235.2">3.2</a>, <a href="#RFC7235"><b>10.1</b></a><ul><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">3</a>, <a href="#rfc.xref.RFC7235.2">3.2</a></li></ul></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>5.2.2.9</b></a></li><li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1</a></li><li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.2</a></li><li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.3.4</a></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>Transformation Applied (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.3.1</a></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.3.4</a>, <a href="#rfc.xref.header.warning.3">4.3.5</a>, <a href="#rfc.iref.w.1"><b>5.5</b></a>, <a href="#rfc.xref.header.warning.4">7.3</a>, <a href="#rfc.xref.header.warning.5">A</a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
     700</pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul><li>110 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.110.1">4.2.4</a>, <a href="#rfc.iref.1.1"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.2">7.2.2</a></li><li>111 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.1.2"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li><li>112 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.112.1">4.2.4</a>, <a href="#rfc.iref.1.3"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.2">7.2.2</a></li><li>113 (warn-code)&nbsp;&nbsp;<a href="#rfc.xref.warn.113.1">4.2.2</a>, <a href="#rfc.iref.1.4"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.2">7.2.2</a></li><li>199 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.1.5"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li></ul></li><li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul><li>214 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.2.1"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li><li>299 (warn-code)&nbsp;&nbsp;<a href="#rfc.iref.2.2"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.2</a></li><li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>5.1</b></a>, <a href="#rfc.xref.header.age.3">7.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">7.3</a>, <a href="#BCP90"><b>10.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li><li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.2">2</a></li><li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li><li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>5.2</b></a>, <a href="#rfc.xref.header.cache-control.2">7.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li></ul></li><li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul><li>Disconnected Operation (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.112.1">4.2.4</a>, <a href="#rfc.iref.d.1"><b>5.5.3</b></a>, <a href="#rfc.xref.warn.112.2">7.2.2</a></li></ul></li><li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul><li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>5.3</b></a>, <a href="#rfc.xref.header.expires.4">7.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li><li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.2</a></li></ul></li><li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul><li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.1">4.2</a></li><li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">4.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>Age</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>5.1</b></a></li><li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>5.2</b></a></li><li><tt>cache-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>5.2</b></a></li><li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2.1</b></a></li><li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>5.3</b></a></li><li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>5.4</b></a></li><li><tt>Pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>5.4</b></a></li><li><tt>pragma-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>5.4</b></a></li><li><tt>warn-agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>5.5</b></a></li><li><tt>warn-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>5.5</b></a></li><li><tt>warn-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>5.5</b></a></li><li><tt>warn-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>5.5</b></a></li><li><tt>Warning</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>5.5</b></a></li><li><tt>warning-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>5.5</b></a></li></ul></li></ul></li><li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul><li>Heuristic Expiration (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.113.1">4.2.2</a>, <a href="#rfc.iref.h.2"><b>5.5.4</b></a>, <a href="#rfc.xref.warn.113.2">7.2.2</a></li><li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">4.2</a></li></ul></li><li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul><li>max-age (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.1"><b>5.2.1.1</b></a>, <a href="#rfc.iref.m.5"><b>5.2.2.8</b></a></li><li>max-stale (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.2"><b>5.2.1.2</b></a></li><li>min-fresh (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.3"><b>5.2.1.3</b></a></li><li>Miscellaneous Persistent Warning (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.m.7"><b>5.5.7</b></a>, <a href="#rfc.xref.warn.299.1">7.2.2</a></li><li>Miscellaneous Warning (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.m.6"><b>5.5.5</b></a>, <a href="#rfc.xref.warn.199.1">7.2.2</a></li><li>must-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.m.4"><b>5.2.2.1</b></a></li></ul></li><li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul><li>no-cache (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>5.2.1.4</b></a>, <a href="#rfc.iref.n.4"><b>5.2.2.2</b></a></li><li>no-store (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.2"><b>5.2.1.5</b></a>, <a href="#rfc.iref.n.5"><b>5.2.2.3</b></a></li><li>no-transform (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.n.3"><b>5.2.1.6</b></a>, <a href="#rfc.iref.n.6"><b>5.2.2.4</b></a></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li>only-if-cached (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.o.1"><b>5.2.1.7</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>5.4</b></a>, <a href="#rfc.xref.header.pragma.2">7.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li><li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>5.2.2.6</b></a></li><li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1</a></li><li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>5.2.2.7</b></a></li><li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>5.2.2.5</b></a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Response is Stale (warn-text)&nbsp;&nbsp;<a href="#rfc.xref.warn.110.1">4.2.4</a>, <a href="#rfc.iref.r.1"><b>5.5.1</b></a>, <a href="#rfc.xref.warn.110.2">7.2.2</a></li><li>Revalidation Failed (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.warn.111.1">7.2.2</a></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>10.2</b></a><ul><li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a></li></ul></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.1.1</a>, <a href="#rfc.xref.RFC5226.2">7.2.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>10.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC5861</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a>, <a href="#rfc.xref.RFC5861.2">7.1.3</a>, <a href="#RFC5861"><b>10.2</b></a><ul><li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.2">7.1.3</a></li><li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5861.1">7.1.3</a></li></ul></li><li><em>RFC5905</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5905.1">4.2.3</a>, <a href="#RFC5905"><b>10.2</b></a></li><li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">8</a>, <a href="#RFC6265"><b>10.2</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a>, <a href="#rfc.xref.RFC7230.2">1.2</a>, <a href="#rfc.xref.RFC7230.3">3.1</a>, <a href="#rfc.xref.RFC7230.4">4</a>, <a href="#rfc.xref.RFC7230.5">4.1</a>, <a href="#rfc.xref.RFC7230.6">4.4</a>, <a href="#rfc.xref.RFC7230.7">4.4</a>, <a href="#rfc.xref.RFC7230.8">4.4</a>, <a href="#rfc.xref.RFC7230.9">5.2.1.6</a>, <a href="#rfc.xref.RFC7230.10">5.2.2.4</a>, <a href="#rfc.xref.RFC7230.11">8</a>, <a href="#rfc.xref.RFC7230.12">8</a>, <a href="#rfc.xref.RFC7230.13">9</a>, <a href="#RFC7230"><b>10.1</b></a>, <a href="#rfc.xref.RFC7230.14">B</a>, <a href="#rfc.xref.RFC7230.15">B</a>, <a href="#rfc.xref.RFC7230.16">B</a>, <a href="#rfc.xref.RFC7230.17">B</a>, <a href="#rfc.xref.RFC7230.18">B</a>, <a href="#rfc.xref.RFC7230.19">B</a>, <a href="#rfc.xref.RFC7230.20">B</a>, <a href="#rfc.xref.RFC7230.21">B</a>, <a href="#rfc.xref.RFC7230.22">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.22">C</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1.1</a></li><li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.19">B</a>, <a href="#rfc.xref.RFC7230.21">B</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.5">4.1</a>, <a href="#rfc.xref.RFC7230.16">B</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.15">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.17">B</a>, <a href="#rfc.xref.RFC7230.18">B</a></li><li><em>Section 3.3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.12">8</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">4</a>, <a href="#rfc.xref.RFC7230.6">4.4</a>, <a href="#rfc.xref.RFC7230.7">4.4</a>, <a href="#rfc.xref.RFC7230.8">4.4</a></li><li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.20">B</a></li><li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.9">5.2.1.6</a>, <a href="#rfc.xref.RFC7230.10">5.2.2.4</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.13">9</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2</a>, <a href="#rfc.xref.RFC7231.2">2</a>, <a href="#rfc.xref.RFC7231.3">4</a>, <a href="#rfc.xref.RFC7231.4">4.1</a>, <a href="#rfc.xref.RFC7231.5">4.2.2</a>, <a href="#rfc.xref.RFC7231.6">4.2.3</a>, <a href="#rfc.xref.RFC7231.7">4.4</a>, <a href="#rfc.xref.RFC7231.8">5.3</a>, <a href="#rfc.xref.RFC7231.9">8</a>, <a href="#RFC7231"><b>10.1</b></a>, <a href="#rfc.xref.RFC7231.10">B</a><ul><li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.3">4</a>, <a href="#rfc.xref.RFC7231.7">4.4</a></li><li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.2">2</a></li><li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.5">4.2.2</a></li><li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.8">5.3</a>, <a href="#rfc.xref.RFC7231.10">B</a></li><li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.6">4.2.3</a></li><li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.4">4.1</a></li></ul></li><li><em>RFC7232</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">4.2.2</a>, <a href="#rfc.xref.RFC7232.2">4.3</a>, <a href="#rfc.xref.RFC7232.3">4.3.1</a>, <a href="#rfc.xref.RFC7232.4">4.3.1</a>, <a href="#rfc.xref.RFC7232.5">4.3.2</a>, <a href="#rfc.xref.RFC7232.6">4.3.2</a>, <a href="#rfc.xref.RFC7232.7">4.3.2</a>, <a href="#rfc.xref.RFC7232.8">4.3.4</a>, <a href="#RFC7232"><b>10.1</b></a><ul><li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.8">4.3.4</a></li><li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.1">4.2.2</a>, <a href="#rfc.xref.RFC7232.3">4.3.1</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.4">4.3.1</a></li><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.6">4.3.2</a></li><li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.7">4.3.2</a></li><li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7232.5">4.3.2</a></li></ul></li><li><em>RFC7233</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.1">3.1</a>, <a href="#rfc.xref.RFC7233.2">3.3</a>, <a href="#rfc.xref.RFC7233.3">3.3</a>, <a href="#rfc.xref.RFC7233.4">4.3.2</a>, <a href="#rfc.xref.RFC7233.5">4.3.2</a>, <a href="#RFC7233"><b>10.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.5">4.3.2</a></li><li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7233.3">3.3</a></li></ul></li><li><em>RFC7235</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">3</a>, <a href="#rfc.xref.RFC7235.2">3.2</a>, <a href="#RFC7235"><b>10.1</b></a><ul><li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7235.1">3</a>, <a href="#rfc.xref.RFC7235.2">3.2</a></li></ul></li></ul></li><li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul><li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>5.2.2.9</b></a></li><li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1</a></li><li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.2</a></li><li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.3.4</a></li></ul></li><li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul><li>Transformation Applied (warn-text)&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>5.5.6</b></a>, <a href="#rfc.xref.warn.214.1">7.2.2</a></li></ul></li><li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul><li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.3.1</a></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.3.4</a>, <a href="#rfc.xref.header.warning.3">4.3.5</a>, <a href="#rfc.iref.w.1"><b>5.5</b></a>, <a href="#rfc.xref.header.warning.4">7.3</a>, <a href="#rfc.xref.header.warning.5">A</a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
    701701      (editor)
    702702    <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p><p><b>Mark Nottingham</b>
  • specs/rfc7235.html

    r2725 r2726  
    502502    }
    503503}
    504 </style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Access Authentication Framework" href="#rfc.section.2"><link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"><link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Changes from RFCs 2616 and 2617" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7234.html" rel="prev"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7235.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7235"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7235"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.638, 2014/05/31 12:29:37, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP authentication"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7235"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."></head><body onload="getMeta(7235,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7235</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2617">2617</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Authentication</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7235">http://www.rfc-editor.org/info/rfc7235</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.401">401 Unauthorized</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFCs 2616 and 2617</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</p><p id="rfc.section.1.p.2">The IANA Authentication Scheme Registry (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;5.1</a>) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="access.authentication.framework"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a></h1><div id="challenge.and.response"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#challenge.and.response">Challenge and Response</a></h2><p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.</p><p id="rfc.section.2.1.p.2">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  auth-scheme    = <a href="#imported.abnf" class="smpl">token</a>
     504</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyrightnotice"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Access Authentication Framework" href="#rfc.section.2"><link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"><link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4"><link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"><link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"><link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"><link rel="Chapter" href="#rfc.section.8" title="8 References"><link rel="Appendix" title="A Changes from RFCs 2616 and 2617" href="#rfc.section.A"><link rel="Appendix" title="B Imported ABNF" href="#rfc.section.B"><link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"><link href="rfc7234.html" rel="prev"><link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc7235.txt"><link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc7235"><link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc7235"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 6.5.5 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="Hypertext Transfer Protocol, HTTP, HTTP authentication"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="Fielding, R."><meta name="dct.creator" content="Reschke, J. F."><meta name="dct.identifier" content="urn:ietf:rfc:7235"><meta name="dct.issued" scheme="ISO8601" content="2014-06"><meta name="dct.replaces" content="urn:ietf:rfc:2616"><meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."><meta name="dct.isPartOf" content="urn:issn:2070-1721"><meta name="description" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."></head><body onload="getMeta(7235,&#34;rfc.meta&#34;);"><table class="header"><tbody><tr><td class="left">Internet Engineering Task Force (IETF)</td><td class="right">R. Fielding, Editor</td></tr><tr><td class="left">Request for Comments: 7235</td><td class="right">Adobe</td></tr><tr><td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a></td><td class="right">J. Reschke, Editor</td></tr><tr><td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2617">2617</a></td><td class="right">greenbytes</td></tr><tr><td class="left">Category: Standards Track</td><td class="right">June 2014</td></tr><tr><td class="left">ISSN: 2070-1721</td><td class="right"></td></tr></tbody></table><p class="title">Hypertext Transfer Protocol (HTTP/1.1): Authentication</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1><p>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.</p><div id="rfc.meta" style="float: right; border: 1px solid black; margin: 2em; padding: 1em; display: none;"></div><div id="rfc.status"><h1><a href="#rfc.status">Status of This Memo</a></h1><p>This is an Internet Standards Track document.</p><p>This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p><p>Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <a href="http://www.rfc-editor.org/info/rfc7235">http://www.rfc-editor.org/info/rfc7235</a>.</p></div><div id="rfc.copyrightnotice"><h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright &copy; 2014 IETF Trust and the persons identified as the document authors. All rights reserved.</p><p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p><p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.</p></div><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul><li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li><li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a><ul><li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li><li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li></ul></li><li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.definitions">Status Code Definitions</a><ul><li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#status.401">401 Unauthorized</a></li><li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></li></ul></li><li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul><li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li><li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li><li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li><li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li></ul></li><li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul><li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul><li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry.procedure">Procedure</a></li><li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li></ul></li><li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li><li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li></ul></li><li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul><li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li><li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li><li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li></ul></li><li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li><li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul><li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFCs 2616 and 2617</a></li><li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#imported.abnf">Imported ABNF</a></li><li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li><li><a href="#rfc.index">Index</a></li><li><a href="#rfc.authors">Authors' Addresses</a></li></ul><div id="introduction"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1><p id="rfc.section.1.p.1">HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.</p><p id="rfc.section.1.p.2">The IANA Authentication Scheme Registry (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;5.1</a>) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.</p><div id="conformance"><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#conformance">Conformance and Error Handling</a></h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.</p><p id="rfc.section.1.1.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="rfc7230.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.</p></div><div id="notation"><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list extension, defined in <a href="rfc7230.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected grammar with all list operators expanded to standard ABNF notation.</p></div></div><div id="access.authentication.framework"><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a></h1><div id="challenge.and.response"><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#challenge.and.response">Challenge and Response</a></h2><p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.</p><p id="rfc.section.2.1.p.2">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  auth-scheme    = <a href="#imported.abnf" class="smpl">token</a>
    505505 
    506506  auth-param     = <a href="#imported.abnf" class="smpl">token</a> <a href="#imported.abnf" class="smpl">BWS</a> "=" <a href="#imported.abnf" class="smpl">BWS</a> ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> )
     
    510510</pre><p id="rfc.section.2.1.p.4">The token68 syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>).</p><p id="rfc.section.2.1.p.5">A <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent, including a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.</p><p id="rfc.section.2.1.p.6">A <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client, including a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource.</p><div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#challenge.and.response" class="smpl">challenge</a>   = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
    511511</pre><div class="note" id="rfc.section.2.1.p.8"><p><b>Note:</b> Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported schemes (such as "basic") first. </p> </div><p id="rfc.section.2.1.p.9">A user agent that wishes to authenticate itself with an origin server &#8212; usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> &#8212; can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.</p><p id="rfc.section.2.1.p.10">A client that wishes to authenticate itself with a proxy &#8212; usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> &#8212; can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request.</p><p id="rfc.section.2.1.p.11">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in <a href="#confidentiality.of.credentials" title="Confidentiality of Credentials">Section&nbsp;6.1</a>.</p><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
    512 </pre><p id="rfc.section.2.1.p.13">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.</p><p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication <em class="bcp14">SHOULD</em> generate a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with at least one (possibly new) challenge applicable to the proxy.</p><p id="rfc.section.2.1.p.15">A server that receives valid credentials that are not adequate to gain access ought to respond with the <a href="rfc7231.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="rfc7231.html#status.403" title="403 Forbidden">Section 6.5.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>).</p><p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.</p></div><div id="protection.space"><div id="rfc.iref.p.1"></div><div id="rfc.iref.r.1"></div><div id="rfc.iref.c.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#protection.space">Protection Space (Realm)</a></h2><p id="rfc.section.2.2.p.1">The "<dfn>realm</dfn>" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.</p><p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <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>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.</p><p id="rfc.section.2.2.p.3">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent <em class="bcp14">MAY</em> reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout). Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.</p><p id="rfc.section.2.2.p.4">For historical reasons, a sender <em class="bcp14">MUST</em> only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.</p></div></div><div id="status.code.definitions"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#status.code.definitions">Status Code Definitions</a></h1><div id="status.401"><div id="rfc.iref.8"></div><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#status.401">401 Unauthorized</a></h2><p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.1</a>) containing at least one challenge applicable to the target resource.</p><p id="rfc.section.3.1.p.2">If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.2</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.</p></div><div id="status.407"><div id="rfc.iref.8"></div><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></h2><p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.3</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.4</a>).</p></div></div><div id="header.field.definitions"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#header.field.definitions">Header Field Definitions</a></h1><p id="rfc.section.4.p.1">This section defines the syntax and semantics of header fields related to the HTTP authentication framework.</p><div id="header.www-authenticate"><div id="rfc.iref.w.1"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></h2><p id="rfc.section.4.1.p.1">The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.</p><div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
     512</pre><p id="rfc.section.2.1.p.13">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.</p><p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication <em class="bcp14">SHOULD</em> generate a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with at least one (possibly new) challenge applicable to the proxy.</p><p id="rfc.section.2.1.p.15">A server that receives valid credentials that are not adequate to gain access ought to respond with the <a href="rfc7231.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="rfc7231.html#status.403" title="403 Forbidden">Section 6.5.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>).</p><p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.</p></div><div id="protection.space"><div id="rfc.iref.p.1"></div><div id="rfc.iref.r.1"></div><div id="rfc.iref.c.1"></div><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#protection.space">Protection Space (Realm)</a></h2><p id="rfc.section.2.2.p.1">The "<dfn>realm</dfn>" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.</p><p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <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>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.</p><p id="rfc.section.2.2.p.3">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent <em class="bcp14">MAY</em> reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout). Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.</p><p id="rfc.section.2.2.p.4">For historical reasons, a sender <em class="bcp14">MUST</em> only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.</p></div></div><div id="status.code.definitions"><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#status.code.definitions">Status Code Definitions</a></h1><div id="status.401"><div id="rfc.iref.4.1"></div><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#status.401">401 Unauthorized</a></h2><p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.1</a>) containing at least one challenge applicable to the target resource.</p><p id="rfc.section.3.1.p.2">If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.2</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.</p></div><div id="status.407"><div id="rfc.iref.4.2"></div><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></h2><p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.3</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.4</a>).</p></div></div><div id="header.field.definitions"><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#header.field.definitions">Header Field Definitions</a></h1><p id="rfc.section.4.p.1">This section defines the syntax and semantics of header fields related to the HTTP authentication framework.</p><div id="header.www-authenticate"><div id="rfc.iref.w.1"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></h2><p id="rfc.section.4.1.p.1">The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.</p><div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    513513</pre><p id="rfc.section.4.1.p.3">A server generating a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response <em class="bcp14">MUST</em> send a WWW-Authenticate header field containing at least one challenge. A server <em class="bcp14">MAY</em> generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.</p><p id="rfc.section.4.1.p.4">A proxy forwarding a response <em class="bcp14">MUST NOT</em> modify any <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> fields in that response.</p><p id="rfc.section.4.1.p.5">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.</p><div id="rfc.figure.u.5"></div><p>For instance:</p><pre class="text">  WWW-Authenticate: Newauth realm="apps", type=1,
    514514                    title="Login to \"apps\"", Basic realm="simple"
     
    546546<a href="#challenge.and.response" class="smpl">token68</a> = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
    547547 *"="
    548 </pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>401 Unauthorized (status code)&nbsp;&nbsp;<a href="#rfc.iref.8"><b>3.1</b></a>, <a href="#rfc.xref.status.401.1">5.2</a></li><li>407 Proxy Authentication Required (status code)&nbsp;&nbsp;<a href="#rfc.iref.8"><b>3.2</b></a>, <a href="#rfc.xref.status.407.1">5.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">3.1</a>, <a href="#rfc.iref.a.1"><b>4.2</b></a>, <a href="#rfc.xref.header.authorization.2">5.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">5.3</a>, <a href="#BCP90"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Canonical Root URI&nbsp;&nbsp;<a href="#rfc.iref.c.1">2.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>auth-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.1</b></a></li><li><tt>auth-scheme</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2.1</b></a></li><li><tt>Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>4.2</b></a></li><li><tt>challenge</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>2.1</b></a></li><li><tt>credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.1</b></a></li><li><tt>Proxy-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>4.3</b></a></li><li><tt>Proxy-Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>4.4</b></a></li><li><tt>token68</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>2.1</b></a></li><li><tt>WWW-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>4.1</b></a></li></ul></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li><em>OWASP</em>&nbsp;&nbsp;<a href="#rfc.xref.OWASP.1">6</a>, <a href="#OWASP"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>Protection Space&nbsp;&nbsp;<a href="#rfc.iref.p.1">2.2</a></li><li>Proxy-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a href="#rfc.iref.p.2"><b>4.3</b></a>, <a href="#rfc.xref.header.proxy-authenticate.2">5.3</a></li><li>Proxy-Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a href="#rfc.iref.p.3"><b>4.4</b></a>, <a href="#rfc.xref.header.proxy-authorization.2">5.3</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Realm&nbsp;&nbsp;<a href="#rfc.iref.r.1">2.2</a></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>8.2</b></a></li><li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">1</a>, <a href="#rfc.xref.RFC2617.2">1</a>, <a href="#rfc.xref.RFC2617.3">7</a>, <a href="#rfc.xref.RFC2617.4">7</a>, <a href="#RFC2617"><b>8.2</b></a><ul><li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.4">7</a></li></ul></li><li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#RFC3986"><b>8.2</b></a></li><li><em>RFC4648</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4648.1">2.1</a>, <a href="#RFC4648"><b>8.2</b></a></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>8.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">6.1</a>, <a href="#RFC5246"><b>8.2</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2.2</a>, <a href="#rfc.xref.RFC7230.5">4.3</a>, <a href="#rfc.xref.RFC7230.6">5.1.2</a>, <a href="#rfc.xref.RFC7230.7">6</a>, <a href="#rfc.xref.RFC7230.8">7</a>, <a href="#RFC7230"><b>8.1</b></a>, <a href="#rfc.xref.RFC7230.9">B</a>, <a href="#rfc.xref.RFC7230.10">B</a>, <a href="#rfc.xref.RFC7230.11">B</a>, <a href="#rfc.xref.RFC7230.12">B</a>, <a href="#rfc.xref.RFC7230.13">B</a>, <a href="#rfc.xref.RFC7230.14">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.14">C</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">5.1.2</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">B</a>, <a href="#rfc.xref.RFC7230.11">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.12">B</a>, <a href="#rfc.xref.RFC7230.13">B</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2.2</a>, <a href="#rfc.xref.RFC7230.5">4.3</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">7</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a>, <a href="#rfc.xref.RFC7231.2">6</a>, <a href="#RFC7231"><b>8.1</b></a><ul><li><em>Section 6.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2</a>, <a href="#rfc.xref.RFC7234.2">5.1.2</a>, <a href="#rfc.xref.RFC7234.3">5.1.2</a>, <a href="#RFC7234"><b>8.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2</a></li><li><em>Section 5.2.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.3">5.1.2</a></li><li><em>Section 5.2.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.2">5.1.2</a></li></ul></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li>WWW-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a href="#rfc.iref.w.1"><b>4.1</b></a>, <a href="#rfc.xref.header.www-authenticate.2">4.3</a>, <a href="#rfc.xref.header.www-authenticate.3">5.3</a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
     548</pre></div><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.W">W</a> </p><div class="print2col"><ul class="ind"><li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul><li>401 Unauthorized (status code)&nbsp;&nbsp;<a href="#rfc.iref.4.1"><b>3.1</b></a>, <a href="#rfc.xref.status.401.1">5.2</a></li><li>407 Proxy Authentication Required (status code)&nbsp;&nbsp;<a href="#rfc.iref.4.2"><b>3.2</b></a>, <a href="#rfc.xref.status.407.1">5.2</a></li></ul></li><li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul><li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">3.1</a>, <a href="#rfc.iref.a.1"><b>4.2</b></a>, <a href="#rfc.xref.header.authorization.2">5.3</a></li></ul></li><li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul><li><em>BCP90</em>&nbsp;&nbsp;<a href="#rfc.xref.BCP90.1">5.3</a>, <a href="#BCP90"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul><li>Canonical Root URI&nbsp;&nbsp;<a href="#rfc.iref.c.1">2.2</a></li></ul></li><li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul><li><tt>Grammar</tt>&nbsp;&nbsp;<ul><li><tt>auth-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.1</b></a></li><li><tt>auth-scheme</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2.1</b></a></li><li><tt>Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>4.2</b></a></li><li><tt>challenge</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>2.1</b></a></li><li><tt>credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.1</b></a></li><li><tt>Proxy-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>4.3</b></a></li><li><tt>Proxy-Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>4.4</b></a></li><li><tt>token68</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>2.1</b></a></li><li><tt>WWW-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>4.1</b></a></li></ul></li></ul></li><li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul><li><em>OWASP</em>&nbsp;&nbsp;<a href="#rfc.xref.OWASP.1">6</a>, <a href="#OWASP"><b>8.2</b></a></li></ul></li><li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul><li>Protection Space&nbsp;&nbsp;<a href="#rfc.iref.p.1">2.2</a></li><li>Proxy-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a href="#rfc.iref.p.2"><b>4.3</b></a>, <a href="#rfc.xref.header.proxy-authenticate.2">5.3</a></li><li>Proxy-Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a href="#rfc.iref.p.3"><b>4.4</b></a>, <a href="#rfc.xref.header.proxy-authorization.2">5.3</a></li></ul></li><li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul><li>Realm&nbsp;&nbsp;<a href="#rfc.iref.r.1">2.2</a></li><li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li><li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>8.2</b></a></li><li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">1</a>, <a href="#rfc.xref.RFC2617.2">1</a>, <a href="#rfc.xref.RFC2617.3">7</a>, <a href="#rfc.xref.RFC2617.4">7</a>, <a href="#RFC2617"><b>8.2</b></a><ul><li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.4">7</a></li></ul></li><li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#RFC3986"><b>8.2</b></a></li><li><em>RFC4648</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4648.1">2.1</a>, <a href="#RFC4648"><b>8.2</b></a></li><li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul><li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">5.1.1</a></li></ul></li><li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>8.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul><li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li></ul></li><li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">6.1</a>, <a href="#RFC5246"><b>8.2</b></a></li><li><em>RFC7230</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.1">1</a>, <a href="#rfc.xref.RFC7230.2">1.1</a>, <a href="#rfc.xref.RFC7230.3">1.2</a>, <a href="#rfc.xref.RFC7230.4">2.2</a>, <a href="#rfc.xref.RFC7230.5">4.3</a>, <a href="#rfc.xref.RFC7230.6">5.1.2</a>, <a href="#rfc.xref.RFC7230.7">6</a>, <a href="#rfc.xref.RFC7230.8">7</a>, <a href="#RFC7230"><b>8.1</b></a>, <a href="#rfc.xref.RFC7230.9">B</a>, <a href="#rfc.xref.RFC7230.10">B</a>, <a href="#rfc.xref.RFC7230.11">B</a>, <a href="#rfc.xref.RFC7230.12">B</a>, <a href="#rfc.xref.RFC7230.13">B</a>, <a href="#rfc.xref.RFC7230.14">C</a><ul><li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.14">C</a></li><li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.6">5.1.2</a></li><li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.2">1.1</a></li><li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.10">B</a>, <a href="#rfc.xref.RFC7230.11">B</a></li><li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.12">B</a>, <a href="#rfc.xref.RFC7230.13">B</a></li><li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.4">2.2</a>, <a href="#rfc.xref.RFC7230.5">4.3</a></li><li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.3">1.2</a></li><li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7230.8">7</a></li></ul></li><li><em>RFC7231</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a>, <a href="#rfc.xref.RFC7231.2">6</a>, <a href="#RFC7231"><b>8.1</b></a><ul><li><em>Section 6.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7231.1">2.1</a></li></ul></li><li><em>RFC7234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2</a>, <a href="#rfc.xref.RFC7234.2">5.1.2</a>, <a href="#rfc.xref.RFC7234.3">5.1.2</a>, <a href="#RFC7234"><b>8.1</b></a><ul><li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.1">4.2</a></li><li><em>Section 5.2.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.3">5.1.2</a></li><li><em>Section 5.2.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC7234.2">5.1.2</a></li></ul></li></ul></li><li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul><li>WWW-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a href="#rfc.iref.w.1"><b>4.1</b></a>, <a href="#rfc.xref.header.www-authenticate.2">4.3</a>, <a href="#rfc.xref.header.www-authenticate.3">5.3</a></li></ul></li></ul></div><div class="avoidbreak"><h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1><p><b>Roy T. Fielding</b>
    549549      (editor)
    550550    <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p><p><b>Julian F. Reschke</b>
  • specs/rfc7236.html

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

    r2725