You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/09 02:42:51 UTC
svn commit: r583022 -
/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
Author: fielding
Date: Mon Oct 8 17:42:49 2007
New Revision: 583022
URL: http://svn.apache.org/viewvc?rev=583022&view=rev
Log:
HTTP/1.1, part 1: Messaging
Added:
labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (with props)
Added: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html?rev=583022&view=auto
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html (added)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html Mon Oct 8 17:42:49 2007
@@ -0,0 +1,506 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html lang="en"><head profile="http://www.w3.org/2006/03/hcard"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>HTTP/1.1 part 1: URIs, Connections, and Message Framing</title><style type="text/css" title="Xml2Rfc (sans serif)">
+a {
+ text-decoration: none;
+}
+a.smpl {
+ color: black;
+}
+a:hover {
+ text-decoration: underline;
+}
+a:active {
+ text-decoration: underline;
+}
+address {
+ margin-top: 1em;
+ margin-left: 2em;
+ font-style: normal;
+}
+body {
+ color: black;
+ font-family: verdana, helvetica, arial, sans-serif;
+ font-size: 10pt;
+}
+cite {
+ font-style: normal;
+}
+dd {
+ margin-right: 2em;
+}
+dl {
+ margin-left: 2em;
+}
+
+dl.empty dd {
+ margin-top: .5em;
+}
+dl p {
+ margin-left: 0em;
+}
+dt {
+ margin-top: .5em;
+}
+h1 {
+ font-size: 14pt;
+ line-height: 21pt;
+ page-break-after: avoid;
+}
+h1.np {
+ page-break-before: always;
+}
+h1 a {
+ color: #333333;
+}
+h2 {
+ font-size: 12pt;
+ line-height: 15pt;
+ page-break-after: avoid;
+}
+h2 a {
+ color: black;
+}
+h3 {
+ font-size: 10pt;
+ page-break-after: avoid;
+}
+h3 a {
+ color: black;
+}
+h4 {
+ font-size: 10pt;
+ page-break-after: avoid;
+}
+h4 a {
+ color: black;
+}
+h5 {
+ font-size: 10pt;
+ page-break-after: avoid;
+}
+h5 a {
+ color: black;
+}
+img {
+ margin-left: 3em;
+}
+li {
+ margin-left: 2em;
+ margin-right: 2em;
+}
+ol {
+ margin-left: 2em;
+ margin-right: 2em;
+}
+ol p {
+ margin-left: 0em;
+}
+p {
+ margin-left: 2em;
+ margin-right: 2em;
+}
+pre {
+ margin-left: 3em;
+ background-color: lightyellow;
+ padding: .25em;
+}
+pre.text2 {
+ border-style: dotted;
+ border-width: 1px;
+ background-color: #f0f0f0;
+ width: 69em;
+}
+pre.inline {
+ background-color: white;
+ padding: 0em;
+}
+pre.text {
+ border-style: dotted;
+ border-width: 1px;
+ background-color: #f8f8f8;
+ width: 69em;
+}
+pre.drawing {
+ border-style: solid;
+ border-width: 1px;
+ background-color: #f8f8f8;
+ padding: 2em;
+}
+table {
+ margin-left: 2em;
+}
+table.header {
+ width: 95%;
+ font-size: 10pt;
+ color: white;
+}
+td.top {
+ vertical-align: top;
+}
+td.topnowrap {
+ vertical-align: top;
+ white-space: nowrap;
+}
+td.header {
+ background-color: gray;
+ width: 50%;
+}
+td.reference {
+ vertical-align: top;
+ white-space: nowrap;
+ padding-right: 1em;
+}
+thead {
+ display:table-header-group;
+}
+ul.toc {
+ list-style: none;
+ margin-left: 1.5em;
+ margin-right: 0em;
+ padding-left: 0em;
+}
+li.tocline0 {
+ line-height: 150%;
+ font-weight: bold;
+ font-size: 10pt;
+ margin-left: 0em;
+ margin-right: 0em;
+}
+li.tocline1 {
+ line-height: normal;
+ font-weight: normal;
+ font-size: 9pt;
+ margin-left: 0em;
+ margin-right: 0em;
+}
+li.tocline2 {
+ font-size: 0pt;
+}
+ul p {
+ margin-left: 0em;
+}
+ul.ind {
+ list-style: none;
+ margin-left: 1.5em;
+ margin-right: 0em;
+ padding-left: 0em;
+}
+li.indline0 {
+ font-weight: bold;
+ line-height: 200%;
+ margin-left: 0em;
+ margin-right: 0em;
+}
+li.indline1 {
+ font-weight: normal;
+ line-height: 150%;
+ margin-left: 0em;
+ margin-right: 0em;
+}
+.bcp14 {
+ font-style: normal;
+ text-transform: lowercase;
+ font-variant: small-caps;
+}
+.comment {
+ background-color: yellow;
+}
+.center {
+ text-align: center;
+}
+.error {
+ color: red;
+ font-style: italic;
+ font-weight: bold;
+}
+.figure {
+ font-weight: bold;
+ text-align: center;
+ font-size: 9pt;
+}
+.filename {
+ color: #333333;
+ font-weight: bold;
+ font-size: 12pt;
+ line-height: 21pt;
+ text-align: center;
+}
+.fn {
+ font-weight: bold;
+}
+.hidden {
+ display: none;
+}
+.left {
+ text-align: left;
+}
+.right {
+ text-align: right;
+}
+.title {
+ color: #990000;
+ font-size: 18pt;
+ line-height: 18pt;
+ font-weight: bold;
+ text-align: center;
+ margin-top: 36pt;
+}
+.vcardline {
+ display: block;
+}
+.warning {
+ font-size: 14pt;
+ background-color: yellow;
+}
+
+
+@media print {
+ .noprint {
+ display: none;
+ }
+
+ a {
+ color: black;
+ text-decoration: none;
+ }
+
+ table.header {
+ width: 90%;
+ }
+
+ td.header {
+ width: 50%;
+ color: black;
+ background-color: white;
+ vertical-align: top;
+ font-size: 12pt;
+ }
+
+ ul.toc a::after {
+ content: leader('.') target-counter(attr(href), page);
+ }
+
+ a.iref {
+ content: target-counter(attr(href), page);
+ }
+
+ .print2col {
+ column-count: 2;
+ -moz-column-count: 2;
+ column-fill: auto;
+ }
+}
+
+@page {
+ @top-left {
+ content: "INTERNET DRAFT";
+ }
+ @top-right {
+ content: "September 2007";
+ }
+ @top-center {
+ content: "HTTP/1.1";
+ }
+ @bottom-left {
+ content: "Fielding, et al.";
+ }
+ @bottom-center {
+ content: "Standards Track";
+ }
+ @bottom-right {
+ content: "[Page " counter(page) "]";
+ }
+}
+
+@page:first {
+ @top-left {
+ content: normal;
+ }
+ @top-right {
+ content: normal;
+ }
+ @top-center {
+ content: normal;
+ }
+}
+</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"><link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3"><link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4"><link rel="Chapter" title="5 Connections" href="#rfc.section.5"><link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6"><link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"><link rel="Chapter" href="#rfc.section.9" title="9 References"><link rel="Appendix" title="A Internet Media Type message/http and application/http" href="#rfc.section.A"><link rel="Appendix" title="B Tolerant Applications" href="#rfc.section.B
"><link rel="Appendix" title="C Conversion of Date Formats" href="#rfc.section.C"><link rel="Appendix" title="D Compatibility with Previous Versions" href="#rfc.section.D"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.346, 2007/10/07 13:54:24, XSLT vendor: SAXON 8.5.1 from Saxonica http://www.saxonica.com/"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><meta name="DC.Creator" content="Fielding, R."><meta name="DC.Creator" content="Gettys, J."><meta name="DC.Creator" content="Mogul, J."><meta name="DC.Creator" content="Frystyk, H."><meta name="DC.Creator" content="Masinter, L."><meta name="DC.Creator" content="Leach, P."><meta name="DC.Creator" content="Berners-Lee, T."><meta name="DC.Identifier" content="urn:ietf:id:draft-fielding-http-p1-messaging-00"><meta name="DC.Date.Issued" scheme="ISO8601" content="2007-09"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068"><meta name="DC.Relation.Replaces" content
="urn:ietf:rfc:2616"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2617"><meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."></head><body><table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"><tr><td class="header left">Network Working Group</td><td c
lass="header right">R. Fielding</td></tr><tr><td class="header left">Internet Draft</td><td class="header right">UC Irvine</td></tr><tr><td class="header left">
+ <draft-fielding-http-p1-messaging-00>
+ </td><td class="header right">J. Gettys</td></tr><tr><td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a>,
+ <a href="http://tools.ietf.org/html/rfc2616">2616</a>,
+ <a href="http://tools.ietf.org/html/rfc2617">2617</a> (if approved)</td><td class="header right">Compaq/W3C</td></tr><tr><td class="header left">Intended status: Standards Track</td><td class="header right">J. Mogul</td></tr><tr><td class="header left">Expires: March 2008</td><td class="header right">Compaq</td></tr><tr><td class="header left"></td><td class="header right">H. Frystyk</td></tr><tr><td class="header left"></td><td class="header right">W3C/MIT</td></tr><tr><td class="header left"></td><td class="header right">L. Masinter</td></tr><tr><td class="header left"></td><td class="header right">Xerox</td></tr><tr><td class="header left"></td><td class="header right">P. Leach</td></tr><tr><td class="header left"></td><td class="header right">Microsoft</td></tr><tr><td class="header left"></td><td class="header right">T. Berners-Lee</td></tr><tr><td class="header left"></td><td class="header right">W3C/MIT</td></tr><tr><td class="header left"></td><td class="header
right">September 2007</td></tr></table><p class="title">HTTP/1.1 part 1: URIs, Connections, and Message Framing<br><span class="filename">draft-fielding-http-p1-messaging-00</span></p><h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.</p><p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.</p><p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other than as “work in progress”.</p><p>The list of current Internet-Drafts can be accessed at <<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>>.</p><p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>.</p><p>This Internet-Draft will expire in March 2008.</p><h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright © The IETF Trust (2007). All Rights Reserved.</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the eight-part specification that defines
the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.</p> <hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li class="tocline0">1. <a href="#rfc.section.1">Introduction</a><ul class="toc"><li class="tocline1">1.1 <a href="#rfc.section.1.1">Purpose</a></li><li class="tocline1">1.2 <a href="#rfc.section.1.2">Requirements</a></li><li class="tocline1">1.3 <a href="#rfc.section.1.3">Terminology</a></li><li class="tocline1">1.4 <a href="#rfc.section.1.4">Overall Operation</a></li></ul></li><li class="tocline0">2.
<a href="#rfc.section.2">Notational Conventions and Generic Grammar</a><ul class="toc"><li class="tocline1">2.1 <a href="#rfc.section.2.1">Augmented BNF</a></li><li class="tocline1">2.2 <a href="#basic.rules">Basic Rules</a></li></ul></li><li class="tocline0">3. <a href="#rfc.section.3">Protocol Parameters</a><ul class="toc"><li class="tocline1">3.1 <a href="#http.version">HTTP Version</a></li><li class="tocline1">3.2 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc"><li class="tocline1">3.2.1 <a href="#general.syntax">General Syntax</a></li><li class="tocline1">3.2.2 <a href="#http.url">http URL</a></li><li class="tocline1">3.2.3 <a href="#uri.comparison">URI Comparison</a></li></ul></li><li class="tocline1">3.3 <a href="#rfc.section.3.3">Date/Time Formats</a><ul class="toc"><li class="tocline1">3.3
.1 <a href="#full.date">Full Date</a></li></ul></li><li class="tocline1">3.4 <a href="#transfer.codings">Transfer Codings</a><ul class="toc"><li class="tocline1">3.4.1 <a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li></ul></li></ul></li><li class="tocline0">4. <a href="#httpmessage">HTTP Message</a><ul class="toc"><li class="tocline1">4.1 <a href="#rfc.section.4.1">Message Types</a></li><li class="tocline1">4.2 <a href="#message.headers">Message Headers</a></li><li class="tocline1">4.3 <a href="#message.body">Message Body</a></li><li class="tocline1">4.4 <a href="#message.length">Message Length</a></li><li class="tocline1">4.5 <a href="#general.header.fields">General Header Fields</a></li></ul></li><li class="tocline0">5. <a href="#rfc.section.5">Connections</a><ul class="toc"><li class="
tocline1">5.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc"><li class="tocline1">5.1.1 <a href="#rfc.section.5.1.1">Purpose</a></li><li class="tocline1">5.1.2 <a href="#rfc.section.5.1.2">Overall Operation</a><ul class="toc"><li class="tocline1">5.1.2.1 <a href="#rfc.section.5.1.2.1">Negotiation</a></li><li class="tocline1">5.1.2.2 <a href="#pipelining">Pipelining</a></li></ul></li><li class="tocline1">5.1.3 <a href="#rfc.section.5.1.3">Proxy Servers</a></li><li class="tocline1">5.1.4 <a href="#rfc.section.5.1.4">Practical Considerations</a></li></ul></li><li class="tocline1">5.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc"><li class="tocline1">5.2.1 <a href="#rfc.section.5.2.1">Persistent Connections and Flow Control</a></li><li class="toclin
e1">5.2.2 <a href="#rfc.section.5.2.2">Monitoring Connections for Error Status Messages</a></li><li class="tocline1">5.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li><li class="tocline1">5.2.4 <a href="#rfc.section.5.2.4">Client Behavior if Server Prematurely Closes Connection</a></li></ul></li></ul></li><li class="tocline0">6. <a href="#rfc.section.6">Header Field Definitions</a><ul class="toc"><li class="tocline1">6.1 <a href="#header.connection">Connection</a></li><li class="tocline1">6.2 <a href="#header.content-length">Content-Length</a></li><li class="tocline1">6.3 <a href="#header.date">Date</a><ul class="toc"><li class="tocline1">6.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li></ul></li><li class="tocline1">6.4 <a href="#header.te">TE</a></li
><li class="tocline1">6.5 <a href="#header.trailer">Trailer</a></li><li class="tocline1">6.6 <a href="#header.transfer-encoding">Transfer-Encoding</a></li><li class="tocline1">6.7 <a href="#header.upgrade">Upgrade</a></li><li class="tocline1">6.8 <a href="#header.via">Via</a></li></ul></li><li class="tocline0">7. <a href="#rfc.section.7">Security Considerations</a><ul class="toc"><li class="tocline1">7.1 <a href="#rfc.section.7.1">Personal Information</a></li><li class="tocline1">7.2 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li><li class="tocline1">7.3 <a href="#rfc.section.7.3">Attacks Based On File and Path Names</a></li><li class="tocline1">7.4 <a href="#rfc.section.7.4">DNS Spoofing</a></li><li class="tocline1">7.5 <a href="#rfc.section.7.5">Proxies and Caching</a></
li><li class="tocline1">7.6 <a href="#rfc.section.7.6">Denial of Service Attacks on Proxies</a></li></ul></li><li class="tocline0">8. <a href="#rfc.section.8">Acknowledgments</a></li><li class="tocline0">9. <a href="#rfc.references">References</a></li><li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li><li class="tocline0">A. <a href="#internet.media.type.http">Internet Media Type message/http and application/http</a></li><li class="tocline0">B. <a href="#tolerant.applications">Tolerant Applications</a></li><li class="tocline0">C. <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li class="tocline0">D. <a href="#rfc.section.D">Compatibility with Previous Versions</a><ul class="toc"><li class="tocline1">D.1 <a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Pers
istent Connections</a></li><li class="tocline1">D.2 <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li></ul></li><li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li><li class="tocline0"><a href="#rfc.index">Index</a></li></ul><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction</h1><p id="rfc.section.1.p.1">This document will define aspects of HTTP related to overall network operation, message framing, interaction with transport protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[30]</cite></a> and <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[31]</cite></a>.</p><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> Purpose</h2><p id="rfc.section.1.1.p.1">The
Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[4]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order f
or two communicating applications to determine each other's true capabilities.</p><p id="rfc.section.1.1.p.2">This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its features.</p><p id="rfc.section.1.1.p.3">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[32]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[2]
</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[17]</cite></a>, for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by Internet mail <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a> as defined by 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">[5]</cite></a>.</p><p id="rfc.section.1.1.p.4">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC
821.1"><cite title="Simple Mail Transfer Protocol">[13]</cite></a>, NNTP <a href="#RFC977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[11]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[15]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[1]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[8]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.</p><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> Requirements</h2><p id="rfc.section.1.2.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 RF
C 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[26]</cite></a>.</p><p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."</p><h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> Terminology</h2><p id="rfc.section.1.3.p.1">This specification uses a number of terms to refer to the roles played by participants
in, and objects of, the HTTP communication.</p><p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span> <dfn>connection</dfn> </p><dl class="empty"><dd>A transport layer virtual circuit established between two programs for the purpose of communication.</dd></dl><p id="rfc.section.1.3.p.3"> <span id="rfc.iref.m.1"></span> <dfn>message</dfn> </p><dl class="empty"><dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#httpmessage" title="HTTP Message">Section 4</a> and transmitted via the connection.</dd></dl><p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span> <dfn>request</dfn> </p><dl class="empty"><dd>An HTTP request message, as defined in [Part 2].</dd></dl><p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span> <dfn>response</dfn> </p><dl class="empty"><dd>An HTTP response message, as defined in [Part 2].</dd></dl><p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></
span> <dfn>resource</dfn> </p><dl class="empty"><dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.</dd></dl><p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span> <dfn>entity</dfn> </p><dl class="empty"><dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in [Part 3].</dd></dl><p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span> <dfn>representation</dfn> </p><dl class="empty"><dd>An entity included with a response that is subject to content negotiation, as described in [Part 3]. There may exist multiple representations associated with a particular response status.<
/dd></dl><p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span> <dfn>content negotiation</dfn> </p><dl class="empty"><dd>The mechanism for selecting the appropriate representation when servicing a request, as described in [Part 3]. The representation of entities in any response can be negotiated (including error responses).</dd></dl><p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn> </p><dl class="empty"><dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.</dd></dl><p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span> <dfn>client</dfn> </p><dl class="empty"><dd>A program that establishes connections for the purpose of sending requests.</dd></dl><p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span> <dfn>user
agent</dfn> </p><dl class="empty"><dd>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.</dd></dl><p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span> <dfn>server</dfn> </p><dl class="empty"><dd>An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.</dd></dl><p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span> <dfn>origin server</dfn> </p><dl class="empty"><dd>The server on which a given resource resides or is to be created.</dd></dl><p id="rfc.section.1.3.p.15"> <span
id="rfc.iref.p.1"></span> <dfn>proxy</dfn> </p><dl class="empty"><dd>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy <em class="bcp14">MUST</em> implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.</dd></dl><p id="rfc.section.1.3.p.16"> <span id="rf
c.iref.g.1"></span> <dfn>gateway</dfn> </p><dl class="empty"><dd>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.</dd></dl><p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span> <dfn>tunnel</dfn> </p><dl class="empty"><dd>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.</dd></dl><p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span> <dfn>cache</dfn> </p><dl class="empty"><dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cache
able responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.</dd></dl><p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span> <dfn>cacheable</dfn> </p><dl class="empty"><dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in [Part 6]. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.</dd></dl><p id="rfc.section.1.3.p.20"> <span id="rfc.iref.u.2"></span> <span id="rfc.iref.d.1"></span> <dfn>upstream</dfn>/<dfn>downstream</dfn> </p><dl class="empty"><dd>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</dd></dl><
p id="rfc.section.1.3.p.21"> <span id="rfc.iref.i.1"></span> <span id="rfc.iref.o.2"></span> <dfn>inbound</dfn>/<dfn>outbound</dfn> </p><dl class="empty"><dd>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"</dd></dl><h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> Overall Operation</h2><p id="rfc.section.1.4.p.1">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.
The relationship between HTTP and MIME is described in [Part 3].</p><p id="rfc.section.1.4.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O).</p><div id="rfc.figure.u.1"></div><pre class="drawing"> request chain ------------------------>
+ UA -------------------v------------------- O
+ <----------------------- response chain
+</pre><p id="rfc.section.1.4.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.</p><div id="rfc.figure.u.2"></div><pre class="drawing"> request chain -------------------------------------->
+ UA -----v----- A -----v----- B -----v----- C -----v----- O
+ <------------------------------------- response chain
+</pre><p id="rfc.section.1.4.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. This distinction is important because some HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple, simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request.</p><p id="rfc.section.1.4.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect of a cache is that the request/response chain is shortened if one of the participants along the
chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request which has not been cached by UA or A.</p><div id="rfc.figure.u.3"></div><pre class="drawing"> request chain ---------->
+ UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+ <--------- response chain
+</pre><p id="rfc.section.1.4.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cacheable responses are defined in [Part 6].</p><p id="rfc.section.1.4.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while introducing protocol constructs that meet the needs of those who build
web applications that require high reliability and, failing that, at least reliable indications of failure.</p><p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[16]</cite></a>, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.</p><p id="rfc.section.1.4.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of re
asons (see <a href="#persistent.connections" title="Persistent Connections">Section 5.1</a>).</p><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> Notational Conventions and Generic Grammar</h1><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Augmented BNF</h2><p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:</p><p id="rfc.section.2.1.p.2">name = definition </p><dl class="empty"><dd>The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is
only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.</dd></dl><p id="rfc.section.2.1.p.3">"literal" </p><dl class="empty"><dd>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</dd></dl><p id="rfc.section.2.1.p.4">rule1 | rule2 </p><dl class="empty"><dd>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</dd></dl><p id="rfc.section.2.1.p.5">(rule1 rule2) </p><dl class="empty"><dd>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".</dd></dl><p id="rfc.section.2.1.p.6">*rule </p><dl class="empty"><dd>The character "*
" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.</dd></dl><p id="rfc.section.2.1.p.7">[rule] </p><dl class="empty"><dd>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</dd></dl><p id="rfc.section.2.1.p.8">N rule </p><dl class="empty"><dd>Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.</dd></dl><p id="rfc.section.2.1.p.9">#rule </p><dl class="empty"><dd>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating
at least <n> and at most <m> elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as</dd><dd>( *LWS element *( *LWS "," *LWS element ))</dd><dd>can be shown as</dd><dd>1#element</dd><dd>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.</dd></dl><p id="rfc.section.2.1.p.10">; comment </p><dl class="empty"><dd>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This
is a simple way of including useful notes in parallel with the specifications.</dd></dl><p id="rfc.section.2.1.p.11">implied *LWS </p><dl class="empty"><dd>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.</dd></dl><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h2><p id="rfc.section.2.2.p.1">The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 <a href="#USASCII" id="rfc.xr
ef.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[18]</cite></a>.</p><div id="rfc.figure.u.4"></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><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><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> OCTET = <any 8-bit sequence of data>
+ CHAR = <any US-ASCII character (octets 0 - 127)>
+ UPALPHA = <any US-ASCII uppercase letter "A".."Z">
+ LOALPHA = <any US-ASCII lowercase letter "a".."z">
+ ALPHA = UPALPHA | LOALPHA
+ DIGIT = <any US-ASCII digit "0".."9">
+ CTL = <any US-ASCII control character
+ (octets 0 - 31) and DEL (127)>
+ CR = <US-ASCII CR, carriage return (13)>
+ LF = <US-ASCII LF, linefeed (10)>
+ SP = <US-ASCII SP, space (32)>
+ HT = <US-ASCII HT, horizontal-tab (9)>
+ <"> = <US-ASCII double-quote mark (34)>
+</pre><p id="rfc.section.2.2.p.3">HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in [Part 3].</p><div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.13"></span> CRLF = CR LF
+</pre><p id="rfc.section.2.2.p.5">HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient <em class="bcp14">MAY</em> replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.</p><div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span> LWS = [CRLF] 1*( SP | HT )
+</pre><p id="rfc.section.2.2.p.7">The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[19]</cite></a> only when encoded according to the rules of RFC 2047 <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[12]</cite></a>.</p><div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span> TEXT = <any OCTET except CTLs,
+ but including LWS>
+</pre><p id="rfc.section.2.2.p.9">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.</p><p id="rfc.section.2.2.p.10">Hexadecimal numeric characters are used in several protocol elements.</p><div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.16"></span> HEX = "A" | "B" | "C" | "D" | "E" | "F"
+ | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+</pre><p id="rfc.section.2.2.p.12">Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>).</p><div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> token = 1*<any CHAR except CTLs or separators>
+ separators = "(" | ")" | "<" | ">" | "@"
+ | "," | ";" | ":" | "\" | <">
+ | "/" | "[" | "]" | "?" | "="
+ | "{" | "}" | SP | HT
+</pre><p id="rfc.section.2.2.p.14">Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.</p><div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> comment = "(" *( ctext | quoted-pair | comment ) ")"
+ ctext = <any TEXT excluding "(" and ")">
+</pre><p id="rfc.section.2.2.p.16">A string of text is parsed as a single word if it is quoted using double-quote marks.</p><div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
+ qdtext = <any TEXT except <">>
+</pre><p id="rfc.section.2.2.p.18">The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.</p><div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.23"></span> quoted-pair = "\" CHAR
+</pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> Protocol Parameters</h1><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="http.version" href="#http.version">HTTP Version</a></h2><p id="rfc.section.3.1.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major>
; number is incremented when the format of a message within the protocol is changed. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[27]</cite></a> for a fuller explanation.</p><p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.</p><div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+</pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.</p><p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 <a href="#RFC2145" id="rf
c.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[27]</cite></a>.</p><p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p><p id="rfc.section.3.1.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway <em class="bcp14">MUST NOT</em> send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.</p><p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite ti
tle="Hypertext Transfer Protocol -- HTTP/1.1">[25]</cite></a>, caching proxies MUST, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.</p><p id="rfc.section.3.1.p.9"> </p><dl class="empty"><dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.</dd></dl><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2><p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the
Network as used in the World-Wide Web">[2]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[17]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a resource.</p><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="general.syntax" href="#general.syntax">General Syntax</a></h3><p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[9]</cite></a>, depending upon the context of their use. The two forms are differentiated by the fact that absolu
te URIs always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[3]</cite></a> and RFC 1808 <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[9]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification.</p><p id="rfc.section.3.2.1.p.2">The HTTP protocol does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to
handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see [Part 2]).</p><p id="rfc.section.3.2.1.p.3"> </p><dl class="empty"><dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.</dd></dl><h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="http.url" href="#http.url">http URL</a></h3><p id="rfc.section.3.2.2.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.</p><div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+</pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path ([Part 2]). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[20]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource ([Part 2]). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.</p><h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="uri.comparison
" href="#uri.comparison">URI Comparison</a></h3><p id="rfc.section.3.2.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: </p><ul><li>A port that is empty or not given is equivalent to the default port for that URI-reference;</li><li>Comparisons of host names <em class="bcp14">MUST</em> be case-insensitive;</li><li>Comparisons of scheme names <em class="bcp14">MUST</em> be case-insensitive;</li><li>An empty abs_path is equivalent to an abs_path of "/".</li></ul><p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[29]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.</p><p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p><div id="rf
c.figure.u.15"></div><pre class="text"> http://abc.com:80/~smith/home.html
+ http://ABC.com/%7Esmith/home.html
+ http://ABC.com:/%7esmith/home.html
+</pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> Date/Time Formats</h2><h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="full.date" href="#full.date">Full Date</a></h3><p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p><div id="rfc.figure.u.16"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
+ Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+ Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
+</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[6]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[10]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Ap
plications">Appendix B</a> for further information.</p><dl class="empty"><dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.</dd></dl><p id="rfc.section.3.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar.</p><div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.26"></span><
span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> HTTP-date = rfc1123-date | rfc850-date | asctime-date
+ rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+ rfc850-date = weekday "," SP date2 SP time SP "GMT"
+ asctime-date = wkday SP date3 SP time SP 4DIGIT
+ date1 = 2DIGIT SP month SP 4DIGIT
+ ; day month year (e.g., 02 Jun 1982)
+ date2 = 2DIGIT "-" month "-" 2DIGIT
+ ; day-month-year (e.g., 02-Jun-82)
+ date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
+ ; month day (e.g., Jun 2)
+ time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+ ; 00:00:00 - 23:59:59
+ wkday = "Mon" | "Tue" | "Wed"
+ | "Thu" | "Fri" | "Sat" | "Sun"
+ weekday = "Monday" | "Tuesday" | "Wednesday"
+ | "Thursday" | "Friday" | "Saturday" | "Sunday"
+ month = "Jan" | "Feb" | "Mar" | "Apr"
+ | "May" | "Jun" | "Jul" | "Aug"
+ | "Sep" | "Oct" | "Nov" | "Dec"
+</pre><p id="rfc.section.3.3.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers are not required to use these formats for user presentation, request logging, etc.</p><h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2><p id="rfc.section.3.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.</p><div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> transfer-coding = "chunked" | transfer-extension
+ transfer-extension = token *( ";" parameter )
+</pre><p id="rfc.section.3.4.p.3">Parameters are in the form of attribute/value pairs.</p><div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span> parameter = attribute "=" value
+ attribute = token
+ value = token | quoted-string
+</pre><p id="rfc.section.3.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 6.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 6.6</a>).</p><p id="rfc.section.3.4.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (<a href="#message.length" title="Message Length">Sect
ion 4.4</a>).</p><p id="rfc.section.3.4.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[5]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (<a href="#message.length" title="Message Length">Section 4.4</a>), or the desire to encrypt data over a shared transport.</p><p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4
.1</a>), "identity" (section 3.6.2), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate" ([Part 3]).</p><p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens ([Part 3]).</p><p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Unimplemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.</p><h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a> <a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3><p id="rfc.section.3.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. T
his allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.</p><div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span> Chunked-Body = *chunk
+ last-chunk
+ trailer
+ CRLF
+
+ chunk = chunk-size [ chunk-extension ] CRLF
+ chunk-data CRLF
+ chunk-size = 1*HEX
+ last-chunk = 1*("0") [ chunk-extension ] CRLF
+
+ chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
+ chunk-ext-name = token
+ chunk-ext-val = token | quoted-string
+ chunk-data = chunk-size(OCTET)
+ trailer = *(entity-header CRLF)
+</pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.</p><p id="rfc.section.3.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 6.5</a>).</p><p id="rfc.section.3.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: </p><ol><li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 
;6.4</a>; or,</li><li>the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.</li></ol><p id="rfc.section.3.4.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly infinite buffer on the proxy.</p><p id="rfc.section.3.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p><div id="rfc.figure.u.21"></div><pre class="text"> length := 0
+ read chunk-size, chunk-extension (if any) and CRLF
+ while (chunk-size > 0) {
+ read chunk-data and CRLF
+ append chunk-data to entity-body
+ length := length + chunk-size
+ read chunk-size and CRLF
+ }
+ read entity-header
+ while (entity-header not empty) {
+ append entity-header to existing header fields
+ read entity-header
+ }
+ Content-Length := length
+ Remove "chunked" from Transfer-Encoding
+</pre><p id="rfc.section.3.4.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-extension extensions they do not understand.</p><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="httpmessage" href="#httpmessage">HTTP Message</a></h1><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> Message Types</h2><p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p><div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span> HTTP-message = Request | Response ; HTTP/1.1 messages
+</pre><p id="rfc.section.4.1.p.3">Request ([Part 2]) and Response ([Part 2]) messages use the generic message format of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.</p><div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span> generic-message = start-line
+ *(message-header CRLF)
+ CRLF
+ [ message-body ]
+ start-line = Request-Line | Status-Line
+</pre><p id="rfc.section.4.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.</p><p id="rfc.section.4.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF.</p><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2><p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header ([Part 2]), response-header ([Part 2]), and entity-header ([Part 3]) fields, follo
w the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[7]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.</p><div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.
g.57"></span> message-header = field-name ":" [ field-value ]
+ field-name = token
+ field-value = *( field-content | LWS )
+ field-content = <the OCTETs making up the field-value
+ and consisting of either *TEXT or combinations
+ of token, separators, and quoted-string>
+</pre><p id="rfc.section.4.2.p.3">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS <em class="bcp14">MAY</em> be removed without changing the semantics of the field value. Any LWS that occurs between field-content <em class="bcp14">MAY</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.</p><p id="rfc.section.4.2.p.4">The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.</p><p id="rfc.section.4.2.p.5">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the ent
ire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded.</p><h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="message.body" href="#message.body">Message Body</a></h2><p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer-coding has been applied, as indicat
ed by the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 6.6</a>).</p><div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.58"></span> message-body = entity-body
+ | <entity-body encoded as per Transfer-Encoding>
+</pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a> places restrictions on when certain transfer-codings may be used.)</p><p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p><p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method ([Part 2]) does not allow sending
an entity-body in requests. A server <em class="bcp14">SHOULD</em> read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body <em class="bcp14">SHOULD</em> be ignored when handling the request.</p><p id="rfc.section.4.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code ([Part 2]). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length.</p><h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="message.length" href=
"#message.length">Message Length</a></h2><p id="rfc.section.4.4.p.1">The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):</p><p id="rfc.section.4.4.p.2"> </p><ol><li><p>Any response message which "<em class="bcp14">MUST NOT</em>" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.</p></li><li><p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 6.6</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "ch
unked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection.</p></li><li><p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 6.2</a>) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field <em class="bcp14">MUST NOT</em> be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter <em class="bcp14">MUST</em> be ignored.</p></li><li><p>If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows th
at the recipient can arse it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses. </p><dl class="empty"><dd>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.</dd></dl></li><li><p>By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)</p></li></ol><p id="rfc.section.4.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, t
he server <em class="bcp14">SHOULD</em> respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.</p><p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.</p><p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.</p><p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number
of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.</p><h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2><p id="rfc.section.4.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the message being transmitted.</p><div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span> general-header = Cache-Control ; [Part 6]
+ | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 6.1</a>
+ | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 6.3</a>
+ | Pragma ; [Part 6]
+ | Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 6.5</a>
+ | Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 6.6</a>
+ | Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.7</a>
+ | Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 6.8</a>
+ | Warning ; [Part 6]
[... 55 lines stripped ...]
Propchange: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.html
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org