Changeset 2737 for specs/rfc7230.html


Ignore:
Timestamp:
Apr 10, 2015, 3:23:33 AM (5 years ago)
Author:
julian.reschke@…
Message:

update specs

File:
1 edited

Legend:

Unmodified
Added
Removed
  • specs/rfc7230.html

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