[29] | 1 | <?xml version="1.0" encoding="utf-8"?> |
---|
[101] | 2 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
[8] | 3 | <!DOCTYPE rfc [ |
---|
| 4 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
| 5 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
| 6 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
| 7 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
| 8 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
| 9 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
| 10 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
| 11 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
| 12 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
| 13 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
[314] | 14 | <!ENTITY ID-VERSION "04"> |
---|
[301] | 15 | <!ENTITY ID-MONTH "August"> |
---|
[124] | 16 | <!ENTITY ID-YEAR "2008"> |
---|
[31] | 17 | <!ENTITY caching "<xref target='Part6' x:rel='#caching' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 18 | <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[115] | 19 | <!ENTITY media-types "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 20 | <!ENTITY content-codings "<xref target='Part3' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 21 | <!ENTITY CONNECT "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 22 | <!ENTITY content.negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 23 | <!ENTITY diff2045entity "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 24 | <!ENTITY entity "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[207] | 25 | <!ENTITY entity-body "<xref target='Part3' x:rel='#entity.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 26 | <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[207] | 27 | <!ENTITY header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 28 | <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 29 | <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 30 | <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 31 | <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 32 | <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 33 | <!ENTITY qvalue "<xref target='Part3' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 34 | <!ENTITY request-header-fields "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 35 | <!ENTITY response-header-fields "<xref target='Part2' x:rel='#response.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 36 | <!ENTITY method "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 37 | <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 38 | <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 39 | <!ENTITY status-1xx "<xref target='Part2' x:rel='#status.1xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 40 | <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[8] | 41 | ]> |
---|
| 42 | <?rfc toc="yes" ?> |
---|
[29] | 43 | <?rfc symrefs="yes" ?> |
---|
| 44 | <?rfc sortrefs="yes" ?> |
---|
[8] | 45 | <?rfc compact="yes"?> |
---|
| 46 | <?rfc subcompact="no" ?> |
---|
| 47 | <?rfc linkmailto="no" ?> |
---|
| 48 | <?rfc editing="no" ?> |
---|
[203] | 49 | <?rfc comments="yes"?> |
---|
| 50 | <?rfc inline="yes"?> |
---|
[8] | 51 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
| 52 | <?rfc-ext include-references-in-index="yes" ?> |
---|
[308] | 53 | <rfc obsoletes="2616" category="std" x:maturity-level="draft" |
---|
[29] | 54 | ipr="full3978" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" |
---|
[153] | 55 | xmlns:x='http://purl.org/net/xml2rfc/ext'> |
---|
[8] | 56 | <front> |
---|
| 57 | |
---|
[120] | 58 | <title abbrev="HTTP/1.1, Part 1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
[8] | 59 | |
---|
[29] | 60 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 61 | <organization abbrev="Day Software">Day Software</organization> |
---|
[8] | 62 | <address> |
---|
| 63 | <postal> |
---|
[29] | 64 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
| 65 | <city>Newport Beach</city> |
---|
[8] | 66 | <region>CA</region> |
---|
[29] | 67 | <code>92660</code> |
---|
| 68 | <country>USA</country> |
---|
[8] | 69 | </postal> |
---|
[29] | 70 | <phone>+1-949-706-5300</phone> |
---|
| 71 | <facsimile>+1-949-706-5305</facsimile> |
---|
| 72 | <email>fielding@gbiv.com</email> |
---|
| 73 | <uri>http://roy.gbiv.com/</uri> |
---|
[8] | 74 | </address> |
---|
| 75 | </author> |
---|
| 76 | |
---|
[29] | 77 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 78 | <organization>One Laptop per Child</organization> |
---|
[8] | 79 | <address> |
---|
| 80 | <postal> |
---|
[29] | 81 | <street>21 Oak Knoll Road</street> |
---|
| 82 | <city>Carlisle</city> |
---|
[8] | 83 | <region>MA</region> |
---|
[29] | 84 | <code>01741</code> |
---|
| 85 | <country>USA</country> |
---|
[8] | 86 | </postal> |
---|
[29] | 87 | <email>jg@laptop.org</email> |
---|
| 88 | <uri>http://www.laptop.org/</uri> |
---|
[8] | 89 | </address> |
---|
| 90 | </author> |
---|
| 91 | |
---|
| 92 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
[29] | 93 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
[8] | 94 | <address> |
---|
| 95 | <postal> |
---|
[29] | 96 | <street>HP Labs, Large Scale Systems Group</street> |
---|
| 97 | <street>1501 Page Mill Road, MS 1177</street> |
---|
[8] | 98 | <city>Palo Alto</city> |
---|
| 99 | <region>CA</region> |
---|
[29] | 100 | <code>94304</code> |
---|
| 101 | <country>USA</country> |
---|
[8] | 102 | </postal> |
---|
[29] | 103 | <email>JeffMogul@acm.org</email> |
---|
[8] | 104 | </address> |
---|
| 105 | </author> |
---|
| 106 | |
---|
| 107 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
[29] | 108 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
[8] | 109 | <address> |
---|
| 110 | <postal> |
---|
[29] | 111 | <street>1 Microsoft Way</street> |
---|
| 112 | <city>Redmond</city> |
---|
| 113 | <region>WA</region> |
---|
| 114 | <code>98052</code> |
---|
| 115 | <country>USA</country> |
---|
[8] | 116 | </postal> |
---|
[29] | 117 | <email>henrikn@microsoft.com</email> |
---|
[8] | 118 | </address> |
---|
| 119 | </author> |
---|
| 120 | |
---|
| 121 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
[29] | 122 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
[8] | 123 | <address> |
---|
| 124 | <postal> |
---|
[29] | 125 | <street>345 Park Ave</street> |
---|
| 126 | <city>San Jose</city> |
---|
[8] | 127 | <region>CA</region> |
---|
[29] | 128 | <code>95110</code> |
---|
| 129 | <country>USA</country> |
---|
[8] | 130 | </postal> |
---|
[29] | 131 | <email>LMM@acm.org</email> |
---|
| 132 | <uri>http://larry.masinter.net/</uri> |
---|
[8] | 133 | </address> |
---|
| 134 | </author> |
---|
| 135 | |
---|
| 136 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 137 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 138 | <address> |
---|
| 139 | <postal> |
---|
| 140 | <street>1 Microsoft Way</street> |
---|
| 141 | <city>Redmond</city> |
---|
| 142 | <region>WA</region> |
---|
| 143 | <code>98052</code> |
---|
| 144 | </postal> |
---|
| 145 | <email>paulle@microsoft.com</email> |
---|
| 146 | </address> |
---|
| 147 | </author> |
---|
| 148 | |
---|
| 149 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 150 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 151 | <address> |
---|
| 152 | <postal> |
---|
[34] | 153 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
| 154 | <street>The Stata Center, Building 32</street> |
---|
| 155 | <street>32 Vassar Street</street> |
---|
[8] | 156 | <city>Cambridge</city> |
---|
| 157 | <region>MA</region> |
---|
| 158 | <code>02139</code> |
---|
[29] | 159 | <country>USA</country> |
---|
[8] | 160 | </postal> |
---|
| 161 | <email>timbl@w3.org</email> |
---|
[34] | 162 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
[8] | 163 | </address> |
---|
| 164 | </author> |
---|
| 165 | |
---|
[95] | 166 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
[94] | 167 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 168 | <address> |
---|
| 169 | <postal> |
---|
| 170 | <street>W3C / ERCIM</street> |
---|
| 171 | <street>2004, rte des Lucioles</street> |
---|
| 172 | <city>Sophia-Antipolis</city> |
---|
| 173 | <region>AM</region> |
---|
| 174 | <code>06902</code> |
---|
| 175 | <country>France</country> |
---|
| 176 | </postal> |
---|
| 177 | <email>ylafon@w3.org</email> |
---|
| 178 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
| 179 | </address> |
---|
| 180 | </author> |
---|
| 181 | |
---|
[95] | 182 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 183 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 184 | <address> |
---|
| 185 | <postal> |
---|
| 186 | <street>Hafenweg 16</street> |
---|
| 187 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
| 188 | <country>Germany</country> |
---|
| 189 | </postal> |
---|
| 190 | <phone>+49 251 2807760</phone> |
---|
| 191 | <facsimile>+49 251 2807761</facsimile> |
---|
| 192 | <email>julian.reschke@greenbytes.de</email> |
---|
| 193 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
| 194 | </address> |
---|
| 195 | </author> |
---|
| 196 | |
---|
[314] | 197 | <date month="&ID-MONTH;" year="&ID-YEAR;" day="29"/> |
---|
[8] | 198 | |
---|
| 199 | <abstract> |
---|
| 200 | <t> |
---|
| 201 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 202 | protocol for distributed, collaborative, hypermedia information |
---|
[29] | 203 | systems. HTTP has been in use by the World Wide Web global information |
---|
[35] | 204 | initiative since 1990. This document is Part 1 of the seven-part specification |
---|
[29] | 205 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
[51] | 206 | obsoletes RFC 2616. Part 1 provides an overview of HTTP and |
---|
[29] | 207 | its associated terminology, defines the "http" and "https" Uniform |
---|
| 208 | Resource Identifier (URI) schemes, defines the generic message syntax |
---|
| 209 | and parsing requirements for HTTP message frames, and describes |
---|
| 210 | general security concerns for implementations. |
---|
[8] | 211 | </t> |
---|
| 212 | </abstract> |
---|
[36] | 213 | |
---|
| 214 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
| 215 | <t> |
---|
| 216 | Discussion of this draft should take place on the HTTPBIS working group |
---|
| 217 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
[113] | 218 | at <eref target="http://www.tools.ietf.org/wg/httpbis/trac/report/11"/> |
---|
[36] | 219 | and related documents (including fancy diffs) can be found at |
---|
[113] | 220 | <eref target="http://www.tools.ietf.org/wg/httpbis/"/>. |
---|
[36] | 221 | </t> |
---|
[153] | 222 | <t> |
---|
[252] | 223 | The changes in this draft are summarized in <xref target="changes.since.02"/>. |
---|
[153] | 224 | </t> |
---|
[36] | 225 | </note> |
---|
[8] | 226 | </front> |
---|
| 227 | <middle> |
---|
| 228 | <section title="Introduction" anchor="introduction"> |
---|
[29] | 229 | <t> |
---|
[8] | 230 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 231 | protocol for distributed, collaborative, hypermedia information |
---|
| 232 | systems. HTTP has been in use by the World-Wide Web global |
---|
[163] | 233 | information initiative since 1990. The first version of HTTP, commonly |
---|
[8] | 234 | referred to as HTTP/0.9, was a simple protocol for raw data transfer |
---|
[163] | 235 | across the Internet with only a single method and no metadata. |
---|
| 236 | HTTP/1.0, as defined by <xref target="RFC1945"/>, improved |
---|
[8] | 237 | the protocol by allowing messages to be in the format of MIME-like |
---|
[163] | 238 | messages, containing metadata about the data transferred and |
---|
| 239 | modifiers on the request/response semantics. However, HTTP/1.0 did |
---|
[8] | 240 | not sufficiently take into consideration the effects of hierarchical |
---|
[163] | 241 | proxies, caching, the need for persistent connections, or name-based |
---|
| 242 | virtual hosts. In addition, the proliferation of incompletely-implemented |
---|
| 243 | applications calling themselves "HTTP/1.0" necessitated a |
---|
[8] | 244 | protocol version change in order for two communicating applications |
---|
| 245 | to determine each other's true capabilities. |
---|
| 246 | </t> |
---|
| 247 | <t> |
---|
[163] | 248 | This document is Part 1 of the seven-part specification that defines |
---|
| 249 | the protocol referred to as "HTTP/1.1", obsoleting <xref target="RFC2616"/>. |
---|
| 250 | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
---|
| 251 | requirements that enable reliable implementations and adding only |
---|
| 252 | those new features that will either be safely ignored by an HTTP/1.0 |
---|
| 253 | recipient or only sent when communicating with a party advertising |
---|
| 254 | compliance with HTTP/1.1. |
---|
| 255 | Part 1 defines those aspects of HTTP/1.1 related to overall network |
---|
| 256 | operation, message framing, interaction with transport protocols, and |
---|
| 257 | URI schemes. |
---|
[8] | 258 | </t> |
---|
| 259 | <t> |
---|
[163] | 260 | This document is currently disorganized in order to minimize the changes |
---|
| 261 | between drafts and enable reviewers to see the smaller errata changes. |
---|
| 262 | The next draft will reorganize the sections to better reflect the content. |
---|
| 263 | In particular, the sections will be organized according to the typical |
---|
| 264 | process of deciding when to use HTTP (URI schemes), overall network operation, |
---|
| 265 | connection management, message framing, and generic message parsing. |
---|
| 266 | The current mess reflects how widely dispersed these topics and associated |
---|
| 267 | requirements had become in <xref target="RFC2616"/>. |
---|
| 268 | </t> |
---|
| 269 | |
---|
| 270 | <section title="Purpose" anchor="intro.purpose"> |
---|
| 271 | <t> |
---|
[8] | 272 | Practical information systems require more functionality than simple |
---|
| 273 | retrieval, including search, front-end update, and annotation. HTTP |
---|
| 274 | allows an open-ended set of methods and headers that indicate the |
---|
| 275 | purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference |
---|
| 276 | provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location |
---|
| 277 | (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a |
---|
| 278 | method is to be applied. Messages are passed in a format similar to |
---|
[133] | 279 | that used by Internet mail <xref target="RFC2822"/> as defined by the Multipurpose |
---|
[8] | 280 | Internet Mail Extensions (MIME) <xref target="RFC2045"/>. |
---|
| 281 | </t> |
---|
| 282 | <t> |
---|
| 283 | HTTP is also used as a generic protocol for communication between |
---|
| 284 | user agents and proxies/gateways to other Internet systems, including |
---|
[129] | 285 | those supported by the SMTP <xref target="RFC2821"/>, NNTP <xref target="RFC3977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>, |
---|
[8] | 286 | and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia |
---|
| 287 | access to resources available from diverse applications. |
---|
| 288 | </t> |
---|
| 289 | </section> |
---|
| 290 | |
---|
| 291 | <section title="Requirements" anchor="intro.requirements"> |
---|
| 292 | <t> |
---|
| 293 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
| 294 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
[96] | 295 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
[8] | 296 | </t> |
---|
| 297 | <t> |
---|
| 298 | An implementation is not compliant if it fails to satisfy one or more |
---|
| 299 | of the &MUST; or &REQUIRED; level requirements for the protocols it |
---|
| 300 | implements. An implementation that satisfies all the &MUST; or &REQUIRED; |
---|
| 301 | level and all the &SHOULD; level requirements for its protocols is said |
---|
| 302 | to be "unconditionally compliant"; one that satisfies all the &MUST; |
---|
| 303 | level requirements but not all the &SHOULD; level requirements for its |
---|
| 304 | protocols is said to be "conditionally compliant." |
---|
| 305 | </t> |
---|
| 306 | </section> |
---|
| 307 | |
---|
| 308 | <section title="Terminology" anchor="intro.terminology"> |
---|
| 309 | <t> |
---|
| 310 | This specification uses a number of terms to refer to the roles |
---|
| 311 | played by participants in, and objects of, the HTTP communication. |
---|
| 312 | </t> |
---|
| 313 | <t> |
---|
| 314 | <iref item="connection"/> |
---|
| 315 | <x:dfn>connection</x:dfn> |
---|
| 316 | <list> |
---|
| 317 | <t> |
---|
| 318 | A transport layer virtual circuit established between two programs |
---|
| 319 | for the purpose of communication. |
---|
| 320 | </t> |
---|
| 321 | </list> |
---|
| 322 | </t> |
---|
| 323 | <t> |
---|
| 324 | <iref item="message"/> |
---|
| 325 | <x:dfn>message</x:dfn> |
---|
| 326 | <list> |
---|
| 327 | <t> |
---|
| 328 | The basic unit of HTTP communication, consisting of a structured |
---|
| 329 | sequence of octets matching the syntax defined in <xref target="http.message"/> and |
---|
| 330 | transmitted via the connection. |
---|
| 331 | </t> |
---|
| 332 | </list> |
---|
| 333 | </t> |
---|
| 334 | <t> |
---|
| 335 | <iref item="request"/> |
---|
| 336 | <x:dfn>request</x:dfn> |
---|
| 337 | <list> |
---|
| 338 | <t> |
---|
| 339 | An HTTP request message, as defined in <xref target="request"/>. |
---|
| 340 | </t> |
---|
| 341 | </list> |
---|
| 342 | </t> |
---|
| 343 | <t> |
---|
| 344 | <iref item="response"/> |
---|
| 345 | <x:dfn>response</x:dfn> |
---|
| 346 | <list> |
---|
| 347 | <t> |
---|
| 348 | An HTTP response message, as defined in <xref target="response"/>. |
---|
| 349 | </t> |
---|
| 350 | </list> |
---|
| 351 | </t> |
---|
| 352 | <t> |
---|
| 353 | <iref item="resource"/> |
---|
| 354 | <x:dfn>resource</x:dfn> |
---|
| 355 | <list> |
---|
| 356 | <t> |
---|
| 357 | A network data object or service that can be identified by a URI, |
---|
| 358 | as defined in <xref target="uri"/>. Resources may be available in multiple |
---|
| 359 | representations (e.g. multiple languages, data formats, size, and |
---|
| 360 | resolutions) or vary in other ways. |
---|
| 361 | </t> |
---|
| 362 | </list> |
---|
| 363 | </t> |
---|
| 364 | <t> |
---|
| 365 | <iref item="entity"/> |
---|
| 366 | <x:dfn>entity</x:dfn> |
---|
| 367 | <list> |
---|
| 368 | <t> |
---|
| 369 | The information transferred as the payload of a request or |
---|
| 370 | response. An entity consists of metainformation in the form of |
---|
| 371 | entity-header fields and content in the form of an entity-body, as |
---|
[29] | 372 | described in &entity;. |
---|
[8] | 373 | </t> |
---|
| 374 | </list> |
---|
| 375 | </t> |
---|
| 376 | <t> |
---|
| 377 | <iref item="representation"/> |
---|
| 378 | <x:dfn>representation</x:dfn> |
---|
| 379 | <list> |
---|
| 380 | <t> |
---|
| 381 | An entity included with a response that is subject to content |
---|
[29] | 382 | negotiation, as described in &content.negotiation;. There may exist multiple |
---|
[8] | 383 | representations associated with a particular response status. |
---|
| 384 | </t> |
---|
| 385 | </list> |
---|
| 386 | </t> |
---|
| 387 | <t> |
---|
| 388 | <iref item="content negotiation"/> |
---|
| 389 | <x:dfn>content negotiation</x:dfn> |
---|
| 390 | <list> |
---|
| 391 | <t> |
---|
| 392 | The mechanism for selecting the appropriate representation when |
---|
[29] | 393 | servicing a request, as described in &content.negotiation;. The |
---|
[8] | 394 | representation of entities in any response can be negotiated |
---|
| 395 | (including error responses). |
---|
| 396 | </t> |
---|
| 397 | </list> |
---|
| 398 | </t> |
---|
| 399 | <t> |
---|
| 400 | <iref item="variant"/> |
---|
| 401 | <x:dfn>variant</x:dfn> |
---|
| 402 | <list> |
---|
| 403 | <t> |
---|
| 404 | A resource may have one, or more than one, representation(s) |
---|
| 405 | associated with it at any given instant. Each of these |
---|
[87] | 406 | representations is termed a `variant'. Use of the term `variant' |
---|
[8] | 407 | does not necessarily imply that the resource is subject to content |
---|
| 408 | negotiation. |
---|
| 409 | </t> |
---|
| 410 | </list> |
---|
| 411 | </t> |
---|
| 412 | <t> |
---|
| 413 | <iref item="client"/> |
---|
| 414 | <x:dfn>client</x:dfn> |
---|
| 415 | <list> |
---|
| 416 | <t> |
---|
| 417 | A program that establishes connections for the purpose of sending |
---|
| 418 | requests. |
---|
| 419 | </t> |
---|
| 420 | </list> |
---|
| 421 | </t> |
---|
| 422 | <t> |
---|
| 423 | <iref item="user agent"/> |
---|
| 424 | <x:dfn>user agent</x:dfn> |
---|
| 425 | <list> |
---|
| 426 | <t> |
---|
| 427 | The client which initiates a request. These are often browsers, |
---|
| 428 | editors, spiders (web-traversing robots), or other end user tools. |
---|
| 429 | </t> |
---|
| 430 | </list> |
---|
| 431 | </t> |
---|
| 432 | <t> |
---|
| 433 | <iref item="server"/> |
---|
| 434 | <x:dfn>server</x:dfn> |
---|
| 435 | <list> |
---|
| 436 | <t> |
---|
| 437 | An application program that accepts connections in order to |
---|
| 438 | service requests by sending back responses. Any given program may |
---|
| 439 | be capable of being both a client and a server; our use of these |
---|
| 440 | terms refers only to the role being performed by the program for a |
---|
| 441 | particular connection, rather than to the program's capabilities |
---|
| 442 | in general. Likewise, any server may act as an origin server, |
---|
| 443 | proxy, gateway, or tunnel, switching behavior based on the nature |
---|
| 444 | of each request. |
---|
| 445 | </t> |
---|
| 446 | </list> |
---|
| 447 | </t> |
---|
| 448 | <t> |
---|
| 449 | <iref item="origin server"/> |
---|
| 450 | <x:dfn>origin server</x:dfn> |
---|
| 451 | <list> |
---|
| 452 | <t> |
---|
| 453 | The server on which a given resource resides or is to be created. |
---|
| 454 | </t> |
---|
| 455 | </list> |
---|
| 456 | </t> |
---|
| 457 | <t> |
---|
| 458 | <iref item="proxy"/> |
---|
| 459 | <x:dfn>proxy</x:dfn> |
---|
| 460 | <list> |
---|
| 461 | <t> |
---|
| 462 | An intermediary program which acts as both a server and a client |
---|
| 463 | for the purpose of making requests on behalf of other clients. |
---|
| 464 | Requests are serviced internally or by passing them on, with |
---|
| 465 | possible translation, to other servers. A proxy &MUST; implement |
---|
| 466 | both the client and server requirements of this specification. A |
---|
| 467 | "transparent proxy" is a proxy that does not modify the request or |
---|
| 468 | response beyond what is required for proxy authentication and |
---|
| 469 | identification. A "non-transparent proxy" is a proxy that modifies |
---|
| 470 | the request or response in order to provide some added service to |
---|
| 471 | the user agent, such as group annotation services, media type |
---|
| 472 | transformation, protocol reduction, or anonymity filtering. Except |
---|
| 473 | where either transparent or non-transparent behavior is explicitly |
---|
| 474 | stated, the HTTP proxy requirements apply to both types of |
---|
| 475 | proxies. |
---|
| 476 | </t> |
---|
| 477 | </list> |
---|
| 478 | </t> |
---|
| 479 | <t> |
---|
| 480 | <iref item="gateway"/> |
---|
| 481 | <x:dfn>gateway</x:dfn> |
---|
| 482 | <list> |
---|
| 483 | <t> |
---|
| 484 | A server which acts as an intermediary for some other server. |
---|
| 485 | Unlike a proxy, a gateway receives requests as if it were the |
---|
| 486 | origin server for the requested resource; the requesting client |
---|
| 487 | may not be aware that it is communicating with a gateway. |
---|
| 488 | </t> |
---|
| 489 | </list> |
---|
| 490 | </t> |
---|
| 491 | <t> |
---|
| 492 | <iref item="tunnel"/> |
---|
| 493 | <x:dfn>tunnel</x:dfn> |
---|
| 494 | <list> |
---|
| 495 | <t> |
---|
| 496 | An intermediary program which is acting as a blind relay between |
---|
| 497 | two connections. Once active, a tunnel is not considered a party |
---|
| 498 | to the HTTP communication, though the tunnel may have been |
---|
| 499 | initiated by an HTTP request. The tunnel ceases to exist when both |
---|
| 500 | ends of the relayed connections are closed. |
---|
| 501 | </t> |
---|
| 502 | </list> |
---|
| 503 | </t> |
---|
| 504 | <t> |
---|
| 505 | <iref item="cache"/> |
---|
| 506 | <x:dfn>cache</x:dfn> |
---|
| 507 | <list> |
---|
| 508 | <t> |
---|
| 509 | A program's local store of response messages and the subsystem |
---|
| 510 | that controls its message storage, retrieval, and deletion. A |
---|
| 511 | cache stores cacheable responses in order to reduce the response |
---|
| 512 | time and network bandwidth consumption on future, equivalent |
---|
| 513 | requests. Any client or server may include a cache, though a cache |
---|
| 514 | cannot be used by a server that is acting as a tunnel. |
---|
| 515 | </t> |
---|
| 516 | </list> |
---|
| 517 | </t> |
---|
| 518 | <t> |
---|
| 519 | <iref item="cacheable"/> |
---|
| 520 | <x:dfn>cacheable</x:dfn> |
---|
| 521 | <list> |
---|
| 522 | <t> |
---|
| 523 | A response is cacheable if a cache is allowed to store a copy of |
---|
| 524 | the response message for use in answering subsequent requests. The |
---|
| 525 | rules for determining the cacheability of HTTP responses are |
---|
[29] | 526 | defined in &caching;. Even if a resource is cacheable, there may |
---|
[8] | 527 | be additional constraints on whether a cache can use the cached |
---|
| 528 | copy for a particular request. |
---|
| 529 | </t> |
---|
| 530 | </list> |
---|
| 531 | </t> |
---|
| 532 | <t> |
---|
| 533 | <iref item="upstream"/> |
---|
| 534 | <iref item="downstream"/> |
---|
| 535 | <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn> |
---|
| 536 | <list> |
---|
| 537 | <t> |
---|
| 538 | Upstream and downstream describe the flow of a message: all |
---|
| 539 | messages flow from upstream to downstream. |
---|
| 540 | </t> |
---|
| 541 | </list> |
---|
| 542 | </t> |
---|
| 543 | <t> |
---|
| 544 | <iref item="inbound"/> |
---|
| 545 | <iref item="outbound"/> |
---|
| 546 | <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn> |
---|
| 547 | <list> |
---|
| 548 | <t> |
---|
| 549 | Inbound and outbound refer to the request and response paths for |
---|
| 550 | messages: "inbound" means "traveling toward the origin server", |
---|
| 551 | and "outbound" means "traveling toward the user agent" |
---|
| 552 | </t> |
---|
| 553 | </list> |
---|
| 554 | </t> |
---|
| 555 | </section> |
---|
| 556 | |
---|
| 557 | <section title="Overall Operation" anchor="intro.overall.operation"> |
---|
| 558 | <t> |
---|
[172] | 559 | HTTP is a request/response protocol. A client sends a |
---|
[8] | 560 | request to the server in the form of a request method, URI, and |
---|
| 561 | protocol version, followed by a MIME-like message containing request |
---|
| 562 | modifiers, client information, and possible body content over a |
---|
| 563 | connection with a server. The server responds with a status line, |
---|
| 564 | including the message's protocol version and a success or error code, |
---|
| 565 | followed by a MIME-like message containing server information, entity |
---|
| 566 | metainformation, and possible entity-body content. The relationship |
---|
[29] | 567 | between HTTP and MIME is described in &diff2045entity;. |
---|
[8] | 568 | </t> |
---|
| 569 | <t> |
---|
| 570 | Most HTTP communication is initiated by a user agent and consists of |
---|
| 571 | a request to be applied to a resource on some origin server. In the |
---|
| 572 | simplest case, this may be accomplished via a single connection (v) |
---|
| 573 | between the user agent (UA) and the origin server (O). |
---|
| 574 | </t> |
---|
| 575 | <figure><artwork type="drawing"> |
---|
| 576 | request chain ------------------------> |
---|
| 577 | UA -------------------v------------------- O |
---|
| 578 | <----------------------- response chain |
---|
| 579 | </artwork></figure> |
---|
| 580 | <t> |
---|
| 581 | A more complicated situation occurs when one or more intermediaries |
---|
| 582 | are present in the request/response chain. There are three common |
---|
| 583 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
---|
| 584 | forwarding agent, receiving requests for a URI in its absolute form, |
---|
| 585 | rewriting all or part of the message, and forwarding the reformatted |
---|
| 586 | request toward the server identified by the URI. A gateway is a |
---|
| 587 | receiving agent, acting as a layer above some other server(s) and, if |
---|
| 588 | necessary, translating the requests to the underlying server's |
---|
| 589 | protocol. A tunnel acts as a relay point between two connections |
---|
| 590 | without changing the messages; tunnels are used when the |
---|
| 591 | communication needs to pass through an intermediary (such as a |
---|
| 592 | firewall) even when the intermediary cannot understand the contents |
---|
| 593 | of the messages. |
---|
| 594 | </t> |
---|
| 595 | <figure><artwork type="drawing"> |
---|
| 596 | request chain --------------------------------------> |
---|
| 597 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
---|
| 598 | <------------------------------------- response chain |
---|
| 599 | </artwork></figure> |
---|
| 600 | <t> |
---|
| 601 | The figure above shows three intermediaries (A, B, and C) between the |
---|
| 602 | user agent and origin server. A request or response message that |
---|
| 603 | travels the whole chain will pass through four separate connections. |
---|
| 604 | This distinction is important because some HTTP communication options |
---|
| 605 | may apply only to the connection with the nearest, non-tunnel |
---|
| 606 | neighbor, only to the end-points of the chain, or to all connections |
---|
| 607 | along the chain. Although the diagram is linear, each participant may |
---|
| 608 | be engaged in multiple, simultaneous communications. For example, B |
---|
| 609 | may be receiving requests from many clients other than A, and/or |
---|
| 610 | forwarding requests to servers other than C, at the same time that it |
---|
| 611 | is handling A's request. |
---|
| 612 | </t> |
---|
| 613 | <t> |
---|
| 614 | Any party to the communication which is not acting as a tunnel may |
---|
| 615 | employ an internal cache for handling requests. The effect of a cache |
---|
| 616 | is that the request/response chain is shortened if one of the |
---|
| 617 | participants along the chain has a cached response applicable to that |
---|
| 618 | request. The following illustrates the resulting chain if B has a |
---|
| 619 | cached copy of an earlier response from O (via C) for a request which |
---|
| 620 | has not been cached by UA or A. |
---|
| 621 | </t> |
---|
| 622 | <figure><artwork type="drawing"> |
---|
| 623 | request chain ----------> |
---|
| 624 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
---|
| 625 | <--------- response chain |
---|
| 626 | </artwork></figure> |
---|
| 627 | <t> |
---|
| 628 | Not all responses are usefully cacheable, and some requests may |
---|
| 629 | contain modifiers which place special requirements on cache behavior. |
---|
| 630 | HTTP requirements for cache behavior and cacheable responses are |
---|
[29] | 631 | defined in &caching;. |
---|
[8] | 632 | </t> |
---|
| 633 | <t> |
---|
| 634 | In fact, there are a wide variety of architectures and configurations |
---|
| 635 | of caches and proxies currently being experimented with or deployed |
---|
| 636 | across the World Wide Web. These systems include national hierarchies |
---|
| 637 | of proxy caches to save transoceanic bandwidth, systems that |
---|
| 638 | broadcast or multicast cache entries, organizations that distribute |
---|
| 639 | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
---|
| 640 | in corporate intranets over high-bandwidth links, and for access via |
---|
| 641 | PDAs with low-power radio links and intermittent connectivity. The |
---|
| 642 | goal of HTTP/1.1 is to support the wide diversity of configurations |
---|
| 643 | already deployed while introducing protocol constructs that meet the |
---|
| 644 | needs of those who build web applications that require high |
---|
| 645 | reliability and, failing that, at least reliable indications of |
---|
| 646 | failure. |
---|
| 647 | </t> |
---|
| 648 | <t> |
---|
| 649 | HTTP communication usually takes place over TCP/IP connections. The |
---|
[91] | 650 | default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does |
---|
[8] | 651 | not preclude HTTP from being implemented on top of any other protocol |
---|
| 652 | on the Internet, or on other networks. HTTP only presumes a reliable |
---|
| 653 | transport; any protocol that provides such guarantees can be used; |
---|
| 654 | the mapping of the HTTP/1.1 request and response structures onto the |
---|
| 655 | transport data units of the protocol in question is outside the scope |
---|
| 656 | of this specification. |
---|
| 657 | </t> |
---|
| 658 | <t> |
---|
| 659 | In HTTP/1.0, most implementations used a new connection for each |
---|
| 660 | request/response exchange. In HTTP/1.1, a connection may be used for |
---|
| 661 | one or more request/response exchanges, although connections may be |
---|
| 662 | closed for a variety of reasons (see <xref target="persistent.connections"/>). |
---|
| 663 | </t> |
---|
| 664 | </section> |
---|
| 665 | </section> |
---|
| 666 | |
---|
| 667 | <section title="Notational Conventions and Generic Grammar" anchor="notation"> |
---|
| 668 | |
---|
| 669 | <section title="Augmented BNF" anchor="notation.abnf"> |
---|
| 670 | <t> |
---|
| 671 | All of the mechanisms specified in this document are described in |
---|
| 672 | both prose and an augmented Backus-Naur Form (BNF) similar to that |
---|
[129] | 673 | used by <xref target="RFC822ABNF"/>. Implementors will need to be familiar with the |
---|
[8] | 674 | notation in order to understand this specification. The augmented BNF |
---|
| 675 | includes the following constructs: |
---|
| 676 | </t> |
---|
| 677 | <t> |
---|
| 678 | name = definition |
---|
| 679 | <list> |
---|
| 680 | <t> |
---|
| 681 | The name of a rule is simply the name itself (without any |
---|
| 682 | enclosing "<" and ">") and is separated from its definition by the |
---|
| 683 | equal "=" character. White space is only significant in that |
---|
| 684 | indentation of continuation lines is used to indicate a rule |
---|
| 685 | definition that spans more than one line. Certain basic rules are |
---|
[154] | 686 | in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle |
---|
[8] | 687 | brackets are used within definitions whenever their presence will |
---|
| 688 | facilitate discerning the use of rule names. |
---|
| 689 | </t> |
---|
| 690 | </list> |
---|
| 691 | </t> |
---|
| 692 | <t> |
---|
| 693 | "literal" |
---|
| 694 | <list> |
---|
| 695 | <t> |
---|
| 696 | Quotation marks surround literal text. Unless stated otherwise, |
---|
| 697 | the text is case-insensitive. |
---|
| 698 | </t> |
---|
| 699 | </list> |
---|
| 700 | </t> |
---|
| 701 | <t> |
---|
| 702 | rule1 | rule2 |
---|
| 703 | <list> |
---|
| 704 | <t> |
---|
| 705 | Elements separated by a bar ("|") are alternatives, e.g., "yes | |
---|
| 706 | no" will accept yes or no. |
---|
| 707 | </t> |
---|
| 708 | </list> |
---|
| 709 | </t> |
---|
| 710 | <t> |
---|
| 711 | (rule1 rule2) |
---|
| 712 | <list> |
---|
| 713 | <t> |
---|
| 714 | Elements enclosed in parentheses are treated as a single element. |
---|
| 715 | Thus, "(elem (foo | bar) elem)" allows the token sequences "elem |
---|
| 716 | foo elem" and "elem bar elem". |
---|
| 717 | </t> |
---|
| 718 | </list> |
---|
| 719 | </t> |
---|
| 720 | <t> |
---|
| 721 | *rule |
---|
| 722 | <list> |
---|
| 723 | <t> |
---|
| 724 | The character "*" preceding an element indicates repetition. The |
---|
| 725 | full form is "<n>*<m>element" indicating at least <n> and at most |
---|
| 726 | <m> occurrences of element. Default values are 0 and infinity so |
---|
| 727 | that "*(element)" allows any number, including zero; "1*element" |
---|
| 728 | requires at least one; and "1*2element" allows one or two. |
---|
| 729 | </t> |
---|
| 730 | </list> |
---|
| 731 | </t> |
---|
| 732 | <t> |
---|
| 733 | [rule] |
---|
| 734 | <list> |
---|
| 735 | <t> |
---|
| 736 | Square brackets enclose optional elements; "[foo bar]" is |
---|
| 737 | equivalent to "*1(foo bar)". |
---|
| 738 | </t> |
---|
| 739 | </list> |
---|
| 740 | </t> |
---|
| 741 | <t> |
---|
| 742 | N rule |
---|
| 743 | <list> |
---|
| 744 | <t> |
---|
| 745 | Specific repetition: "<n>(element)" is equivalent to |
---|
| 746 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). |
---|
| 747 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three |
---|
| 748 | alphabetic characters. |
---|
| 749 | </t> |
---|
| 750 | </list> |
---|
| 751 | </t> |
---|
| 752 | <t> |
---|
| 753 | #rule |
---|
| 754 | <list> |
---|
| 755 | <t> |
---|
| 756 | A construct "#" is defined, similar to "*", for defining lists of |
---|
| 757 | elements. The full form is "<n>#<m>element" indicating at least |
---|
| 758 | <n> and at most <m> elements, each separated by one or more commas |
---|
| 759 | (",") and &OPTIONAL; linear white space (LWS). This makes the usual |
---|
| 760 | form of lists very easy; a rule such as |
---|
[249] | 761 | <figure><artwork type="example"> |
---|
| 762 | ( *<x:ref>LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure> |
---|
[8] | 763 | </t> |
---|
| 764 | <t> |
---|
| 765 | can be shown as |
---|
[249] | 766 | <figure><artwork type="example"> |
---|
| 767 | 1#element</artwork></figure> |
---|
[8] | 768 | </t> |
---|
| 769 | <t> |
---|
| 770 | Wherever this construct is used, null elements are allowed, but do |
---|
| 771 | not contribute to the count of elements present. That is, |
---|
| 772 | "(element), , (element) " is permitted, but counts as only two |
---|
| 773 | elements. Therefore, where at least one element is required, at |
---|
| 774 | least one non-null element &MUST; be present. Default values are 0 |
---|
| 775 | and infinity so that "#element" allows any number, including zero; |
---|
| 776 | "1#element" requires at least one; and "1#2element" allows one or |
---|
| 777 | two. |
---|
| 778 | </t> |
---|
| 779 | </list> |
---|
| 780 | </t> |
---|
| 781 | <t> |
---|
| 782 | ; comment |
---|
| 783 | <list> |
---|
| 784 | <t> |
---|
| 785 | A semi-colon, set off some distance to the right of rule text, |
---|
| 786 | starts a comment that continues to the end of line. This is a |
---|
| 787 | simple way of including useful notes in parallel with the |
---|
| 788 | specifications. |
---|
| 789 | </t> |
---|
| 790 | </list> |
---|
| 791 | </t> |
---|
[259] | 792 | <t anchor="implied.LWS"> |
---|
| 793 | <iref item="implied *LWS" primary="true"/> |
---|
[8] | 794 | implied *LWS |
---|
| 795 | <list> |
---|
| 796 | <t> |
---|
| 797 | The grammar described by this specification is word-based. Except |
---|
| 798 | where noted otherwise, linear white space (LWS) can be included |
---|
| 799 | between any two adjacent words (token or quoted-string), and |
---|
| 800 | between adjacent words and separators, without changing the |
---|
| 801 | interpretation of a field. At least one delimiter (LWS and/or |
---|
| 802 | separators) &MUST; exist between any two tokens (for the definition |
---|
| 803 | of "token" below), since they would otherwise be interpreted as a |
---|
| 804 | single token. |
---|
| 805 | </t> |
---|
| 806 | </list> |
---|
| 807 | </t> |
---|
| 808 | </section> |
---|
| 809 | |
---|
| 810 | <section title="Basic Rules" anchor="basic.rules"> |
---|
[229] | 811 | <t anchor="core.rules"> |
---|
| 812 | <x:anchor-alias value="OCTET"/> |
---|
| 813 | <x:anchor-alias value="CHAR"/> |
---|
| 814 | <x:anchor-alias value="ALPHA"/> |
---|
| 815 | <x:anchor-alias value="DIGIT"/> |
---|
| 816 | <x:anchor-alias value="CTL"/> |
---|
| 817 | <x:anchor-alias value="CR"/> |
---|
| 818 | <x:anchor-alias value="LF"/> |
---|
| 819 | <x:anchor-alias value="SP"/> |
---|
| 820 | <x:anchor-alias value="HTAB"/> |
---|
| 821 | <x:anchor-alias value="DQUOTE"/> |
---|
[8] | 822 | The following rules are used throughout this specification to |
---|
| 823 | describe basic parsing constructs. The US-ASCII coded character set |
---|
| 824 | is defined by ANSI X3.4-1986 <xref target="USASCII"/>. |
---|
| 825 | </t> |
---|
[186] | 826 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HTAB"/><iref primary="true" item="Grammar" subitem="DQUOTE"/> |
---|
[229] | 827 | <x:ref>OCTET</x:ref> = %x00-FF |
---|
[186] | 828 | ; any 8-bit sequence of data |
---|
[229] | 829 | <x:ref>CHAR</x:ref> = %x01-7F |
---|
[188] | 830 | ; any US-ASCII character, excluding NUL |
---|
[229] | 831 | <x:ref>ALPHA</x:ref> = %x41-5A | %x61-7A |
---|
[187] | 832 | ; A-Z | a-z |
---|
[229] | 833 | <x:ref>DIGIT</x:ref> = %x30-39 |
---|
[186] | 834 | ; any US-ASCII digit "0".."9" |
---|
[229] | 835 | <x:ref>CTL</x:ref> = %x00-1F | %x7F |
---|
[186] | 836 | ; (octets 0 - 31) and DEL (127) |
---|
[229] | 837 | <x:ref>CR</x:ref> = %x0D |
---|
[186] | 838 | ; US-ASCII CR, carriage return (13) |
---|
[229] | 839 | <x:ref>LF</x:ref> = %x0A |
---|
[186] | 840 | ; US-ASCII LF, linefeed (10) |
---|
[229] | 841 | <x:ref>SP</x:ref> = %x20 |
---|
[186] | 842 | ; US-ASCII SP, space (32) |
---|
[229] | 843 | <x:ref>HTAB</x:ref> = %x09 |
---|
[186] | 844 | ; US-ASCII HT, horizontal-tab (9) |
---|
[229] | 845 | <x:ref>DQUOTE</x:ref> = %x22 |
---|
[186] | 846 | ; US-ASCII double-quote mark (34) |
---|
[8] | 847 | </artwork></figure> |
---|
[229] | 848 | <t anchor="rule.CRLF"> |
---|
| 849 | <x:anchor-alias value="CRLF"/> |
---|
[8] | 850 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
---|
| 851 | protocol elements except the entity-body (see <xref target="tolerant.applications"/> for |
---|
| 852 | tolerant applications). The end-of-line marker within an entity-body |
---|
[115] | 853 | is defined by its associated media type, as described in &media-types;. |
---|
[8] | 854 | </t> |
---|
| 855 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="CRLF"/> |
---|
[229] | 856 | <x:ref>CRLF</x:ref> = <x:ref>CR</x:ref> LF |
---|
[8] | 857 | </artwork></figure> |
---|
[229] | 858 | <t anchor="rule.LWS"> |
---|
| 859 | <x:anchor-alias value="LWS"/> |
---|
[8] | 860 | HTTP/1.1 header field values can be folded onto multiple lines if the |
---|
| 861 | continuation line begins with a space or horizontal tab. All linear |
---|
| 862 | white space, including folding, has the same semantics as SP. A |
---|
| 863 | recipient &MAY; replace any linear white space with a single SP before |
---|
| 864 | interpreting the field value or forwarding the message downstream. |
---|
| 865 | </t> |
---|
| 866 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/> |
---|
[229] | 867 | <x:ref>LWS</x:ref> = [<x:ref>CRLF</x:ref>] 1*( <x:ref>SP</x:ref> | <x:ref>HTAB</x:ref> ) |
---|
[8] | 868 | </artwork></figure> |
---|
[229] | 869 | <t anchor="rule.TEXT"> |
---|
| 870 | <x:anchor-alias value="TEXT"/> |
---|
[8] | 871 | The TEXT rule is only used for descriptive field contents and values |
---|
| 872 | that are not intended to be interpreted by the message parser. Words |
---|
| 873 | of *TEXT &MAY; contain characters from character sets other than ISO-8859-1 |
---|
[121] | 874 | <xref target="ISO-8859-1"/> only when encoded according to the rules of |
---|
[8] | 875 | <xref target="RFC2047"/>. |
---|
| 876 | </t> |
---|
| 877 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/> |
---|
[229] | 878 | <x:ref>TEXT</x:ref> = %x20-7E | %x80-FF | <x:ref>LWS</x:ref> |
---|
| 879 | ; any <x:ref>OCTET</x:ref> except <x:ref>CTL</x:ref>s, but including <x:ref>LWS</x:ref> |
---|
[8] | 880 | </artwork></figure> |
---|
| 881 | <t> |
---|
| 882 | A CRLF is allowed in the definition of TEXT only as part of a header |
---|
| 883 | field continuation. It is expected that the folding LWS will be |
---|
| 884 | replaced with a single SP before interpretation of the TEXT value. |
---|
| 885 | </t> |
---|
[309] | 886 | <t anchor="rule.HEXDIG"> |
---|
| 887 | <x:anchor-alias value="HEXDIG"/> |
---|
[8] | 888 | Hexadecimal numeric characters are used in several protocol elements. |
---|
| 889 | </t> |
---|
[309] | 890 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HEXDIG"/> |
---|
| 891 | <x:ref>HEXDIG</x:ref> = "A" | "B" | "C" | "D" | "E" | "F" |
---|
[229] | 892 | | "a" | "b" | "c" | "d" | "e" | "f" | <x:ref>DIGIT</x:ref> |
---|
[8] | 893 | </artwork></figure> |
---|
[229] | 894 | <t anchor="rule.token.separators"> |
---|
| 895 | <x:anchor-alias value="tchar"/> |
---|
| 896 | <x:anchor-alias value="token"/> |
---|
| 897 | <x:anchor-alias value="separators"/> |
---|
[8] | 898 | Many HTTP/1.1 header field values consist of words separated by LWS |
---|
| 899 | or special characters. These special characters &MUST; be in a quoted |
---|
| 900 | string to be used within a parameter value (as defined in |
---|
| 901 | <xref target="transfer.codings"/>). |
---|
| 902 | </t> |
---|
[214] | 903 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><iref primary="true" item="Grammar" subitem="separators"/> |
---|
[229] | 904 | <x:ref>separators</x:ref> = "(" | ")" | "<" | ">" | "@" |
---|
| 905 | | "," | ";" | ":" | "\" | <x:ref>DQUOTE</x:ref> |
---|
[135] | 906 | | "/" | "[" | "]" | "?" | "=" |
---|
[229] | 907 | | "{" | "}" | <x:ref>SP</x:ref> | <x:ref>HTAB</x:ref> |
---|
[214] | 908 | |
---|
[229] | 909 | <x:ref>tchar</x:ref> = "!" | "#" | "$" | "%" | "&" | "'" | "*" |
---|
[218] | 910 | | "+" | "-" | "." | "^" | "_" | "`" | "|" | "~" |
---|
[229] | 911 | | <x:ref>DIGIT</x:ref> | <x:ref>ALPHA</x:ref> |
---|
| 912 | ; any <x:ref>CHAR</x:ref> except <x:ref>CTL</x:ref>s or <x:ref>separators</x:ref> |
---|
[214] | 913 | |
---|
[229] | 914 | <x:ref>token</x:ref> = 1*<x:ref>tchar</x:ref> |
---|
[8] | 915 | </artwork></figure> |
---|
[229] | 916 | <t anchor="rule.comment"> |
---|
| 917 | <x:anchor-alias value="comment"/> |
---|
| 918 | <x:anchor-alias value="ctext"/> |
---|
[8] | 919 | Comments can be included in some HTTP header fields by surrounding |
---|
| 920 | the comment text with parentheses. Comments are only allowed in |
---|
| 921 | fields containing "comment" as part of their field value definition. |
---|
| 922 | In all other fields, parentheses are considered part of the field |
---|
| 923 | value. |
---|
| 924 | </t> |
---|
| 925 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/> |
---|
[229] | 926 | <x:ref>comment</x:ref> = "(" *( <x:ref>ctext</x:ref> | <x:ref>quoted-pair</x:ref> | <x:ref>comment</x:ref> ) ")" |
---|
| 927 | <x:ref>ctext</x:ref> = <any <x:ref>TEXT</x:ref> excluding "(" and ")"> |
---|
[8] | 928 | </artwork></figure> |
---|
[229] | 929 | <t anchor="rule.quoted-string"> |
---|
| 930 | <x:anchor-alias value="quoted-string"/> |
---|
| 931 | <x:anchor-alias value="qdtext"/> |
---|
[8] | 932 | A string of text is parsed as a single word if it is quoted using |
---|
| 933 | double-quote marks. |
---|
| 934 | </t> |
---|
| 935 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/> |
---|
[229] | 936 | <x:ref>quoted-string</x:ref> = ( <x:ref>DQUOTE</x:ref> *(<x:ref>qdtext</x:ref> | <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> ) |
---|
| 937 | <x:ref>qdtext</x:ref> = <any <x:ref>TEXT</x:ref> excluding <x:ref>DQUOTE</x:ref> and "\"> |
---|
[8] | 938 | </artwork></figure> |
---|
[229] | 939 | <t anchor="rule.quoted-pair"> |
---|
| 940 | <x:anchor-alias value="quoted-pair"/> |
---|
[238] | 941 | <x:anchor-alias value="quoted-text"/> |
---|
[8] | 942 | The backslash character ("\") &MAY; be used as a single-character |
---|
| 943 | quoting mechanism only within quoted-string and comment constructs. |
---|
| 944 | </t> |
---|
[238] | 945 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-text"/><iref primary="true" item="Grammar" subitem="quoted-pair"/> |
---|
| 946 | <x:ref>quoted-text</x:ref> = %x01-09 | |
---|
| 947 | %x0B-0C | |
---|
| 948 | %x0E-FF ; Characters excluding NUL, <x:ref>CR</x:ref> and <x:ref>LF</x:ref> |
---|
| 949 | <x:ref>quoted-pair</x:ref> = "\" <x:ref>quoted-text</x:ref> |
---|
[8] | 950 | </artwork></figure> |
---|
| 951 | </section> |
---|
[207] | 952 | |
---|
| 953 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
[229] | 954 | <x:anchor-alias value="request-header"/> |
---|
| 955 | <x:anchor-alias value="response-header"/> |
---|
| 956 | <x:anchor-alias value="accept-params"/> |
---|
| 957 | <x:anchor-alias value="entity-body"/> |
---|
| 958 | <x:anchor-alias value="entity-header"/> |
---|
| 959 | <x:anchor-alias value="Cache-Control"/> |
---|
| 960 | <x:anchor-alias value="Pragma"/> |
---|
| 961 | <x:anchor-alias value="Warning"/> |
---|
[207] | 962 | <t> |
---|
| 963 | The ABNF rules below are defined in other parts: |
---|
| 964 | </t> |
---|
| 965 | <figure><!-- Part2--><artwork type="abnf2616"> |
---|
[229] | 966 | <x:ref>request-header</x:ref> = <request-header, defined in &request-header-fields;> |
---|
| 967 | <x:ref>response-header</x:ref> = <response-header, defined in &response-header-fields;> |
---|
[207] | 968 | </artwork></figure> |
---|
| 969 | <figure><!-- Part3--><artwork type="abnf2616"> |
---|
[229] | 970 | <x:ref>accept-params</x:ref> = <accept-params, defined in &header-accept;> |
---|
| 971 | <x:ref>entity-body</x:ref> = <entity-body, defined in &entity-body;> |
---|
| 972 | <x:ref>entity-header</x:ref> = <entity-header, defined in &entity-header-fields;> |
---|
[207] | 973 | </artwork></figure> |
---|
| 974 | <figure><!-- Part6--><artwork type="abnf2616"> |
---|
[229] | 975 | <x:ref>Cache-Control</x:ref> = <Cache-Control, defined in &header-pragma;> |
---|
| 976 | <x:ref>Pragma</x:ref> = <Pragma, defined in &header-pragma;> |
---|
| 977 | <x:ref>Warning</x:ref> = <Warning, defined in &header-warning;> |
---|
[207] | 978 | </artwork></figure> |
---|
[8] | 979 | </section> |
---|
| 980 | |
---|
[207] | 981 | </section> |
---|
| 982 | |
---|
[8] | 983 | <section title="Protocol Parameters" anchor="protocol.parameters"> |
---|
| 984 | |
---|
| 985 | <section title="HTTP Version" anchor="http.version"> |
---|
[229] | 986 | <x:anchor-alias value="HTTP-Version"/> |
---|
[260] | 987 | <x:anchor-alias value="HTTP-Prot-Name"/> |
---|
[8] | 988 | <t> |
---|
| 989 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
---|
| 990 | of the protocol. The protocol versioning policy is intended to allow |
---|
| 991 | the sender to indicate the format of a message and its capacity for |
---|
| 992 | understanding further HTTP communication, rather than the features |
---|
| 993 | obtained via that communication. No change is made to the version |
---|
| 994 | number for the addition of message components which do not affect |
---|
| 995 | communication behavior or which only add to extensible field values. |
---|
| 996 | The <minor> number is incremented when the changes made to the |
---|
| 997 | protocol add features which do not change the general message parsing |
---|
| 998 | algorithm, but which may add to the message semantics and imply |
---|
| 999 | additional capabilities of the sender. The <major> number is |
---|
| 1000 | incremented when the format of a message within the protocol is |
---|
[97] | 1001 | changed. See <xref target="RFC2145"/> for a fuller explanation. |
---|
[8] | 1002 | </t> |
---|
| 1003 | <t> |
---|
| 1004 | The version of an HTTP message is indicated by an HTTP-Version field |
---|
[68] | 1005 | in the first line of the message. HTTP-Version is case-sensitive. |
---|
[8] | 1006 | </t> |
---|
[260] | 1007 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/> |
---|
| 1008 | <x:ref>HTTP-Version</x:ref> = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref> |
---|
[272] | 1009 | <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive |
---|
[8] | 1010 | </artwork></figure> |
---|
| 1011 | <t> |
---|
| 1012 | Note that the major and minor numbers &MUST; be treated as separate |
---|
| 1013 | integers and that each &MAY; be incremented higher than a single digit. |
---|
| 1014 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
---|
| 1015 | lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and |
---|
| 1016 | &MUST-NOT; be sent. |
---|
| 1017 | </t> |
---|
| 1018 | <t> |
---|
| 1019 | An application that sends a request or response message that includes |
---|
| 1020 | HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant |
---|
| 1021 | with this specification. Applications that are at least conditionally |
---|
| 1022 | compliant with this specification &SHOULD; use an HTTP-Version of |
---|
| 1023 | "HTTP/1.1" in their messages, and &MUST; do so for any message that is |
---|
| 1024 | not compatible with HTTP/1.0. For more details on when to send |
---|
[97] | 1025 | specific HTTP-Version values, see <xref target="RFC2145"/>. |
---|
[8] | 1026 | </t> |
---|
| 1027 | <t> |
---|
| 1028 | The HTTP version of an application is the highest HTTP version for |
---|
| 1029 | which the application is at least conditionally compliant. |
---|
| 1030 | </t> |
---|
| 1031 | <t> |
---|
| 1032 | Proxy and gateway applications need to be careful when forwarding |
---|
| 1033 | messages in protocol versions different from that of the application. |
---|
| 1034 | Since the protocol version indicates the protocol capability of the |
---|
| 1035 | sender, a proxy/gateway &MUST-NOT; send a message with a version |
---|
| 1036 | indicator which is greater than its actual version. If a higher |
---|
| 1037 | version request is received, the proxy/gateway &MUST; either downgrade |
---|
| 1038 | the request version, or respond with an error, or switch to tunnel |
---|
| 1039 | behavior. |
---|
| 1040 | </t> |
---|
| 1041 | <t> |
---|
| 1042 | Due to interoperability problems with HTTP/1.0 proxies discovered |
---|
[97] | 1043 | since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways |
---|
[8] | 1044 | &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version |
---|
| 1045 | they support. The proxy/gateway's response to that request &MUST; be in |
---|
| 1046 | the same major version as the request. |
---|
| 1047 | </t> |
---|
| 1048 | <t> |
---|
| 1049 | <list> |
---|
| 1050 | <t> |
---|
| 1051 | <x:h>Note:</x:h> Converting between versions of HTTP may involve modification |
---|
| 1052 | of header fields required or forbidden by the versions involved. |
---|
| 1053 | </t> |
---|
| 1054 | </list> |
---|
| 1055 | </t> |
---|
| 1056 | </section> |
---|
| 1057 | |
---|
| 1058 | <section title="Uniform Resource Identifiers" anchor="uri"> |
---|
| 1059 | <t> |
---|
| 1060 | URIs have been known by many names: WWW addresses, Universal Document |
---|
| 1061 | Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the |
---|
| 1062 | combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN) |
---|
| 1063 | <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are |
---|
| 1064 | simply formatted strings which identify--via name, location, or any |
---|
| 1065 | other characteristic--a resource. |
---|
| 1066 | </t> |
---|
| 1067 | |
---|
| 1068 | <section title="General Syntax" anchor="general.syntax"> |
---|
[229] | 1069 | <x:anchor-alias value="absoluteURI"/> |
---|
| 1070 | <x:anchor-alias value="authority"/> |
---|
| 1071 | <x:anchor-alias value="fragment"/> |
---|
| 1072 | <x:anchor-alias value="path-absolute"/> |
---|
| 1073 | <x:anchor-alias value="port"/> |
---|
| 1074 | <x:anchor-alias value="query"/> |
---|
| 1075 | <x:anchor-alias value="relativeURI"/> |
---|
| 1076 | <x:anchor-alias value="uri-host"/> |
---|
[8] | 1077 | <t> |
---|
| 1078 | URIs in HTTP can be represented in absolute form or relative to some |
---|
| 1079 | known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two |
---|
| 1080 | forms are differentiated by the fact that absolute URIs always begin |
---|
| 1081 | with a scheme name followed by a colon. For definitive information on |
---|
| 1082 | URL syntax and semantics, see "Uniform Resource Identifiers (URI): |
---|
[97] | 1083 | Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> |
---|
| 1084 | and <xref target="RFC1808"/>). This specification adopts the |
---|
[206] | 1085 | definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", |
---|
[185] | 1086 | "host", "abs_path", "query", and "authority" from that specification: |
---|
[8] | 1087 | </t> |
---|
[185] | 1088 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/> |
---|
[229] | 1089 | <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> |
---|
| 1090 | <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>> |
---|
| 1091 | <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>> |
---|
| 1092 | <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> |
---|
| 1093 | <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> |
---|
| 1094 | <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>> |
---|
| 1095 | <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>> |
---|
| 1096 | <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> |
---|
[185] | 1097 | </artwork></figure> |
---|
[8] | 1098 | <t> |
---|
[172] | 1099 | HTTP does not place any a priori limit on the length of |
---|
[8] | 1100 | a URI. Servers &MUST; be able to handle the URI of any resource they |
---|
| 1101 | serve, and &SHOULD; be able to handle URIs of unbounded length if they |
---|
| 1102 | provide GET-based forms that could generate such URIs. A server |
---|
| 1103 | &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer |
---|
[29] | 1104 | than the server can handle (see &status-414;). |
---|
[8] | 1105 | </t> |
---|
| 1106 | <t> |
---|
| 1107 | <list> |
---|
| 1108 | <t> |
---|
| 1109 | <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths |
---|
| 1110 | above 255 bytes, because some older client or proxy |
---|
| 1111 | implementations might not properly support these lengths. |
---|
| 1112 | </t> |
---|
| 1113 | </list> |
---|
| 1114 | </t> |
---|
| 1115 | </section> |
---|
| 1116 | |
---|
| 1117 | <section title="http URL" anchor="http.url"> |
---|
[229] | 1118 | <x:anchor-alias value="http-URL"/> |
---|
[312] | 1119 | <iref item="http URI scheme" primary="true"/> |
---|
| 1120 | <iref item="URI scheme" subitem="http" primary="true"/> |
---|
[8] | 1121 | <t> |
---|
| 1122 | The "http" scheme is used to locate network resources via the HTTP |
---|
| 1123 | protocol. This section defines the scheme-specific syntax and |
---|
| 1124 | semantics for http URLs. |
---|
| 1125 | </t> |
---|
[185] | 1126 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/> |
---|
[229] | 1127 | <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] |
---|
| 1128 | [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]] |
---|
[8] | 1129 | </artwork></figure> |
---|
| 1130 | <t> |
---|
| 1131 | If the port is empty or not given, port 80 is assumed. The semantics |
---|
| 1132 | are that the identified resource is located at the server listening |
---|
| 1133 | for TCP connections on that port of that host, and the Request-URI |
---|
[185] | 1134 | for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses |
---|
[97] | 1135 | in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If |
---|
[185] | 1136 | the path-absolute is not present in the URL, it &MUST; be given as "/" when |
---|
[8] | 1137 | used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy |
---|
| 1138 | receives a host name which is not a fully qualified domain name, it |
---|
| 1139 | &MAY; add its domain to the host name it received. If a proxy receives |
---|
| 1140 | a fully qualified domain name, the proxy &MUST-NOT; change the host |
---|
| 1141 | name. |
---|
| 1142 | </t> |
---|
[313] | 1143 | <t><list><t> |
---|
| 1144 | <iref item="https URI scheme"/> |
---|
| 1145 | <iref item="URI scheme" subitem="https"/> |
---|
| 1146 | <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>. |
---|
| 1147 | </t></list></t> |
---|
[8] | 1148 | </section> |
---|
| 1149 | |
---|
| 1150 | <section title="URI Comparison" anchor="uri.comparison"> |
---|
| 1151 | <t> |
---|
| 1152 | When comparing two URIs to decide if they match or not, a client |
---|
| 1153 | &SHOULD; use a case-sensitive octet-by-octet comparison of the entire |
---|
| 1154 | URIs, with these exceptions: |
---|
| 1155 | <list style="symbols"> |
---|
| 1156 | <t>A port that is empty or not given is equivalent to the default |
---|
| 1157 | port for that URI-reference;</t> |
---|
| 1158 | <t>Comparisons of host names &MUST; be case-insensitive;</t> |
---|
| 1159 | <t>Comparisons of scheme names &MUST; be case-insensitive;</t> |
---|
[185] | 1160 | <t>An empty path-absolute is equivalent to an path-absolute of "/".</t> |
---|
[8] | 1161 | </list> |
---|
| 1162 | </t> |
---|
| 1163 | <t> |
---|
[69] | 1164 | Characters other than those in the "reserved" set (see |
---|
[309] | 1165 | <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their |
---|
| 1166 | ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. |
---|
[8] | 1167 | </t> |
---|
| 1168 | <t> |
---|
| 1169 | For example, the following three URIs are equivalent: |
---|
| 1170 | </t> |
---|
| 1171 | <figure><artwork type="example"> |
---|
[90] | 1172 | http://example.com:80/~smith/home.html |
---|
| 1173 | http://EXAMPLE.com/%7Esmith/home.html |
---|
| 1174 | http://EXAMPLE.com:/%7esmith/home.html |
---|
[8] | 1175 | </artwork></figure> |
---|
| 1176 | </section> |
---|
| 1177 | </section> |
---|
| 1178 | |
---|
| 1179 | <section title="Date/Time Formats" anchor="date.time.formats"> |
---|
| 1180 | <section title="Full Date" anchor="full.date"> |
---|
[229] | 1181 | <x:anchor-alias value="HTTP-date"/> |
---|
[239] | 1182 | <x:anchor-alias value="obsolete-date"/> |
---|
[229] | 1183 | <x:anchor-alias value="rfc1123-date"/> |
---|
| 1184 | <x:anchor-alias value="rfc850-date"/> |
---|
| 1185 | <x:anchor-alias value="asctime-date"/> |
---|
| 1186 | <x:anchor-alias value="date1"/> |
---|
| 1187 | <x:anchor-alias value="date2"/> |
---|
| 1188 | <x:anchor-alias value="date3"/> |
---|
| 1189 | <x:anchor-alias value="rfc1123-date"/> |
---|
| 1190 | <x:anchor-alias value="time"/> |
---|
| 1191 | <x:anchor-alias value="wkday"/> |
---|
| 1192 | <x:anchor-alias value="weekday"/> |
---|
| 1193 | <x:anchor-alias value="month"/> |
---|
[8] | 1194 | <t> |
---|
| 1195 | HTTP applications have historically allowed three different formats |
---|
| 1196 | for the representation of date/time stamps: |
---|
| 1197 | </t> |
---|
| 1198 | <figure><artwork type="example"> |
---|
| 1199 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
---|
[82] | 1200 | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
---|
[8] | 1201 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
| 1202 | </artwork></figure> |
---|
| 1203 | <t> |
---|
| 1204 | The first format is preferred as an Internet standard and represents |
---|
[97] | 1205 | a fixed-length subset of that defined by <xref target="RFC1123"/> (an update to |
---|
| 1206 | <xref target="RFC822"/>). The other formats are described here only for |
---|
[82] | 1207 | compatibility with obsolete implementations. |
---|
[8] | 1208 | HTTP/1.1 clients and servers that parse the date value &MUST; accept |
---|
| 1209 | all three formats (for compatibility with HTTP/1.0), though they &MUST; |
---|
| 1210 | only generate the RFC 1123 format for representing HTTP-date values |
---|
| 1211 | in header fields. See <xref target="tolerant.applications"/> for further information. |
---|
| 1212 | </t> |
---|
| 1213 | <t><list><t> |
---|
| 1214 | <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in |
---|
| 1215 | accepting date values that may have been sent by non-HTTP |
---|
| 1216 | applications, as is sometimes the case when retrieving or posting |
---|
| 1217 | messages via proxies/gateways to SMTP or NNTP. |
---|
| 1218 | </t></list></t> |
---|
| 1219 | <t> |
---|
| 1220 | All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time |
---|
| 1221 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
| 1222 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
| 1223 | first two formats by the inclusion of "GMT" as the three-letter |
---|
| 1224 | abbreviation for time zone, and &MUST; be assumed when reading the |
---|
| 1225 | asctime format. HTTP-date is case sensitive and &MUST-NOT; include |
---|
| 1226 | additional LWS beyond that specifically included as SP in the |
---|
| 1227 | grammar. |
---|
| 1228 | </t> |
---|
[239] | 1229 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="obsolete-date"/><iref primary="true" item="Grammar" subitem="rfc850-date"/><iref primary="true" item="Grammar" subitem="asctime-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><iref primary="true" item="Grammar" subitem="time"/><iref primary="true" item="Grammar" subitem="wkday"/><iref primary="true" item="Grammar" subitem="weekday"/><iref primary="true" item="Grammar" subitem="month"/> |
---|
| 1230 | <x:ref>HTTP-date</x:ref> = <x:ref>rfc1123-date</x:ref> | <x:ref>obsolete-date</x:ref> |
---|
| 1231 | <x:ref>obsolete-date</x:ref> = <x:ref>rfc850-date</x:ref> | <x:ref>asctime-date</x:ref> |
---|
[273] | 1232 | <x:ref>rfc1123-date</x:ref> = <x:ref>wkday</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> time <x:ref>SP</x:ref> GMT |
---|
| 1233 | <x:ref>rfc850-date</x:ref> = <x:ref>weekday</x:ref> "," <x:ref>SP</x:ref> date2 <x:ref>SP</x:ref> time <x:ref>SP</x:ref> GMT |
---|
[229] | 1234 | <x:ref>asctime-date</x:ref> = <x:ref>wkday</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time</x:ref> <x:ref>SP</x:ref> 4<x:ref>DIGIT</x:ref> |
---|
| 1235 | <x:ref>date1</x:ref> = 2<x:ref>DIGIT</x:ref> <x:ref>SP</x:ref> <x:ref>month</x:ref> <x:ref>SP</x:ref> 4<x:ref>DIGIT</x:ref> |
---|
[135] | 1236 | ; day month year (e.g., 02 Jun 1982) |
---|
[229] | 1237 | <x:ref>date2</x:ref> = 2<x:ref>DIGIT</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref> |
---|
[135] | 1238 | ; day-month-year (e.g., 02-Jun-82) |
---|
[229] | 1239 | <x:ref>date3</x:ref> = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> | ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> )) |
---|
[135] | 1240 | ; month day (e.g., Jun 2) |
---|
[229] | 1241 | <x:ref>time</x:ref> = 2<x:ref>DIGIT</x:ref> ":" 2<x:ref>DIGIT</x:ref> ":" 2<x:ref>DIGIT</x:ref> |
---|
[135] | 1242 | ; 00:00:00 - 23:59:59 |
---|
[273] | 1243 | <x:ref>wkday</x:ref> = s-Mon | s-Tue | s-Wed |
---|
| 1244 | | s-Thu | s-Fri | s-Sat | s-Sun |
---|
| 1245 | <x:ref>weekday</x:ref> = l-Mon | l-Tue | l-Wed |
---|
| 1246 | | l-Thu | l-Fri | l-Sat | l-Sun |
---|
| 1247 | <x:ref>month</x:ref> = s-Jan | s-Feb | s-Mar | s-Apr |
---|
| 1248 | | s-May | s-Jun | s-Jul | s-Aug |
---|
| 1249 | | s-Sep | s-Oct | s-Nov | s-Dec |
---|
| 1250 | |
---|
| 1251 | GMT = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive |
---|
| 1252 | |
---|
| 1253 | s-Mon = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive |
---|
| 1254 | s-Tue = <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive |
---|
| 1255 | s-Wed = <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive |
---|
| 1256 | s-Thu = <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive |
---|
| 1257 | s-Fri = <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive |
---|
| 1258 | s-Sat = <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive |
---|
| 1259 | s-Sun = <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive |
---|
| 1260 | |
---|
| 1261 | l-Mon = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive |
---|
| 1262 | l-Tue = <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive |
---|
| 1263 | l-Wed = <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive |
---|
| 1264 | l-Thu = <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive |
---|
| 1265 | l-Fri = <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive |
---|
| 1266 | l-Sat = <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive |
---|
| 1267 | l-Sun = <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive |
---|
| 1268 | |
---|
| 1269 | s-Jan = <x:abnf-char-sequence>"Jan"</x:abnf-char-sequence> ; "Jan", case-sensitive |
---|
| 1270 | s-Feb = <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive |
---|
| 1271 | s-Mar = <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive |
---|
| 1272 | s-Apr = <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive |
---|
| 1273 | s-May = <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive |
---|
| 1274 | s-Jun = <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive |
---|
| 1275 | s-Jul = <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive |
---|
| 1276 | s-Aug = <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive |
---|
| 1277 | s-Sep = <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive |
---|
| 1278 | s-Oct = <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive |
---|
| 1279 | s-Nov = <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive |
---|
| 1280 | s-Dec = <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive |
---|
[8] | 1281 | </artwork></figure> |
---|
| 1282 | <t> |
---|
| 1283 | <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only |
---|
| 1284 | to their usage within the protocol stream. Clients and servers are |
---|
| 1285 | not required to use these formats for user presentation, request |
---|
| 1286 | logging, etc. |
---|
| 1287 | </t> |
---|
| 1288 | </section> |
---|
| 1289 | </section> |
---|
| 1290 | |
---|
| 1291 | <section title="Transfer Codings" anchor="transfer.codings"> |
---|
[229] | 1292 | <x:anchor-alias value="parameter"/> |
---|
| 1293 | <x:anchor-alias value="transfer-coding"/> |
---|
| 1294 | <x:anchor-alias value="transfer-extension"/> |
---|
[8] | 1295 | <t> |
---|
| 1296 | Transfer-coding values are used to indicate an encoding |
---|
| 1297 | transformation that has been, can be, or may need to be applied to an |
---|
| 1298 | entity-body in order to ensure "safe transport" through the network. |
---|
| 1299 | This differs from a content coding in that the transfer-coding is a |
---|
| 1300 | property of the message, not of the original entity. |
---|
| 1301 | </t> |
---|
| 1302 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/> |
---|
[229] | 1303 | <x:ref>transfer-coding</x:ref> = "chunked" | <x:ref>transfer-extension</x:ref> |
---|
| 1304 | <x:ref>transfer-extension</x:ref> = <x:ref>token</x:ref> *( ";" <x:ref>parameter</x:ref> ) |
---|
[8] | 1305 | </artwork></figure> |
---|
[229] | 1306 | <t anchor="rule.parameter"> |
---|
| 1307 | <x:anchor-alias value="attribute"/> |
---|
| 1308 | <x:anchor-alias value="parameter"/> |
---|
| 1309 | <x:anchor-alias value="value"/> |
---|
[8] | 1310 | Parameters are in the form of attribute/value pairs. |
---|
| 1311 | </t> |
---|
| 1312 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/> |
---|
[229] | 1313 | <x:ref>parameter</x:ref> = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref> |
---|
| 1314 | <x:ref>attribute</x:ref> = <x:ref>token</x:ref> |
---|
| 1315 | <x:ref>value</x:ref> = <x:ref>token</x:ref> | <x:ref>quoted-string</x:ref> |
---|
[8] | 1316 | </artwork></figure> |
---|
| 1317 | <t> |
---|
| 1318 | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
---|
| 1319 | transfer-coding values in the TE header field (<xref target="header.te"/>) and in |
---|
| 1320 | the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). |
---|
| 1321 | </t> |
---|
| 1322 | <t> |
---|
| 1323 | Whenever a transfer-coding is applied to a message-body, the set of |
---|
[276] | 1324 | transfer-codings &MUST; include "chunked", unless the message indicates it |
---|
| 1325 | is terminated by closing the connection. When the "chunked" transfer-coding |
---|
[8] | 1326 | is used, it &MUST; be the last transfer-coding applied to the |
---|
| 1327 | message-body. The "chunked" transfer-coding &MUST-NOT; be applied more |
---|
| 1328 | than once to a message-body. These rules allow the recipient to |
---|
| 1329 | determine the transfer-length of the message (<xref target="message.length"/>). |
---|
| 1330 | </t> |
---|
| 1331 | <t> |
---|
| 1332 | Transfer-codings are analogous to the Content-Transfer-Encoding |
---|
| 1333 | values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of |
---|
| 1334 | binary data over a 7-bit transport service. However, safe transport |
---|
| 1335 | has a different focus for an 8bit-clean transfer protocol. In HTTP, |
---|
| 1336 | the only unsafe characteristic of message-bodies is the difficulty in |
---|
[29] | 1337 | determining the exact body length (<xref target="message.length"/>), or the desire to |
---|
[8] | 1338 | encrypt data over a shared transport. |
---|
| 1339 | </t> |
---|
| 1340 | <t> |
---|
| 1341 | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
---|
| 1342 | transfer-coding value tokens. Initially, the registry contains the |
---|
[85] | 1343 | following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), |
---|
[115] | 1344 | "gzip", "compress", and "deflate" (&content-codings;). |
---|
[8] | 1345 | </t> |
---|
| 1346 | <t> |
---|
| 1347 | New transfer-coding value tokens &SHOULD; be registered in the same way |
---|
[115] | 1348 | as new content-coding value tokens (&content-codings;). |
---|
[8] | 1349 | </t> |
---|
| 1350 | <t> |
---|
| 1351 | A server which receives an entity-body with a transfer-coding it does |
---|
[137] | 1352 | not understand &SHOULD; return 501 (Not Implemented), and close the |
---|
[8] | 1353 | connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0 |
---|
| 1354 | client. |
---|
| 1355 | </t> |
---|
| 1356 | |
---|
| 1357 | <section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding"> |
---|
[229] | 1358 | <x:anchor-alias value="chunk"/> |
---|
| 1359 | <x:anchor-alias value="Chunked-Body"/> |
---|
| 1360 | <x:anchor-alias value="chunk-data"/> |
---|
| 1361 | <x:anchor-alias value="chunk-extension"/> |
---|
| 1362 | <x:anchor-alias value="chunk-ext-name"/> |
---|
| 1363 | <x:anchor-alias value="chunk-ext-val"/> |
---|
| 1364 | <x:anchor-alias value="chunk-size"/> |
---|
| 1365 | <x:anchor-alias value="last-chunk"/> |
---|
| 1366 | <x:anchor-alias value="trailer-part"/> |
---|
[8] | 1367 | <t> |
---|
| 1368 | The chunked encoding modifies the body of a message in order to |
---|
| 1369 | transfer it as a series of chunks, each with its own size indicator, |
---|
| 1370 | followed by an &OPTIONAL; trailer containing entity-header fields. This |
---|
| 1371 | allows dynamically produced content to be transferred along with the |
---|
| 1372 | information necessary for the recipient to verify that it has |
---|
| 1373 | received the full message. |
---|
| 1374 | </t> |
---|
[185] | 1375 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-extension"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer-part"/> |
---|
[229] | 1376 | <x:ref>Chunked-Body</x:ref> = *<x:ref>chunk</x:ref> |
---|
| 1377 | <x:ref>last-chunk</x:ref> |
---|
| 1378 | <x:ref>trailer-part</x:ref> |
---|
| 1379 | <x:ref>CRLF</x:ref> |
---|
[135] | 1380 | |
---|
[229] | 1381 | <x:ref>chunk</x:ref> = <x:ref>chunk-size</x:ref> [ <x:ref>chunk-extension</x:ref> ] <x:ref>CRLF</x:ref> |
---|
| 1382 | <x:ref>chunk-data</x:ref> <x:ref>CRLF</x:ref> |
---|
[309] | 1383 | <x:ref>chunk-size</x:ref> = 1*<x:ref>HEXDIG</x:ref> |
---|
[229] | 1384 | <x:ref>last-chunk</x:ref> = 1*("0") [ <x:ref>chunk-extension</x:ref> ] <x:ref>CRLF</x:ref> |
---|
[135] | 1385 | |
---|
[229] | 1386 | <x:ref>chunk-extension</x:ref>= *( ";" <x:ref>chunk-ext-name</x:ref> [ "=" <x:ref>chunk-ext-val</x:ref> ] ) |
---|
| 1387 | <x:ref>chunk-ext-name</x:ref> = <x:ref>token</x:ref> |
---|
| 1388 | <x:ref>chunk-ext-val</x:ref> = <x:ref>token</x:ref> | <x:ref>quoted-string</x:ref> |
---|
| 1389 | <x:ref>chunk-data</x:ref> = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets |
---|
| 1390 | <x:ref>trailer-part</x:ref> = *(<x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref>) |
---|
[8] | 1391 | </artwork></figure> |
---|
| 1392 | <t> |
---|
| 1393 | The chunk-size field is a string of hex digits indicating the size of |
---|
[70] | 1394 | the chunk-data in octets. The chunked encoding is ended by any chunk whose size is |
---|
[8] | 1395 | zero, followed by the trailer, which is terminated by an empty line. |
---|
| 1396 | </t> |
---|
| 1397 | <t> |
---|
| 1398 | The trailer allows the sender to include additional HTTP header |
---|
| 1399 | fields at the end of the message. The Trailer header field can be |
---|
| 1400 | used to indicate which header fields are included in a trailer (see |
---|
| 1401 | <xref target="header.trailer"/>). |
---|
| 1402 | </t> |
---|
| 1403 | <t> |
---|
| 1404 | A server using chunked transfer-coding in a response &MUST-NOT; use the |
---|
| 1405 | trailer for any header fields unless at least one of the following is |
---|
| 1406 | true: |
---|
| 1407 | <list style="numbers"> |
---|
| 1408 | <t>the request included a TE header field that indicates "trailers" is |
---|
| 1409 | acceptable in the transfer-coding of the response, as described in |
---|
| 1410 | <xref target="header.te"/>; or,</t> |
---|
| 1411 | |
---|
| 1412 | <t>the server is the origin server for the response, the trailer |
---|
| 1413 | fields consist entirely of optional metadata, and the recipient |
---|
| 1414 | could use the message (in a manner acceptable to the origin server) |
---|
| 1415 | without receiving this metadata. In other words, the origin server |
---|
| 1416 | is willing to accept the possibility that the trailer fields might |
---|
| 1417 | be silently discarded along the path to the client.</t> |
---|
| 1418 | </list> |
---|
| 1419 | </t> |
---|
| 1420 | <t> |
---|
| 1421 | This requirement prevents an interoperability failure when the |
---|
| 1422 | message is being received by an HTTP/1.1 (or later) proxy and |
---|
| 1423 | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
---|
| 1424 | compliance with the protocol would have necessitated a possibly |
---|
| 1425 | infinite buffer on the proxy. |
---|
| 1426 | </t> |
---|
| 1427 | <t> |
---|
[29] | 1428 | A process for decoding the "chunked" transfer-coding |
---|
| 1429 | can be represented in pseudo-code as: |
---|
[8] | 1430 | </t> |
---|
[29] | 1431 | <figure><artwork type="code"> |
---|
| 1432 | length := 0 |
---|
| 1433 | read chunk-size, chunk-extension (if any) and CRLF |
---|
| 1434 | while (chunk-size > 0) { |
---|
| 1435 | read chunk-data and CRLF |
---|
| 1436 | append chunk-data to entity-body |
---|
| 1437 | length := length + chunk-size |
---|
| 1438 | read chunk-size and CRLF |
---|
| 1439 | } |
---|
| 1440 | read entity-header |
---|
| 1441 | while (entity-header not empty) { |
---|
| 1442 | append entity-header to existing header fields |
---|
| 1443 | read entity-header |
---|
| 1444 | } |
---|
| 1445 | Content-Length := length |
---|
| 1446 | Remove "chunked" from Transfer-Encoding |
---|
| 1447 | </artwork></figure> |
---|
[8] | 1448 | <t> |
---|
| 1449 | All HTTP/1.1 applications &MUST; be able to receive and decode the |
---|
| 1450 | "chunked" transfer-coding, and &MUST; ignore chunk-extension extensions |
---|
| 1451 | they do not understand. |
---|
| 1452 | </t> |
---|
| 1453 | </section> |
---|
| 1454 | </section> |
---|
| 1455 | |
---|
[190] | 1456 | <section title="Product Tokens" anchor="product.tokens"> |
---|
[229] | 1457 | <x:anchor-alias value="product"/> |
---|
| 1458 | <x:anchor-alias value="product-version"/> |
---|
[190] | 1459 | <t> |
---|
| 1460 | Product tokens are used to allow communicating applications to |
---|
| 1461 | identify themselves by software name and version. Most fields using |
---|
| 1462 | product tokens also allow sub-products which form a significant part |
---|
| 1463 | of the application to be listed, separated by white space. By |
---|
| 1464 | convention, the products are listed in order of their significance |
---|
| 1465 | for identifying the application. |
---|
| 1466 | </t> |
---|
| 1467 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> |
---|
[229] | 1468 | <x:ref>product</x:ref> = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>] |
---|
| 1469 | <x:ref>product-version</x:ref> = <x:ref>token</x:ref> |
---|
[190] | 1470 | </artwork></figure> |
---|
| 1471 | <t> |
---|
| 1472 | Examples: |
---|
| 1473 | </t> |
---|
| 1474 | <figure><artwork type="example"> |
---|
| 1475 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
| 1476 | Server: Apache/0.8.4 |
---|
| 1477 | </artwork></figure> |
---|
| 1478 | <t> |
---|
| 1479 | Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be |
---|
| 1480 | used for advertising or other non-essential information. Although any |
---|
| 1481 | token character &MAY; appear in a product-version, this token &SHOULD; |
---|
| 1482 | only be used for a version identifier (i.e., successive versions of |
---|
| 1483 | the same product &SHOULD; only differ in the product-version portion of |
---|
| 1484 | the product value). |
---|
| 1485 | </t> |
---|
[8] | 1486 | </section> |
---|
| 1487 | |
---|
[190] | 1488 | </section> |
---|
| 1489 | |
---|
[8] | 1490 | <section title="HTTP Message" anchor="http.message"> |
---|
| 1491 | |
---|
| 1492 | <section title="Message Types" anchor="message.types"> |
---|
[229] | 1493 | <x:anchor-alias value="generic-message"/> |
---|
| 1494 | <x:anchor-alias value="HTTP-message"/> |
---|
| 1495 | <x:anchor-alias value="start-line"/> |
---|
[8] | 1496 | <t> |
---|
| 1497 | HTTP messages consist of requests from client to server and responses |
---|
| 1498 | from server to client. |
---|
| 1499 | </t> |
---|
| 1500 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/> |
---|
[229] | 1501 | <x:ref>HTTP-message</x:ref> = <x:ref>Request</x:ref> | <x:ref>Response</x:ref> ; HTTP/1.1 messages |
---|
[8] | 1502 | </artwork></figure> |
---|
| 1503 | <t> |
---|
| 1504 | Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic |
---|
[133] | 1505 | message format of <xref target="RFC2822"/> for transferring entities (the payload |
---|
[8] | 1506 | of the message). Both types of message consist of a start-line, zero |
---|
| 1507 | or more header fields (also known as "headers"), an empty line (i.e., |
---|
| 1508 | a line with nothing preceding the CRLF) indicating the end of the |
---|
| 1509 | header fields, and possibly a message-body. |
---|
| 1510 | </t> |
---|
| 1511 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/> |
---|
[229] | 1512 | <x:ref>generic-message</x:ref> = <x:ref>start-line</x:ref> |
---|
| 1513 | *(<x:ref>message-header</x:ref> <x:ref>CRLF</x:ref>) |
---|
| 1514 | <x:ref>CRLF</x:ref> |
---|
| 1515 | [ <x:ref>message-body</x:ref> ] |
---|
| 1516 | <x:ref>start-line</x:ref> = <x:ref>Request-Line</x:ref> | <x:ref>Status-Line</x:ref> |
---|
[8] | 1517 | </artwork></figure> |
---|
| 1518 | <t> |
---|
| 1519 | In the interest of robustness, servers &SHOULD; ignore any empty |
---|
| 1520 | line(s) received where a Request-Line is expected. In other words, if |
---|
| 1521 | the server is reading the protocol stream at the beginning of a |
---|
| 1522 | message and receives a CRLF first, it should ignore the CRLF. |
---|
| 1523 | </t> |
---|
| 1524 | <t> |
---|
| 1525 | Certain buggy HTTP/1.0 client implementations generate extra CRLF's |
---|
| 1526 | after a POST request. To restate what is explicitly forbidden by the |
---|
| 1527 | BNF, an HTTP/1.1 client &MUST-NOT; preface or follow a request with an |
---|
| 1528 | extra CRLF. |
---|
| 1529 | </t> |
---|
| 1530 | </section> |
---|
| 1531 | |
---|
| 1532 | <section title="Message Headers" anchor="message.headers"> |
---|
[229] | 1533 | <x:anchor-alias value="field-content"/> |
---|
| 1534 | <x:anchor-alias value="field-name"/> |
---|
| 1535 | <x:anchor-alias value="field-value"/> |
---|
| 1536 | <x:anchor-alias value="message-header"/> |
---|
[8] | 1537 | <t> |
---|
| 1538 | HTTP header fields, which include general-header (<xref target="general.header.fields"/>), |
---|
[29] | 1539 | request-header (&request-header-fields;), response-header (&response-header-fields;), and |
---|
| 1540 | entity-header (&entity-header-fields;) fields, follow the same generic format as |
---|
[133] | 1541 | that given in <xref target="RFC2822" x:fmt="of" x:sec="2.1"/>. Each header field consists |
---|
[8] | 1542 | of a name followed by a colon (":") and the field value. Field names |
---|
| 1543 | are case-insensitive. The field value &MAY; be preceded by any amount |
---|
| 1544 | of LWS, though a single SP is preferred. Header fields can be |
---|
| 1545 | extended over multiple lines by preceding each extra line with at |
---|
[154] | 1546 | least one SP or HTAB. Applications ought to follow "common form", where |
---|
[8] | 1547 | one is known or indicated, when generating HTTP constructs, since |
---|
| 1548 | there might exist some implementations that fail to accept anything |
---|
| 1549 | beyond the common forms. |
---|
| 1550 | </t> |
---|
| 1551 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/> |
---|
[229] | 1552 | <x:ref>message-header</x:ref> = <x:ref>field-name</x:ref> ":" [ <x:ref>field-value</x:ref> ] |
---|
| 1553 | <x:ref>field-name</x:ref> = <x:ref>token</x:ref> |
---|
| 1554 | <x:ref>field-value</x:ref> = *( <x:ref>field-content</x:ref> | <x:ref>LWS</x:ref> ) |
---|
| 1555 | <x:ref>field-content</x:ref> = <field content> |
---|
| 1556 | ; the <x:ref>OCTET</x:ref>s making up the field-value |
---|
| 1557 | ; and consisting of either *<x:ref>TEXT</x:ref> or combinations |
---|
| 1558 | ; of <x:ref>token</x:ref>, <x:ref>separators</x:ref>, and <x:ref>quoted-string</x:ref> |
---|
[8] | 1559 | </artwork></figure> |
---|
| 1560 | <t> |
---|
| 1561 | The field-content does not include any leading or trailing LWS: |
---|
| 1562 | linear white space occurring before the first non-whitespace |
---|
| 1563 | character of the field-value or after the last non-whitespace |
---|
| 1564 | character of the field-value. Such leading or trailing LWS &MAY; be |
---|
| 1565 | removed without changing the semantics of the field value. Any LWS |
---|
| 1566 | that occurs between field-content &MAY; be replaced with a single SP |
---|
| 1567 | before interpreting the field value or forwarding the message |
---|
| 1568 | downstream. |
---|
| 1569 | </t> |
---|
| 1570 | <t> |
---|
| 1571 | The order in which header fields with differing field names are |
---|
| 1572 | received is not significant. However, it is "good practice" to send |
---|
| 1573 | general-header fields first, followed by request-header or response-header |
---|
| 1574 | fields, and ending with the entity-header fields. |
---|
| 1575 | </t> |
---|
| 1576 | <t> |
---|
| 1577 | Multiple message-header fields with the same field-name &MAY; be |
---|
| 1578 | present in a message if and only if the entire field-value for that |
---|
| 1579 | header field is defined as a comma-separated list [i.e., #(values)]. |
---|
| 1580 | It &MUST; be possible to combine the multiple header fields into one |
---|
| 1581 | "field-name: field-value" pair, without changing the semantics of the |
---|
| 1582 | message, by appending each subsequent field-value to the first, each |
---|
| 1583 | separated by a comma. The order in which header fields with the same |
---|
| 1584 | field-name are received is therefore significant to the |
---|
| 1585 | interpretation of the combined field value, and thus a proxy &MUST-NOT; |
---|
| 1586 | change the order of these field values when a message is forwarded. |
---|
| 1587 | </t> |
---|
[310] | 1588 | <t> |
---|
| 1589 | <list><t> |
---|
| 1590 | <x:h>Note:</x:h> the "Set-Cookie" header as implemented in |
---|
| 1591 | practice (as opposed to how it is specified in <xref target="RFC2109"/>) |
---|
| 1592 | can occur multiple times, but does not use the list syntax, and thus cannot |
---|
| 1593 | be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/> |
---|
| 1594 | for details.) Also note that the Set-Cookie2 header specified in |
---|
| 1595 | <xref target="RFC2965"/> does not share this problem. |
---|
| 1596 | </t></list> |
---|
| 1597 | </t> |
---|
| 1598 | |
---|
[8] | 1599 | </section> |
---|
| 1600 | |
---|
| 1601 | <section title="Message Body" anchor="message.body"> |
---|
[229] | 1602 | <x:anchor-alias value="message-body"/> |
---|
[8] | 1603 | <t> |
---|
| 1604 | The message-body (if any) of an HTTP message is used to carry the |
---|
| 1605 | entity-body associated with the request or response. The message-body |
---|
| 1606 | differs from the entity-body only when a transfer-coding has been |
---|
| 1607 | applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). |
---|
| 1608 | </t> |
---|
| 1609 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/> |
---|
[229] | 1610 | <x:ref>message-body</x:ref> = <x:ref>entity-body</x:ref> |
---|
| 1611 | | <entity-body encoded as per <x:ref>Transfer-Encoding</x:ref>> |
---|
[8] | 1612 | </artwork></figure> |
---|
| 1613 | <t> |
---|
| 1614 | Transfer-Encoding &MUST; be used to indicate any transfer-codings |
---|
| 1615 | applied by an application to ensure safe and proper transfer of the |
---|
| 1616 | message. Transfer-Encoding is a property of the message, not of the |
---|
| 1617 | entity, and thus &MAY; be added or removed by any application along the |
---|
| 1618 | request/response chain. (However, <xref target="transfer.codings"/> places restrictions on |
---|
| 1619 | when certain transfer-codings may be used.) |
---|
| 1620 | </t> |
---|
| 1621 | <t> |
---|
| 1622 | The rules for when a message-body is allowed in a message differ for |
---|
| 1623 | requests and responses. |
---|
| 1624 | </t> |
---|
| 1625 | <t> |
---|
| 1626 | The presence of a message-body in a request is signaled by the |
---|
| 1627 | inclusion of a Content-Length or Transfer-Encoding header field in |
---|
| 1628 | the request's message-headers. A message-body &MUST-NOT; be included in |
---|
[29] | 1629 | a request if the specification of the request method (&method;) |
---|
[171] | 1630 | explicitly disallows an entity-body in requests. |
---|
| 1631 | When a request message contains both a message-body of non-zero |
---|
| 1632 | length and a method that does not define any semantics for that |
---|
| 1633 | request message-body, then an origin server &SHOULD; either ignore |
---|
| 1634 | the message-body or respond with an appropriate error message |
---|
| 1635 | (e.g., 413). A proxy or gateway, when presented the same request, |
---|
| 1636 | &SHOULD; either forward the request inbound with the message-body or |
---|
| 1637 | ignore the message-body when determining a response. |
---|
[8] | 1638 | </t> |
---|
| 1639 | <t> |
---|
| 1640 | For response messages, whether or not a message-body is included with |
---|
| 1641 | a message is dependent on both the request method and the response |
---|
| 1642 | status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method |
---|
| 1643 | &MUST-NOT; include a message-body, even though the presence of entity-header |
---|
| 1644 | fields might lead one to believe they do. All 1xx |
---|
[137] | 1645 | (informational), 204 (No Content), and 304 (Not Modified) responses |
---|
[8] | 1646 | &MUST-NOT; include a message-body. All other responses do include a |
---|
| 1647 | message-body, although it &MAY; be of zero length. |
---|
| 1648 | </t> |
---|
| 1649 | </section> |
---|
| 1650 | |
---|
| 1651 | <section title="Message Length" anchor="message.length"> |
---|
| 1652 | <t> |
---|
| 1653 | The transfer-length of a message is the length of the message-body as |
---|
| 1654 | it appears in the message; that is, after any transfer-codings have |
---|
| 1655 | been applied. When a message-body is included with a message, the |
---|
| 1656 | transfer-length of that body is determined by one of the following |
---|
| 1657 | (in order of precedence): |
---|
| 1658 | </t> |
---|
| 1659 | <t> |
---|
| 1660 | <list style="numbers"> |
---|
| 1661 | <x:lt><t> |
---|
| 1662 | Any response message which "&MUST-NOT;" include a message-body (such |
---|
| 1663 | as the 1xx, 204, and 304 responses and any response to a HEAD |
---|
| 1664 | request) is always terminated by the first empty line after the |
---|
| 1665 | header fields, regardless of the entity-header fields present in |
---|
| 1666 | the message. |
---|
| 1667 | </t></x:lt> |
---|
| 1668 | <x:lt><t> |
---|
[85] | 1669 | If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>) |
---|
[276] | 1670 | is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>) |
---|
| 1671 | is used, the transfer-length is defined by the use of this transfer-coding. |
---|
| 1672 | If a Transfer-Encoding header field is present and the "chunked" transfer-coding |
---|
| 1673 | is not present, the transfer-length is defined by the sender closing the connection. |
---|
[8] | 1674 | </t></x:lt> |
---|
| 1675 | <x:lt><t> |
---|
| 1676 | If a Content-Length header field (<xref target="header.content-length"/>) is present, its |
---|
| 1677 | decimal value in OCTETs represents both the entity-length and the |
---|
| 1678 | transfer-length. The Content-Length header field &MUST-NOT; be sent |
---|
| 1679 | if these two lengths are different (i.e., if a Transfer-Encoding |
---|
| 1680 | header field is present). If a message is received with both a |
---|
| 1681 | Transfer-Encoding header field and a Content-Length header field, |
---|
| 1682 | the latter &MUST; be ignored. |
---|
| 1683 | </t></x:lt> |
---|
| 1684 | <x:lt><t> |
---|
| 1685 | If the message uses the media type "multipart/byteranges", and the |
---|
[71] | 1686 | transfer-length is not otherwise specified, then this self-delimiting |
---|
[8] | 1687 | media type defines the transfer-length. This media type |
---|
[71] | 1688 | &MUST-NOT; be used unless the sender knows that the recipient can parse |
---|
| 1689 | it; the presence in a request of a Range header with multiple byte-range |
---|
| 1690 | specifiers from a 1.1 client implies that the client can parse |
---|
[8] | 1691 | multipart/byteranges responses. |
---|
| 1692 | <list style="empty"><t> |
---|
| 1693 | A range header might be forwarded by a 1.0 proxy that does not |
---|
| 1694 | understand multipart/byteranges; in this case the server &MUST; |
---|
| 1695 | delimit the message using methods defined in items 1, 3 or 5 of |
---|
| 1696 | this section. |
---|
| 1697 | </t></list> |
---|
| 1698 | </t></x:lt> |
---|
| 1699 | <x:lt><t> |
---|
| 1700 | By the server closing the connection. (Closing the connection |
---|
| 1701 | cannot be used to indicate the end of a request body, since that |
---|
| 1702 | would leave no possibility for the server to send back a response.) |
---|
| 1703 | </t></x:lt> |
---|
| 1704 | </list> |
---|
| 1705 | </t> |
---|
| 1706 | <t> |
---|
| 1707 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
---|
| 1708 | containing a message-body &MUST; include a valid Content-Length header |
---|
| 1709 | field unless the server is known to be HTTP/1.1 compliant. If a |
---|
| 1710 | request contains a message-body and a Content-Length is not given, |
---|
[137] | 1711 | the server &SHOULD; respond with 400 (Bad Request) if it cannot |
---|
| 1712 | determine the length of the message, or with 411 (Length Required) if |
---|
[8] | 1713 | it wishes to insist on receiving a valid Content-Length. |
---|
| 1714 | </t> |
---|
| 1715 | <t> |
---|
| 1716 | All HTTP/1.1 applications that receive entities &MUST; accept the |
---|
| 1717 | "chunked" transfer-coding (<xref target="transfer.codings"/>), thus allowing this mechanism |
---|
| 1718 | to be used for messages when the message length cannot be determined |
---|
| 1719 | in advance. |
---|
| 1720 | </t> |
---|
| 1721 | <t> |
---|
| 1722 | Messages &MUST-NOT; include both a Content-Length header field and a |
---|
[85] | 1723 | transfer-coding. If the message does include a |
---|
[8] | 1724 | transfer-coding, the Content-Length &MUST; be ignored. |
---|
| 1725 | </t> |
---|
| 1726 | <t> |
---|
| 1727 | When a Content-Length is given in a message where a message-body is |
---|
| 1728 | allowed, its field value &MUST; exactly match the number of OCTETs in |
---|
| 1729 | the message-body. HTTP/1.1 user agents &MUST; notify the user when an |
---|
| 1730 | invalid length is received and detected. |
---|
| 1731 | </t> |
---|
| 1732 | </section> |
---|
| 1733 | |
---|
| 1734 | <section title="General Header Fields" anchor="general.header.fields"> |
---|
[229] | 1735 | <x:anchor-alias value="general-header"/> |
---|
[8] | 1736 | <t> |
---|
| 1737 | There are a few header fields which have general applicability for |
---|
| 1738 | both request and response messages, but which do not apply to the |
---|
| 1739 | entity being transferred. These header fields apply only to the |
---|
| 1740 | message being transmitted. |
---|
| 1741 | </t> |
---|
| 1742 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="general-header"/> |
---|
[229] | 1743 | <x:ref>general-header</x:ref> = <x:ref>Cache-Control</x:ref> ; &header-cache-control; |
---|
| 1744 | | <x:ref>Connection</x:ref> ; <xref target="header.connection"/> |
---|
| 1745 | | <x:ref>Date</x:ref> ; <xref target="header.date"/> |
---|
| 1746 | | <x:ref>Pragma</x:ref> ; &header-pragma; |
---|
| 1747 | | <x:ref>Trailer</x:ref> ; <xref target="header.trailer"/> |
---|
| 1748 | | <x:ref>Transfer-Encoding</x:ref> ; <xref target="header.transfer-encoding"/> |
---|
| 1749 | | <x:ref>Upgrade</x:ref> ; <xref target="header.upgrade"/> |
---|
| 1750 | | <x:ref>Via</x:ref> ; <xref target="header.via"/> |
---|
| 1751 | | <x:ref>Warning</x:ref> ; &header-warning; |
---|
[8] | 1752 | </artwork></figure> |
---|
| 1753 | <t> |
---|
| 1754 | General-header field names can be extended reliably only in |
---|
| 1755 | combination with a change in the protocol version. However, new or |
---|
| 1756 | experimental header fields may be given the semantics of general |
---|
| 1757 | header fields if all parties in the communication recognize them to |
---|
| 1758 | be general-header fields. Unrecognized header fields are treated as |
---|
| 1759 | entity-header fields. |
---|
| 1760 | </t> |
---|
| 1761 | </section> |
---|
| 1762 | </section> |
---|
| 1763 | |
---|
| 1764 | <section title="Request" anchor="request"> |
---|
[229] | 1765 | <x:anchor-alias value="Request"/> |
---|
[8] | 1766 | <t> |
---|
| 1767 | A request message from a client to a server includes, within the |
---|
| 1768 | first line of that message, the method to be applied to the resource, |
---|
| 1769 | the identifier of the resource, and the protocol version in use. |
---|
| 1770 | </t> |
---|
[29] | 1771 | <!-- Host ; should be moved here eventually --> |
---|
[8] | 1772 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/> |
---|
[229] | 1773 | <x:ref>Request</x:ref> = <x:ref>Request-Line</x:ref> ; <xref target="request-line"/> |
---|
| 1774 | *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> |
---|
| 1775 | | <x:ref>request-header</x:ref> ; &request-header-fields; |
---|
| 1776 | | <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref>) ; &entity-header-fields; |
---|
| 1777 | <x:ref>CRLF</x:ref> |
---|
| 1778 | [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> |
---|
[8] | 1779 | </artwork></figure> |
---|
| 1780 | |
---|
| 1781 | <section title="Request-Line" anchor="request-line"> |
---|
[229] | 1782 | <x:anchor-alias value="Request-Line"/> |
---|
[8] | 1783 | <t> |
---|
| 1784 | The Request-Line begins with a method token, followed by the |
---|
| 1785 | Request-URI and the protocol version, and ending with CRLF. The |
---|
| 1786 | elements are separated by SP characters. No CR or LF is allowed |
---|
| 1787 | except in the final CRLF sequence. |
---|
| 1788 | </t> |
---|
| 1789 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/> |
---|
[229] | 1790 | <x:ref>Request-Line</x:ref> = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>Request-URI</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref> |
---|
[8] | 1791 | </artwork></figure> |
---|
| 1792 | |
---|
| 1793 | <section title="Method" anchor="method"> |
---|
[229] | 1794 | <x:anchor-alias value="Method"/> |
---|
[8] | 1795 | <t> |
---|
| 1796 | The Method token indicates the method to be performed on the |
---|
| 1797 | resource identified by the Request-URI. The method is case-sensitive. |
---|
| 1798 | </t> |
---|
| 1799 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> |
---|
[229] | 1800 | <x:ref>Method</x:ref> = <x:ref>token</x:ref> |
---|
[8] | 1801 | </artwork></figure> |
---|
| 1802 | </section> |
---|
| 1803 | |
---|
| 1804 | <section title="Request-URI" anchor="request-uri"> |
---|
[229] | 1805 | <x:anchor-alias value="Request-URI"/> |
---|
[8] | 1806 | <t> |
---|
| 1807 | The Request-URI is a Uniform Resource Identifier (<xref target="uri"/>) and |
---|
| 1808 | identifies the resource upon which to apply the request. |
---|
| 1809 | </t> |
---|
| 1810 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/> |
---|
[229] | 1811 | <x:ref>Request-URI</x:ref> = "*" |
---|
| 1812 | | <x:ref>absoluteURI</x:ref> |
---|
| 1813 | | ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) |
---|
| 1814 | | <x:ref>authority</x:ref> |
---|
[8] | 1815 | </artwork></figure> |
---|
| 1816 | <t> |
---|
| 1817 | The four options for Request-URI are dependent on the nature of the |
---|
| 1818 | request. The asterisk "*" means that the request does not apply to a |
---|
| 1819 | particular resource, but to the server itself, and is only allowed |
---|
| 1820 | when the method used does not necessarily apply to a resource. One |
---|
| 1821 | example would be |
---|
| 1822 | </t> |
---|
| 1823 | <figure><artwork type="example"> |
---|
| 1824 | OPTIONS * HTTP/1.1 |
---|
| 1825 | </artwork></figure> |
---|
| 1826 | <t> |
---|
| 1827 | The absoluteURI form is &REQUIRED; when the request is being made to a |
---|
| 1828 | proxy. The proxy is requested to forward the request or service it |
---|
| 1829 | from a valid cache, and return the response. Note that the proxy &MAY; |
---|
| 1830 | forward the request on to another proxy or directly to the server |
---|
| 1831 | specified by the absoluteURI. In order to avoid request loops, a |
---|
| 1832 | proxy &MUST; be able to recognize all of its server names, including |
---|
| 1833 | any aliases, local variations, and the numeric IP address. An example |
---|
| 1834 | Request-Line would be: |
---|
| 1835 | </t> |
---|
| 1836 | <figure><artwork type="example"> |
---|
[90] | 1837 | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
---|
[8] | 1838 | </artwork></figure> |
---|
| 1839 | <t> |
---|
| 1840 | To allow for transition to absoluteURIs in all requests in future |
---|
| 1841 | versions of HTTP, all HTTP/1.1 servers &MUST; accept the absoluteURI |
---|
| 1842 | form in requests, even though HTTP/1.1 clients will only generate |
---|
| 1843 | them in requests to proxies. |
---|
| 1844 | </t> |
---|
| 1845 | <t> |
---|
[29] | 1846 | The authority form is only used by the CONNECT method (&CONNECT;). |
---|
[8] | 1847 | </t> |
---|
| 1848 | <t> |
---|
| 1849 | The most common form of Request-URI is that used to identify a |
---|
| 1850 | resource on an origin server or gateway. In this case the absolute |
---|
[185] | 1851 | path of the URI &MUST; be transmitted (see <xref target="general.syntax"/>, path-absolute) as |
---|
[8] | 1852 | the Request-URI, and the network location of the URI (authority) &MUST; |
---|
| 1853 | be transmitted in a Host header field. For example, a client wishing |
---|
| 1854 | to retrieve the resource above directly from the origin server would |
---|
[90] | 1855 | create a TCP connection to port 80 of the host "www.example.org" and send |
---|
[8] | 1856 | the lines: |
---|
| 1857 | </t> |
---|
| 1858 | <figure><artwork type="example"> |
---|
| 1859 | GET /pub/WWW/TheProject.html HTTP/1.1 |
---|
[90] | 1860 | Host: www.example.org |
---|
[8] | 1861 | </artwork></figure> |
---|
| 1862 | <t> |
---|
| 1863 | followed by the remainder of the Request. Note that the absolute path |
---|
| 1864 | cannot be empty; if none is present in the original URI, it &MUST; be |
---|
| 1865 | given as "/" (the server root). |
---|
| 1866 | </t> |
---|
| 1867 | <t> |
---|
| 1868 | The Request-URI is transmitted in the format specified in |
---|
[309] | 1869 | <xref target="general.syntax"/>. If the Request-URI is encoded using the |
---|
| 1870 | "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding |
---|
| 1871 | (<xref target="RFC2396" x:fmt="," x:sec="2.4.1"/>), the origin server |
---|
| 1872 | &MUST; decode the Request-URI in order to |
---|
[8] | 1873 | properly interpret the request. Servers &SHOULD; respond to invalid |
---|
| 1874 | Request-URIs with an appropriate status code. |
---|
| 1875 | </t> |
---|
| 1876 | <t> |
---|
[185] | 1877 | A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the |
---|
[8] | 1878 | received Request-URI when forwarding it to the next inbound server, |
---|
[185] | 1879 | except as noted above to replace a null path-absolute with "/". |
---|
[8] | 1880 | </t> |
---|
| 1881 | <t> |
---|
| 1882 | <list><t> |
---|
| 1883 | <x:h>Note:</x:h> The "no rewrite" rule prevents the proxy from changing the |
---|
| 1884 | meaning of the request when the origin server is improperly using |
---|
| 1885 | a non-reserved URI character for a reserved purpose. Implementors |
---|
| 1886 | should be aware that some pre-HTTP/1.1 proxies have been known to |
---|
| 1887 | rewrite the Request-URI. |
---|
| 1888 | </t></list> |
---|
| 1889 | </t> |
---|
| 1890 | </section> |
---|
| 1891 | </section> |
---|
| 1892 | |
---|
| 1893 | <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request"> |
---|
| 1894 | <t> |
---|
| 1895 | The exact resource identified by an Internet request is determined by |
---|
| 1896 | examining both the Request-URI and the Host header field. |
---|
| 1897 | </t> |
---|
| 1898 | <t> |
---|
| 1899 | An origin server that does not allow resources to differ by the |
---|
| 1900 | requested host &MAY; ignore the Host header field value when |
---|
| 1901 | determining the resource identified by an HTTP/1.1 request. (But see |
---|
| 1902 | <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/> |
---|
| 1903 | for other requirements on Host support in HTTP/1.1.) |
---|
| 1904 | </t> |
---|
| 1905 | <t> |
---|
| 1906 | An origin server that does differentiate resources based on the host |
---|
| 1907 | requested (sometimes referred to as virtual hosts or vanity host |
---|
| 1908 | names) &MUST; use the following rules for determining the requested |
---|
| 1909 | resource on an HTTP/1.1 request: |
---|
| 1910 | <list style="numbers"> |
---|
| 1911 | <t>If Request-URI is an absoluteURI, the host is part of the |
---|
| 1912 | Request-URI. Any Host header field value in the request &MUST; be |
---|
| 1913 | ignored.</t> |
---|
| 1914 | <t>If the Request-URI is not an absoluteURI, and the request includes |
---|
| 1915 | a Host header field, the host is determined by the Host header |
---|
| 1916 | field value.</t> |
---|
| 1917 | <t>If the host as determined by rule 1 or 2 is not a valid host on |
---|
| 1918 | the server, the response &MUST; be a 400 (Bad Request) error message.</t> |
---|
| 1919 | </list> |
---|
| 1920 | </t> |
---|
| 1921 | <t> |
---|
| 1922 | Recipients of an HTTP/1.0 request that lacks a Host header field &MAY; |
---|
| 1923 | attempt to use heuristics (e.g., examination of the URI path for |
---|
| 1924 | something unique to a particular host) in order to determine what |
---|
| 1925 | exact resource is being requested. |
---|
| 1926 | </t> |
---|
| 1927 | </section> |
---|
| 1928 | |
---|
| 1929 | </section> |
---|
| 1930 | |
---|
| 1931 | |
---|
| 1932 | <section title="Response" anchor="response"> |
---|
[229] | 1933 | <x:anchor-alias value="Response"/> |
---|
[8] | 1934 | <t> |
---|
| 1935 | After receiving and interpreting a request message, a server responds |
---|
| 1936 | with an HTTP response message. |
---|
| 1937 | </t> |
---|
| 1938 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/> |
---|
[229] | 1939 | <x:ref>Response</x:ref> = <x:ref>Status-Line</x:ref> ; <xref target="status-line"/> |
---|
| 1940 | *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> |
---|
| 1941 | | <x:ref>response-header</x:ref> ; &response-header-fields; |
---|
| 1942 | | <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref>) ; &entity-header-fields; |
---|
| 1943 | <x:ref>CRLF</x:ref> |
---|
| 1944 | [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> |
---|
[8] | 1945 | </artwork></figure> |
---|
| 1946 | |
---|
| 1947 | <section title="Status-Line" anchor="status-line"> |
---|
[229] | 1948 | <x:anchor-alias value="Status-Line"/> |
---|
[8] | 1949 | <t> |
---|
| 1950 | The first line of a Response message is the Status-Line, consisting |
---|
| 1951 | of the protocol version followed by a numeric status code and its |
---|
| 1952 | associated textual phrase, with each element separated by SP |
---|
| 1953 | characters. No CR or LF is allowed except in the final CRLF sequence. |
---|
| 1954 | </t> |
---|
| 1955 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Line"/> |
---|
[229] | 1956 | <x:ref>Status-Line</x:ref> = <x:ref>HTTP-Version</x:ref> <x:ref>SP</x:ref> <x:ref>Status-Code</x:ref> <x:ref>SP</x:ref> <x:ref>Reason-Phrase</x:ref> <x:ref>CRLF</x:ref> |
---|
[8] | 1957 | </artwork></figure> |
---|
| 1958 | |
---|
| 1959 | <section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase"> |
---|
[229] | 1960 | <x:anchor-alias value="Reason-Phrase"/> |
---|
| 1961 | <x:anchor-alias value="Status-Code"/> |
---|
[8] | 1962 | <t> |
---|
| 1963 | The Status-Code element is a 3-digit integer result code of the |
---|
| 1964 | attempt to understand and satisfy the request. These codes are fully |
---|
[198] | 1965 | defined in &status-codes;. The Reason Phrase exists for the sole |
---|
| 1966 | purpose of providing a textual description associated with the numeric |
---|
| 1967 | status code, out of deference to earlier Internet application protocols |
---|
| 1968 | that were more frequently used with interactive text clients. |
---|
| 1969 | A client &SHOULD; ignore the content of the Reason Phrase. |
---|
[8] | 1970 | </t> |
---|
| 1971 | <t> |
---|
| 1972 | The first digit of the Status-Code defines the class of response. The |
---|
| 1973 | last two digits do not have any categorization role. There are 5 |
---|
| 1974 | values for the first digit: |
---|
| 1975 | <list style="symbols"> |
---|
| 1976 | <t> |
---|
| 1977 | 1xx: Informational - Request received, continuing process |
---|
| 1978 | </t> |
---|
| 1979 | <t> |
---|
| 1980 | 2xx: Success - The action was successfully received, |
---|
| 1981 | understood, and accepted |
---|
| 1982 | </t> |
---|
| 1983 | <t> |
---|
| 1984 | 3xx: Redirection - Further action must be taken in order to |
---|
| 1985 | complete the request |
---|
| 1986 | </t> |
---|
| 1987 | <t> |
---|
| 1988 | 4xx: Client Error - The request contains bad syntax or cannot |
---|
| 1989 | be fulfilled |
---|
| 1990 | </t> |
---|
| 1991 | <t> |
---|
| 1992 | 5xx: Server Error - The server failed to fulfill an apparently |
---|
| 1993 | valid request |
---|
| 1994 | </t> |
---|
| 1995 | </list> |
---|
| 1996 | </t> |
---|
| 1997 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/> |
---|
[229] | 1998 | <x:ref>Status-Code</x:ref> = 3<x:ref>DIGIT</x:ref> |
---|
| 1999 | <x:ref>Reason-Phrase</x:ref> = *<<x:ref>TEXT</x:ref>, excluding <x:ref>CR</x:ref>, <x:ref>LF</x:ref>> |
---|
[8] | 2000 | </artwork></figure> |
---|
| 2001 | </section> |
---|
| 2002 | </section> |
---|
| 2003 | |
---|
| 2004 | </section> |
---|
| 2005 | |
---|
| 2006 | |
---|
| 2007 | <section title="Connections" anchor="connections"> |
---|
| 2008 | |
---|
| 2009 | <section title="Persistent Connections" anchor="persistent.connections"> |
---|
| 2010 | |
---|
| 2011 | <section title="Purpose" anchor="persistent.purpose"> |
---|
| 2012 | <t> |
---|
| 2013 | Prior to persistent connections, a separate TCP connection was |
---|
| 2014 | established to fetch each URL, increasing the load on HTTP servers |
---|
| 2015 | and causing congestion on the Internet. The use of inline images and |
---|
| 2016 | other associated data often require a client to make multiple |
---|
| 2017 | requests of the same server in a short amount of time. Analysis of |
---|
| 2018 | these performance problems and results from a prototype |
---|
| 2019 | implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and |
---|
[97] | 2020 | measurements of actual HTTP/1.1 (<xref target="RFC2068" x:fmt="none">RFC 2068</xref>) implementations show good |
---|
[8] | 2021 | results <xref target="Nie1997"/>. Alternatives have also been explored, for example, |
---|
| 2022 | T/TCP <xref target="Tou1998"/>. |
---|
| 2023 | </t> |
---|
| 2024 | <t> |
---|
| 2025 | Persistent HTTP connections have a number of advantages: |
---|
| 2026 | <list style="symbols"> |
---|
| 2027 | <t> |
---|
| 2028 | By opening and closing fewer TCP connections, CPU time is saved |
---|
| 2029 | in routers and hosts (clients, servers, proxies, gateways, |
---|
| 2030 | tunnels, or caches), and memory used for TCP protocol control |
---|
| 2031 | blocks can be saved in hosts. |
---|
| 2032 | </t> |
---|
| 2033 | <t> |
---|
| 2034 | HTTP requests and responses can be pipelined on a connection. |
---|
| 2035 | Pipelining allows a client to make multiple requests without |
---|
| 2036 | waiting for each response, allowing a single TCP connection to |
---|
| 2037 | be used much more efficiently, with much lower elapsed time. |
---|
| 2038 | </t> |
---|
| 2039 | <t> |
---|
| 2040 | Network congestion is reduced by reducing the number of packets |
---|
| 2041 | caused by TCP opens, and by allowing TCP sufficient time to |
---|
| 2042 | determine the congestion state of the network. |
---|
| 2043 | </t> |
---|
| 2044 | <t> |
---|
| 2045 | Latency on subsequent requests is reduced since there is no time |
---|
| 2046 | spent in TCP's connection opening handshake. |
---|
| 2047 | </t> |
---|
| 2048 | <t> |
---|
| 2049 | HTTP can evolve more gracefully, since errors can be reported |
---|
| 2050 | without the penalty of closing the TCP connection. Clients using |
---|
| 2051 | future versions of HTTP might optimistically try a new feature, |
---|
| 2052 | but if communicating with an older server, retry with old |
---|
| 2053 | semantics after an error is reported. |
---|
| 2054 | </t> |
---|
| 2055 | </list> |
---|
| 2056 | </t> |
---|
| 2057 | <t> |
---|
| 2058 | HTTP implementations &SHOULD; implement persistent connections. |
---|
| 2059 | </t> |
---|
| 2060 | </section> |
---|
| 2061 | |
---|
| 2062 | <section title="Overall Operation" anchor="persistent.overall"> |
---|
| 2063 | <t> |
---|
| 2064 | A significant difference between HTTP/1.1 and earlier versions of |
---|
| 2065 | HTTP is that persistent connections are the default behavior of any |
---|
| 2066 | HTTP connection. That is, unless otherwise indicated, the client |
---|
| 2067 | &SHOULD; assume that the server will maintain a persistent connection, |
---|
| 2068 | even after error responses from the server. |
---|
| 2069 | </t> |
---|
| 2070 | <t> |
---|
| 2071 | Persistent connections provide a mechanism by which a client and a |
---|
| 2072 | server can signal the close of a TCP connection. This signaling takes |
---|
| 2073 | place using the Connection header field (<xref target="header.connection"/>). Once a close |
---|
| 2074 | has been signaled, the client &MUST-NOT; send any more requests on that |
---|
| 2075 | connection. |
---|
| 2076 | </t> |
---|
| 2077 | |
---|
| 2078 | <section title="Negotiation" anchor="persistent.negotiation"> |
---|
| 2079 | <t> |
---|
| 2080 | An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to |
---|
| 2081 | maintain a persistent connection unless a Connection header including |
---|
| 2082 | the connection-token "close" was sent in the request. If the server |
---|
| 2083 | chooses to close the connection immediately after sending the |
---|
| 2084 | response, it &SHOULD; send a Connection header including the |
---|
| 2085 | connection-token close. |
---|
| 2086 | </t> |
---|
| 2087 | <t> |
---|
| 2088 | An HTTP/1.1 client &MAY; expect a connection to remain open, but would |
---|
| 2089 | decide to keep it open based on whether the response from a server |
---|
| 2090 | contains a Connection header with the connection-token close. In case |
---|
| 2091 | the client does not want to maintain a connection for more than that |
---|
| 2092 | request, it &SHOULD; send a Connection header including the |
---|
| 2093 | connection-token close. |
---|
| 2094 | </t> |
---|
| 2095 | <t> |
---|
| 2096 | If either the client or the server sends the close token in the |
---|
| 2097 | Connection header, that request becomes the last one for the |
---|
| 2098 | connection. |
---|
| 2099 | </t> |
---|
| 2100 | <t> |
---|
| 2101 | Clients and servers &SHOULD-NOT; assume that a persistent connection is |
---|
| 2102 | maintained for HTTP versions less than 1.1 unless it is explicitly |
---|
| 2103 | signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward |
---|
| 2104 | compatibility with HTTP/1.0 clients. |
---|
| 2105 | </t> |
---|
| 2106 | <t> |
---|
| 2107 | In order to remain persistent, all messages on the connection &MUST; |
---|
| 2108 | have a self-defined message length (i.e., one not defined by closure |
---|
| 2109 | of the connection), as described in <xref target="message.length"/>. |
---|
| 2110 | </t> |
---|
| 2111 | </section> |
---|
| 2112 | |
---|
| 2113 | <section title="Pipelining" anchor="pipelining"> |
---|
| 2114 | <t> |
---|
| 2115 | A client that supports persistent connections &MAY; "pipeline" its |
---|
| 2116 | requests (i.e., send multiple requests without waiting for each |
---|
| 2117 | response). A server &MUST; send its responses to those requests in the |
---|
| 2118 | same order that the requests were received. |
---|
| 2119 | </t> |
---|
| 2120 | <t> |
---|
| 2121 | Clients which assume persistent connections and pipeline immediately |
---|
| 2122 | after connection establishment &SHOULD; be prepared to retry their |
---|
| 2123 | connection if the first pipelined attempt fails. If a client does |
---|
| 2124 | such a retry, it &MUST-NOT; pipeline before it knows the connection is |
---|
| 2125 | persistent. Clients &MUST; also be prepared to resend their requests if |
---|
| 2126 | the server closes the connection before sending all of the |
---|
| 2127 | corresponding responses. |
---|
| 2128 | </t> |
---|
| 2129 | <t> |
---|
| 2130 | Clients &SHOULD-NOT; pipeline requests using non-idempotent methods or |
---|
[29] | 2131 | non-idempotent sequences of methods (see &idempotent-methods;). Otherwise, a |
---|
[8] | 2132 | premature termination of the transport connection could lead to |
---|
| 2133 | indeterminate results. A client wishing to send a non-idempotent |
---|
| 2134 | request &SHOULD; wait to send that request until it has received the |
---|
| 2135 | response status for the previous request. |
---|
| 2136 | </t> |
---|
| 2137 | </section> |
---|
| 2138 | </section> |
---|
| 2139 | |
---|
| 2140 | <section title="Proxy Servers" anchor="persistent.proxy"> |
---|
| 2141 | <t> |
---|
| 2142 | It is especially important that proxies correctly implement the |
---|
| 2143 | properties of the Connection header field as specified in <xref target="header.connection"/>. |
---|
| 2144 | </t> |
---|
| 2145 | <t> |
---|
| 2146 | The proxy server &MUST; signal persistent connections separately with |
---|
| 2147 | its clients and the origin servers (or other proxy servers) that it |
---|
| 2148 | connects to. Each persistent connection applies to only one transport |
---|
| 2149 | link. |
---|
| 2150 | </t> |
---|
| 2151 | <t> |
---|
| 2152 | A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection |
---|
[97] | 2153 | with an HTTP/1.0 client (but see <xref target="RFC2068"/> for information and |
---|
[8] | 2154 | discussion of the problems with the Keep-Alive header implemented by |
---|
| 2155 | many HTTP/1.0 clients). |
---|
| 2156 | </t> |
---|
| 2157 | </section> |
---|
| 2158 | |
---|
| 2159 | <section title="Practical Considerations" anchor="persistent.practical"> |
---|
| 2160 | <t> |
---|
| 2161 | Servers will usually have some time-out value beyond which they will |
---|
| 2162 | no longer maintain an inactive connection. Proxy servers might make |
---|
| 2163 | this a higher value since it is likely that the client will be making |
---|
| 2164 | more connections through the same server. The use of persistent |
---|
| 2165 | connections places no requirements on the length (or existence) of |
---|
| 2166 | this time-out for either the client or the server. |
---|
| 2167 | </t> |
---|
| 2168 | <t> |
---|
| 2169 | When a client or server wishes to time-out it &SHOULD; issue a graceful |
---|
| 2170 | close on the transport connection. Clients and servers &SHOULD; both |
---|
| 2171 | constantly watch for the other side of the transport close, and |
---|
| 2172 | respond to it as appropriate. If a client or server does not detect |
---|
| 2173 | the other side's close promptly it could cause unnecessary resource |
---|
| 2174 | drain on the network. |
---|
| 2175 | </t> |
---|
| 2176 | <t> |
---|
| 2177 | A client, server, or proxy &MAY; close the transport connection at any |
---|
| 2178 | time. For example, a client might have started to send a new request |
---|
| 2179 | at the same time that the server has decided to close the "idle" |
---|
| 2180 | connection. From the server's point of view, the connection is being |
---|
| 2181 | closed while it was idle, but from the client's point of view, a |
---|
| 2182 | request is in progress. |
---|
| 2183 | </t> |
---|
| 2184 | <t> |
---|
| 2185 | This means that clients, servers, and proxies &MUST; be able to recover |
---|
| 2186 | from asynchronous close events. Client software &SHOULD; reopen the |
---|
| 2187 | transport connection and retransmit the aborted sequence of requests |
---|
| 2188 | without user interaction so long as the request sequence is |
---|
[29] | 2189 | idempotent (see &idempotent-methods;). Non-idempotent methods or sequences |
---|
[8] | 2190 | &MUST-NOT; be automatically retried, although user agents &MAY; offer a |
---|
| 2191 | human operator the choice of retrying the request(s). Confirmation by |
---|
| 2192 | user-agent software with semantic understanding of the application |
---|
| 2193 | &MAY; substitute for user confirmation. The automatic retry &SHOULD-NOT; |
---|
| 2194 | be repeated if the second sequence of requests fails. |
---|
| 2195 | </t> |
---|
| 2196 | <t> |
---|
| 2197 | Servers &SHOULD; always respond to at least one request per connection, |
---|
| 2198 | if at all possible. Servers &SHOULD-NOT; close a connection in the |
---|
| 2199 | middle of transmitting a response, unless a network or client failure |
---|
| 2200 | is suspected. |
---|
| 2201 | </t> |
---|
| 2202 | <t> |
---|
| 2203 | Clients that use persistent connections &SHOULD; limit the number of |
---|
| 2204 | simultaneous connections that they maintain to a given server. A |
---|
| 2205 | single-user client &SHOULD-NOT; maintain more than 2 connections with |
---|
| 2206 | any server or proxy. A proxy &SHOULD; use up to 2*N connections to |
---|
| 2207 | another server or proxy, where N is the number of simultaneously |
---|
| 2208 | active users. These guidelines are intended to improve HTTP response |
---|
| 2209 | times and avoid congestion. |
---|
| 2210 | </t> |
---|
| 2211 | </section> |
---|
| 2212 | </section> |
---|
| 2213 | |
---|
| 2214 | <section title="Message Transmission Requirements" anchor="message.transmission.requirements"> |
---|
| 2215 | |
---|
| 2216 | <section title="Persistent Connections and Flow Control" anchor="persistent.flow"> |
---|
| 2217 | <t> |
---|
| 2218 | HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's |
---|
| 2219 | flow control mechanisms to resolve temporary overloads, rather than |
---|
| 2220 | terminating connections with the expectation that clients will retry. |
---|
| 2221 | The latter technique can exacerbate network congestion. |
---|
| 2222 | </t> |
---|
| 2223 | </section> |
---|
| 2224 | |
---|
| 2225 | <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor"> |
---|
| 2226 | <t> |
---|
| 2227 | An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor |
---|
| 2228 | the network connection for an error status while it is transmitting |
---|
| 2229 | the request. If the client sees an error status, it &SHOULD; |
---|
| 2230 | immediately cease transmitting the body. If the body is being sent |
---|
| 2231 | using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and |
---|
| 2232 | empty trailer &MAY; be used to prematurely mark the end of the message. |
---|
| 2233 | If the body was preceded by a Content-Length header, the client &MUST; |
---|
| 2234 | close the connection. |
---|
| 2235 | </t> |
---|
| 2236 | </section> |
---|
| 2237 | |
---|
| 2238 | <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status"> |
---|
| 2239 | <t> |
---|
[29] | 2240 | The purpose of the 100 (Continue) status (see &status-100;) is to |
---|
[8] | 2241 | allow a client that is sending a request message with a request body |
---|
| 2242 | to determine if the origin server is willing to accept the request |
---|
| 2243 | (based on the request headers) before the client sends the request |
---|
| 2244 | body. In some cases, it might either be inappropriate or highly |
---|
| 2245 | inefficient for the client to send the body if the server will reject |
---|
| 2246 | the message without looking at the body. |
---|
| 2247 | </t> |
---|
| 2248 | <t> |
---|
| 2249 | Requirements for HTTP/1.1 clients: |
---|
| 2250 | <list style="symbols"> |
---|
| 2251 | <t> |
---|
| 2252 | If a client will wait for a 100 (Continue) response before |
---|
| 2253 | sending the request body, it &MUST; send an Expect request-header |
---|
[29] | 2254 | field (&header-expect;) with the "100-continue" expectation. |
---|
[8] | 2255 | </t> |
---|
| 2256 | <t> |
---|
[29] | 2257 | A client &MUST-NOT; send an Expect request-header field (&header-expect;) |
---|
[8] | 2258 | with the "100-continue" expectation if it does not intend |
---|
| 2259 | to send a request body. |
---|
| 2260 | </t> |
---|
| 2261 | </list> |
---|
| 2262 | </t> |
---|
| 2263 | <t> |
---|
| 2264 | Because of the presence of older implementations, the protocol allows |
---|
| 2265 | ambiguous situations in which a client may send "Expect: 100-continue" |
---|
| 2266 | without receiving either a 417 (Expectation Failed) status |
---|
| 2267 | or a 100 (Continue) status. Therefore, when a client sends this |
---|
| 2268 | header field to an origin server (possibly via a proxy) from which it |
---|
| 2269 | has never seen a 100 (Continue) status, the client &SHOULD-NOT; wait |
---|
| 2270 | for an indefinite period before sending the request body. |
---|
| 2271 | </t> |
---|
| 2272 | <t> |
---|
| 2273 | Requirements for HTTP/1.1 origin servers: |
---|
| 2274 | <list style="symbols"> |
---|
| 2275 | <t> Upon receiving a request which includes an Expect request-header |
---|
| 2276 | field with the "100-continue" expectation, an origin server &MUST; |
---|
| 2277 | either respond with 100 (Continue) status and continue to read |
---|
| 2278 | from the input stream, or respond with a final status code. The |
---|
| 2279 | origin server &MUST-NOT; wait for the request body before sending |
---|
| 2280 | the 100 (Continue) response. If it responds with a final status |
---|
| 2281 | code, it &MAY; close the transport connection or it &MAY; continue |
---|
| 2282 | to read and discard the rest of the request. It &MUST-NOT; |
---|
| 2283 | perform the requested method if it returns a final status code. |
---|
| 2284 | </t> |
---|
| 2285 | <t> An origin server &SHOULD-NOT; send a 100 (Continue) response if |
---|
| 2286 | the request message does not include an Expect request-header |
---|
| 2287 | field with the "100-continue" expectation, and &MUST-NOT; send a |
---|
| 2288 | 100 (Continue) response if such a request comes from an HTTP/1.0 |
---|
| 2289 | (or earlier) client. There is an exception to this rule: for |
---|
[97] | 2290 | compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue) |
---|
[8] | 2291 | status in response to an HTTP/1.1 PUT or POST request that does |
---|
| 2292 | not include an Expect request-header field with the "100-continue" |
---|
| 2293 | expectation. This exception, the purpose of which is |
---|
| 2294 | to minimize any client processing delays associated with an |
---|
| 2295 | undeclared wait for 100 (Continue) status, applies only to |
---|
| 2296 | HTTP/1.1 requests, and not to requests with any other HTTP-version |
---|
| 2297 | value. |
---|
| 2298 | </t> |
---|
| 2299 | <t> An origin server &MAY; omit a 100 (Continue) response if it has |
---|
| 2300 | already received some or all of the request body for the |
---|
| 2301 | corresponding request. |
---|
| 2302 | </t> |
---|
| 2303 | <t> An origin server that sends a 100 (Continue) response &MUST; |
---|
| 2304 | ultimately send a final status code, once the request body is |
---|
| 2305 | received and processed, unless it terminates the transport |
---|
| 2306 | connection prematurely. |
---|
| 2307 | </t> |
---|
| 2308 | <t> If an origin server receives a request that does not include an |
---|
| 2309 | Expect request-header field with the "100-continue" expectation, |
---|
| 2310 | the request includes a request body, and the server responds |
---|
| 2311 | with a final status code before reading the entire request body |
---|
| 2312 | from the transport connection, then the server &SHOULD-NOT; close |
---|
| 2313 | the transport connection until it has read the entire request, |
---|
| 2314 | or until the client closes the connection. Otherwise, the client |
---|
| 2315 | might not reliably receive the response message. However, this |
---|
| 2316 | requirement is not be construed as preventing a server from |
---|
| 2317 | defending itself against denial-of-service attacks, or from |
---|
| 2318 | badly broken client implementations. |
---|
| 2319 | </t> |
---|
| 2320 | </list> |
---|
| 2321 | </t> |
---|
| 2322 | <t> |
---|
| 2323 | Requirements for HTTP/1.1 proxies: |
---|
| 2324 | <list style="symbols"> |
---|
| 2325 | <t> If a proxy receives a request that includes an Expect request-header |
---|
| 2326 | field with the "100-continue" expectation, and the proxy |
---|
| 2327 | either knows that the next-hop server complies with HTTP/1.1 or |
---|
| 2328 | higher, or does not know the HTTP version of the next-hop |
---|
| 2329 | server, it &MUST; forward the request, including the Expect header |
---|
| 2330 | field. |
---|
| 2331 | </t> |
---|
| 2332 | <t> If the proxy knows that the version of the next-hop server is |
---|
| 2333 | HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST; |
---|
| 2334 | respond with a 417 (Expectation Failed) status. |
---|
| 2335 | </t> |
---|
| 2336 | <t> Proxies &SHOULD; maintain a cache recording the HTTP version |
---|
| 2337 | numbers received from recently-referenced next-hop servers. |
---|
| 2338 | </t> |
---|
| 2339 | <t> A proxy &MUST-NOT; forward a 100 (Continue) response if the |
---|
| 2340 | request message was received from an HTTP/1.0 (or earlier) |
---|
| 2341 | client and did not include an Expect request-header field with |
---|
| 2342 | the "100-continue" expectation. This requirement overrides the |
---|
[29] | 2343 | general rule for forwarding of 1xx responses (see &status-1xx;). |
---|
[8] | 2344 | </t> |
---|
| 2345 | </list> |
---|
| 2346 | </t> |
---|
| 2347 | </section> |
---|
| 2348 | |
---|
| 2349 | <section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature"> |
---|
| 2350 | <t> |
---|
| 2351 | If an HTTP/1.1 client sends a request which includes a request body, |
---|
| 2352 | but which does not include an Expect request-header field with the |
---|
| 2353 | "100-continue" expectation, and if the client is not directly |
---|
| 2354 | connected to an HTTP/1.1 origin server, and if the client sees the |
---|
| 2355 | connection close before receiving any status from the server, the |
---|
| 2356 | client &SHOULD; retry the request. If the client does retry this |
---|
| 2357 | request, it &MAY; use the following "binary exponential backoff" |
---|
| 2358 | algorithm to be assured of obtaining a reliable response: |
---|
| 2359 | <list style="numbers"> |
---|
| 2360 | <t> |
---|
| 2361 | Initiate a new connection to the server |
---|
| 2362 | </t> |
---|
| 2363 | <t> |
---|
| 2364 | Transmit the request-headers |
---|
| 2365 | </t> |
---|
| 2366 | <t> |
---|
| 2367 | Initialize a variable R to the estimated round-trip time to the |
---|
| 2368 | server (e.g., based on the time it took to establish the |
---|
| 2369 | connection), or to a constant value of 5 seconds if the round-trip |
---|
| 2370 | time is not available. |
---|
| 2371 | </t> |
---|
| 2372 | <t> |
---|
| 2373 | Compute T = R * (2**N), where N is the number of previous |
---|
| 2374 | retries of this request. |
---|
| 2375 | </t> |
---|
| 2376 | <t> |
---|
| 2377 | Wait either for an error response from the server, or for T |
---|
| 2378 | seconds (whichever comes first) |
---|
| 2379 | </t> |
---|
| 2380 | <t> |
---|
| 2381 | If no error response is received, after T seconds transmit the |
---|
| 2382 | body of the request. |
---|
| 2383 | </t> |
---|
| 2384 | <t> |
---|
| 2385 | If client sees that the connection is closed prematurely, |
---|
| 2386 | repeat from step 1 until the request is accepted, an error |
---|
| 2387 | response is received, or the user becomes impatient and |
---|
| 2388 | terminates the retry process. |
---|
| 2389 | </t> |
---|
| 2390 | </list> |
---|
| 2391 | </t> |
---|
| 2392 | <t> |
---|
| 2393 | If at any point an error status is received, the client |
---|
| 2394 | <list style="symbols"> |
---|
| 2395 | <t>&SHOULD-NOT; continue and</t> |
---|
| 2396 | |
---|
| 2397 | <t>&SHOULD; close the connection if it has not completed sending the |
---|
| 2398 | request message.</t> |
---|
| 2399 | </list> |
---|
| 2400 | </t> |
---|
| 2401 | </section> |
---|
| 2402 | </section> |
---|
| 2403 | </section> |
---|
| 2404 | |
---|
| 2405 | |
---|
| 2406 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
| 2407 | <t> |
---|
[117] | 2408 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
| 2409 | related to message framing and transport protocols. |
---|
[8] | 2410 | </t> |
---|
[117] | 2411 | <t> |
---|
| 2412 | For entity-header fields, both sender and recipient refer to either the |
---|
| 2413 | client or the server, depending on who sends and who receives the entity. |
---|
| 2414 | </t> |
---|
[8] | 2415 | |
---|
| 2416 | <section title="Connection" anchor="header.connection"> |
---|
| 2417 | <iref primary="true" item="Connection header" x:for-anchor=""/> |
---|
| 2418 | <iref primary="true" item="Headers" subitem="Connection" x:for-anchor=""/> |
---|
[229] | 2419 | <x:anchor-alias value="Connection"/> |
---|
| 2420 | <x:anchor-alias value="connection-token"/> |
---|
[8] | 2421 | <t> |
---|
| 2422 | The Connection general-header field allows the sender to specify |
---|
| 2423 | options that are desired for that particular connection and &MUST-NOT; |
---|
| 2424 | be communicated by proxies over further connections. |
---|
| 2425 | </t> |
---|
| 2426 | <t> |
---|
| 2427 | The Connection header has the following grammar: |
---|
| 2428 | </t> |
---|
| 2429 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/> |
---|
[229] | 2430 | <x:ref>Connection</x:ref> = "Connection" ":" 1#(<x:ref>connection-token</x:ref>) |
---|
| 2431 | <x:ref>connection-token</x:ref> = <x:ref>token</x:ref> |
---|
[8] | 2432 | </artwork></figure> |
---|
| 2433 | <t> |
---|
| 2434 | HTTP/1.1 proxies &MUST; parse the Connection header field before a |
---|
| 2435 | message is forwarded and, for each connection-token in this field, |
---|
| 2436 | remove any header field(s) from the message with the same name as the |
---|
| 2437 | connection-token. Connection options are signaled by the presence of |
---|
| 2438 | a connection-token in the Connection header field, not by any |
---|
| 2439 | corresponding additional header field(s), since the additional header |
---|
| 2440 | field may not be sent if there are no parameters associated with that |
---|
| 2441 | connection option. |
---|
| 2442 | </t> |
---|
| 2443 | <t> |
---|
| 2444 | Message headers listed in the Connection header &MUST-NOT; include |
---|
| 2445 | end-to-end headers, such as Cache-Control. |
---|
| 2446 | </t> |
---|
| 2447 | <t> |
---|
| 2448 | HTTP/1.1 defines the "close" connection option for the sender to |
---|
| 2449 | signal that the connection will be closed after completion of the |
---|
| 2450 | response. For example, |
---|
| 2451 | </t> |
---|
| 2452 | <figure><artwork type="example"> |
---|
| 2453 | Connection: close |
---|
| 2454 | </artwork></figure> |
---|
| 2455 | <t> |
---|
| 2456 | in either the request or the response header fields indicates that |
---|
| 2457 | the connection &SHOULD-NOT; be considered `persistent' (<xref target="persistent.connections"/>) |
---|
| 2458 | after the current request/response is complete. |
---|
| 2459 | </t> |
---|
| 2460 | <t> |
---|
[86] | 2461 | An HTTP/1.1 client that does not support persistent connections &MUST; |
---|
| 2462 | include the "close" connection option in every request message. |
---|
[8] | 2463 | </t> |
---|
| 2464 | <t> |
---|
[86] | 2465 | An HTTP/1.1 server that does not support persistent connections &MUST; |
---|
| 2466 | include the "close" connection option in every response message that |
---|
| 2467 | does not have a 1xx (informational) status code. |
---|
| 2468 | </t> |
---|
| 2469 | <t> |
---|
[8] | 2470 | A system receiving an HTTP/1.0 (or lower-version) message that |
---|
[96] | 2471 | includes a Connection header &MUST;, for each connection-token in this |
---|
[8] | 2472 | field, remove and ignore any header field(s) from the message with |
---|
| 2473 | the same name as the connection-token. This protects against mistaken |
---|
| 2474 | forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>. |
---|
| 2475 | </t> |
---|
| 2476 | </section> |
---|
| 2477 | |
---|
| 2478 | <section title="Content-Length" anchor="header.content-length"> |
---|
| 2479 | <iref primary="true" item="Content-Length header" x:for-anchor=""/> |
---|
| 2480 | <iref primary="true" item="Headers" subitem="Content-Length" x:for-anchor=""/> |
---|
[229] | 2481 | <x:anchor-alias value="Content-Length"/> |
---|
[8] | 2482 | <t> |
---|
| 2483 | The Content-Length entity-header field indicates the size of the |
---|
| 2484 | entity-body, in decimal number of OCTETs, sent to the recipient or, |
---|
| 2485 | in the case of the HEAD method, the size of the entity-body that |
---|
| 2486 | would have been sent had the request been a GET. |
---|
| 2487 | </t> |
---|
| 2488 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> |
---|
[229] | 2489 | <x:ref>Content-Length</x:ref> = "Content-Length" ":" 1*<x:ref>DIGIT</x:ref> |
---|
[8] | 2490 | </artwork></figure> |
---|
| 2491 | <t> |
---|
| 2492 | An example is |
---|
| 2493 | </t> |
---|
| 2494 | <figure><artwork type="example"> |
---|
| 2495 | Content-Length: 3495 |
---|
| 2496 | </artwork></figure> |
---|
| 2497 | <t> |
---|
| 2498 | Applications &SHOULD; use this field to indicate the transfer-length of |
---|
| 2499 | the message-body, unless this is prohibited by the rules in <xref target="message.length"/>. |
---|
| 2500 | </t> |
---|
| 2501 | <t> |
---|
| 2502 | Any Content-Length greater than or equal to zero is a valid value. |
---|
| 2503 | <xref target="message.length"/> describes how to determine the length of a message-body |
---|
| 2504 | if a Content-Length is not given. |
---|
| 2505 | </t> |
---|
| 2506 | <t> |
---|
| 2507 | Note that the meaning of this field is significantly different from |
---|
| 2508 | the corresponding definition in MIME, where it is an optional field |
---|
| 2509 | used within the "message/external-body" content-type. In HTTP, it |
---|
| 2510 | &SHOULD; be sent whenever the message's length can be determined prior |
---|
| 2511 | to being transferred, unless this is prohibited by the rules in |
---|
| 2512 | <xref target="message.length"/>. |
---|
| 2513 | </t> |
---|
| 2514 | </section> |
---|
| 2515 | |
---|
| 2516 | <section title="Date" anchor="header.date"> |
---|
| 2517 | <iref primary="true" item="Date header" x:for-anchor=""/> |
---|
| 2518 | <iref primary="true" item="Headers" subitem="Date" x:for-anchor=""/> |
---|
[229] | 2519 | <x:anchor-alias value="Date"/> |
---|
[8] | 2520 | <t> |
---|
| 2521 | The Date general-header field represents the date and time at which |
---|
| 2522 | the message was originated, having the same semantics as orig-date in |
---|
[134] | 2523 | <xref target="RFC2822" x:fmt="of" x:sec="3.6.1"/>. The field value is an HTTP-date, as described in <xref target="full.date"/>; |
---|
[84] | 2524 | it &MUST; be sent in rfc1123-date format. |
---|
[8] | 2525 | </t> |
---|
| 2526 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> |
---|
[229] | 2527 | <x:ref>Date</x:ref> = "Date" ":" <x:ref>HTTP-date</x:ref> |
---|
[8] | 2528 | </artwork></figure> |
---|
| 2529 | <t> |
---|
| 2530 | An example is |
---|
| 2531 | </t> |
---|
| 2532 | <figure><artwork type="example"> |
---|
| 2533 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
| 2534 | </artwork></figure> |
---|
| 2535 | <t> |
---|
| 2536 | Origin servers &MUST; include a Date header field in all responses, |
---|
| 2537 | except in these cases: |
---|
| 2538 | <list style="numbers"> |
---|
| 2539 | <t>If the response status code is 100 (Continue) or 101 (Switching |
---|
| 2540 | Protocols), the response &MAY; include a Date header field, at |
---|
| 2541 | the server's option.</t> |
---|
| 2542 | |
---|
| 2543 | <t>If the response status code conveys a server error, e.g. 500 |
---|
| 2544 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
| 2545 | inconvenient or impossible to generate a valid Date.</t> |
---|
| 2546 | |
---|
| 2547 | <t>If the server does not have a clock that can provide a |
---|
| 2548 | reasonable approximation of the current time, its responses |
---|
| 2549 | &MUST-NOT; include a Date header field. In this case, the rules |
---|
| 2550 | in <xref target="clockless.origin.server.operation"/> &MUST; be followed.</t> |
---|
| 2551 | </list> |
---|
| 2552 | </t> |
---|
| 2553 | <t> |
---|
| 2554 | A received message that does not have a Date header field &MUST; be |
---|
| 2555 | assigned one by the recipient if the message will be cached by that |
---|
| 2556 | recipient or gatewayed via a protocol which requires a Date. An HTTP |
---|
| 2557 | implementation without a clock &MUST-NOT; cache responses without |
---|
| 2558 | revalidating them on every use. An HTTP cache, especially a shared |
---|
| 2559 | cache, &SHOULD; use a mechanism, such as NTP <xref target="RFC1305"/>, to synchronize its |
---|
| 2560 | clock with a reliable external standard. |
---|
| 2561 | </t> |
---|
| 2562 | <t> |
---|
| 2563 | Clients &SHOULD; only send a Date header field in messages that include |
---|
| 2564 | an entity-body, as in the case of the PUT and POST requests, and even |
---|
| 2565 | then it is optional. A client without a clock &MUST-NOT; send a Date |
---|
| 2566 | header field in a request. |
---|
| 2567 | </t> |
---|
| 2568 | <t> |
---|
| 2569 | The HTTP-date sent in a Date header &SHOULD-NOT; represent a date and |
---|
| 2570 | time subsequent to the generation of the message. It &SHOULD; represent |
---|
| 2571 | the best available approximation of the date and time of message |
---|
| 2572 | generation, unless the implementation has no means of generating a |
---|
| 2573 | reasonably accurate date and time. In theory, the date ought to |
---|
| 2574 | represent the moment just before the entity is generated. In |
---|
| 2575 | practice, the date can be generated at any time during the message |
---|
| 2576 | origination without affecting its semantic value. |
---|
| 2577 | </t> |
---|
| 2578 | |
---|
| 2579 | <section title="Clockless Origin Server Operation" anchor="clockless.origin.server.operation"> |
---|
| 2580 | <t> |
---|
| 2581 | Some origin server implementations might not have a clock available. |
---|
| 2582 | An origin server without a clock &MUST-NOT; assign Expires or Last-Modified |
---|
| 2583 | values to a response, unless these values were associated |
---|
| 2584 | with the resource by a system or user with a reliable clock. It &MAY; |
---|
| 2585 | assign an Expires value that is known, at or before server |
---|
| 2586 | configuration time, to be in the past (this allows "pre-expiration" |
---|
| 2587 | of responses without storing separate Expires values for each |
---|
| 2588 | resource). |
---|
| 2589 | </t> |
---|
| 2590 | </section> |
---|
| 2591 | </section> |
---|
| 2592 | |
---|
| 2593 | <section title="Host" anchor="header.host"> |
---|
| 2594 | <iref primary="true" item="Host header" x:for-anchor=""/> |
---|
| 2595 | <iref primary="true" item="Headers" subitem="Host" x:for-anchor=""/> |
---|
[229] | 2596 | <x:anchor-alias value="Host"/> |
---|
[8] | 2597 | <t> |
---|
| 2598 | The Host request-header field specifies the Internet host and port |
---|
| 2599 | number of the resource being requested, as obtained from the original |
---|
| 2600 | URI given by the user or referring resource (generally an HTTP URL, |
---|
| 2601 | as described in <xref target="http.url"/>). The Host field value &MUST; represent |
---|
| 2602 | the naming authority of the origin server or gateway given by the |
---|
| 2603 | original URL. This allows the origin server or gateway to |
---|
| 2604 | differentiate between internally-ambiguous URLs, such as the root "/" |
---|
| 2605 | URL of a server for multiple host names on a single IP address. |
---|
| 2606 | </t> |
---|
| 2607 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/> |
---|
[229] | 2608 | <x:ref>Host</x:ref> = "Host" ":" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.url"/> |
---|
[8] | 2609 | </artwork></figure> |
---|
| 2610 | <t> |
---|
| 2611 | A "host" without any trailing port information implies the default |
---|
| 2612 | port for the service requested (e.g., "80" for an HTTP URL). For |
---|
| 2613 | example, a request on the origin server for |
---|
[90] | 2614 | <http://www.example.org/pub/WWW/> would properly include: |
---|
[8] | 2615 | </t> |
---|
| 2616 | <figure><artwork type="example"> |
---|
| 2617 | GET /pub/WWW/ HTTP/1.1 |
---|
[90] | 2618 | Host: www.example.org |
---|
[8] | 2619 | </artwork></figure> |
---|
| 2620 | <t> |
---|
| 2621 | A client &MUST; include a Host header field in all HTTP/1.1 request |
---|
[148] | 2622 | messages. If the requested URI does not include an Internet host |
---|
[8] | 2623 | name for the service being requested, then the Host header field &MUST; |
---|
| 2624 | be given with an empty value. An HTTP/1.1 proxy &MUST; ensure that any |
---|
| 2625 | request message it forwards does contain an appropriate Host header |
---|
| 2626 | field that identifies the service being requested by the proxy. All |
---|
| 2627 | Internet-based HTTP/1.1 servers &MUST; respond with a 400 (Bad Request) |
---|
| 2628 | status code to any HTTP/1.1 request message which lacks a Host header |
---|
| 2629 | field. |
---|
| 2630 | </t> |
---|
| 2631 | <t> |
---|
[97] | 2632 | See Sections <xref target="the.resource.identified.by.a.request" format="counter"/> |
---|
[8] | 2633 | and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/> |
---|
| 2634 | for other requirements relating to Host. |
---|
| 2635 | </t> |
---|
| 2636 | </section> |
---|
| 2637 | |
---|
| 2638 | <section title="TE" anchor="header.te"> |
---|
| 2639 | <iref primary="true" item="TE header" x:for-anchor=""/> |
---|
| 2640 | <iref primary="true" item="Headers" subitem="TE" x:for-anchor=""/> |
---|
[229] | 2641 | <x:anchor-alias value="TE"/> |
---|
| 2642 | <x:anchor-alias value="t-codings"/> |
---|
[8] | 2643 | <t> |
---|
| 2644 | The TE request-header field indicates what extension transfer-codings |
---|
| 2645 | it is willing to accept in the response and whether or not it is |
---|
| 2646 | willing to accept trailer fields in a chunked transfer-coding. Its |
---|
| 2647 | value may consist of the keyword "trailers" and/or a comma-separated |
---|
| 2648 | list of extension transfer-coding names with optional accept |
---|
| 2649 | parameters (as described in <xref target="transfer.codings"/>). |
---|
| 2650 | </t> |
---|
| 2651 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/> |
---|
[229] | 2652 | <x:ref>TE</x:ref> = "TE" ":" #( <x:ref>t-codings</x:ref> ) |
---|
| 2653 | <x:ref>t-codings</x:ref> = "trailers" | ( <x:ref>transfer-extension</x:ref> [ <x:ref>accept-params</x:ref> ] ) |
---|
[8] | 2654 | </artwork></figure> |
---|
| 2655 | <t> |
---|
| 2656 | The presence of the keyword "trailers" indicates that the client is |
---|
| 2657 | willing to accept trailer fields in a chunked transfer-coding, as |
---|
| 2658 | defined in <xref target="chunked.transfer.encoding"/>. This keyword is reserved for use with |
---|
| 2659 | transfer-coding values even though it does not itself represent a |
---|
| 2660 | transfer-coding. |
---|
| 2661 | </t> |
---|
| 2662 | <t> |
---|
| 2663 | Examples of its use are: |
---|
| 2664 | </t> |
---|
| 2665 | <figure><artwork type="example"> |
---|
| 2666 | TE: deflate |
---|
| 2667 | TE: |
---|
| 2668 | TE: trailers, deflate;q=0.5 |
---|
| 2669 | </artwork></figure> |
---|
| 2670 | <t> |
---|
| 2671 | The TE header field only applies to the immediate connection. |
---|
| 2672 | Therefore, the keyword &MUST; be supplied within a Connection header |
---|
| 2673 | field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. |
---|
| 2674 | </t> |
---|
| 2675 | <t> |
---|
| 2676 | A server tests whether a transfer-coding is acceptable, according to |
---|
| 2677 | a TE field, using these rules: |
---|
| 2678 | <list style="numbers"> |
---|
| 2679 | <x:lt> |
---|
| 2680 | <t>The "chunked" transfer-coding is always acceptable. If the |
---|
| 2681 | keyword "trailers" is listed, the client indicates that it is |
---|
| 2682 | willing to accept trailer fields in the chunked response on |
---|
| 2683 | behalf of itself and any downstream clients. The implication is |
---|
| 2684 | that, if given, the client is stating that either all |
---|
| 2685 | downstream clients are willing to accept trailer fields in the |
---|
| 2686 | forwarded response, or that it will attempt to buffer the |
---|
| 2687 | response on behalf of downstream recipients. |
---|
| 2688 | </t><t> |
---|
| 2689 | <x:h>Note:</x:h> HTTP/1.1 does not define any means to limit the size of a |
---|
| 2690 | chunked response such that a client can be assured of buffering |
---|
| 2691 | the entire response.</t> |
---|
| 2692 | </x:lt> |
---|
| 2693 | <x:lt> |
---|
| 2694 | <t>If the transfer-coding being tested is one of the transfer-codings |
---|
| 2695 | listed in the TE field, then it is acceptable unless it |
---|
[29] | 2696 | is accompanied by a qvalue of 0. (As defined in &qvalue;, a |
---|
[8] | 2697 | qvalue of 0 means "not acceptable.")</t> |
---|
| 2698 | </x:lt> |
---|
| 2699 | <x:lt> |
---|
| 2700 | <t>If multiple transfer-codings are acceptable, then the |
---|
| 2701 | acceptable transfer-coding with the highest non-zero qvalue is |
---|
| 2702 | preferred. The "chunked" transfer-coding always has a qvalue |
---|
| 2703 | of 1.</t> |
---|
| 2704 | </x:lt> |
---|
| 2705 | </list> |
---|
| 2706 | </t> |
---|
| 2707 | <t> |
---|
| 2708 | If the TE field-value is empty or if no TE field is present, the only |
---|
| 2709 | transfer-coding is "chunked". A message with no transfer-coding is |
---|
| 2710 | always acceptable. |
---|
| 2711 | </t> |
---|
| 2712 | </section> |
---|
| 2713 | |
---|
| 2714 | <section title="Trailer" anchor="header.trailer"> |
---|
| 2715 | <iref primary="true" item="Trailer header" x:for-anchor=""/> |
---|
| 2716 | <iref primary="true" item="Headers" subitem="Trailer" x:for-anchor=""/> |
---|
[229] | 2717 | <x:anchor-alias value="Trailer"/> |
---|
[8] | 2718 | <t> |
---|
| 2719 | The Trailer general field value indicates that the given set of |
---|
| 2720 | header fields is present in the trailer of a message encoded with |
---|
| 2721 | chunked transfer-coding. |
---|
| 2722 | </t> |
---|
| 2723 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> |
---|
[229] | 2724 | <x:ref>Trailer</x:ref> = "Trailer" ":" 1#<x:ref>field-name</x:ref> |
---|
[8] | 2725 | </artwork></figure> |
---|
| 2726 | <t> |
---|
| 2727 | An HTTP/1.1 message &SHOULD; include a Trailer header field in a |
---|
| 2728 | message using chunked transfer-coding with a non-empty trailer. Doing |
---|
| 2729 | so allows the recipient to know which header fields to expect in the |
---|
| 2730 | trailer. |
---|
| 2731 | </t> |
---|
| 2732 | <t> |
---|
| 2733 | If no Trailer header field is present, the trailer &SHOULD-NOT; include |
---|
| 2734 | any header fields. See <xref target="chunked.transfer.encoding"/> for restrictions on the use of |
---|
| 2735 | trailer fields in a "chunked" transfer-coding. |
---|
| 2736 | </t> |
---|
| 2737 | <t> |
---|
| 2738 | Message header fields listed in the Trailer header field &MUST-NOT; |
---|
| 2739 | include the following header fields: |
---|
| 2740 | <list style="symbols"> |
---|
| 2741 | <t>Transfer-Encoding</t> |
---|
| 2742 | <t>Content-Length</t> |
---|
| 2743 | <t>Trailer</t> |
---|
| 2744 | </list> |
---|
| 2745 | </t> |
---|
| 2746 | </section> |
---|
| 2747 | |
---|
| 2748 | <section title="Transfer-Encoding" anchor="header.transfer-encoding"> |
---|
| 2749 | <iref primary="true" item="Transfer-Encoding header" x:for-anchor=""/> |
---|
| 2750 | <iref primary="true" item="Headers" subitem="Transfer-Encoding" x:for-anchor=""/> |
---|
[229] | 2751 | <x:anchor-alias value="Transfer-Encoding"/> |
---|
[8] | 2752 | <t> |
---|
| 2753 | The Transfer-Encoding general-header field indicates what (if any) |
---|
| 2754 | type of transformation has been applied to the message body in order |
---|
| 2755 | to safely transfer it between the sender and the recipient. This |
---|
| 2756 | differs from the content-coding in that the transfer-coding is a |
---|
| 2757 | property of the message, not of the entity. |
---|
| 2758 | </t> |
---|
| 2759 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> |
---|
[229] | 2760 | <x:ref>Transfer-Encoding</x:ref> = "Transfer-Encoding" ":" 1#<x:ref>transfer-coding</x:ref> |
---|
[8] | 2761 | </artwork></figure> |
---|
| 2762 | <t> |
---|
| 2763 | Transfer-codings are defined in <xref target="transfer.codings"/>. An example is: |
---|
| 2764 | </t> |
---|
| 2765 | <figure><artwork type="example"> |
---|
| 2766 | Transfer-Encoding: chunked |
---|
| 2767 | </artwork></figure> |
---|
| 2768 | <t> |
---|
| 2769 | If multiple encodings have been applied to an entity, the transfer-codings |
---|
| 2770 | &MUST; be listed in the order in which they were applied. |
---|
| 2771 | Additional information about the encoding parameters &MAY; be provided |
---|
| 2772 | by other entity-header fields not defined by this specification. |
---|
| 2773 | </t> |
---|
| 2774 | <t> |
---|
| 2775 | Many older HTTP/1.0 applications do not understand the Transfer-Encoding |
---|
| 2776 | header. |
---|
| 2777 | </t> |
---|
| 2778 | </section> |
---|
| 2779 | |
---|
| 2780 | <section title="Upgrade" anchor="header.upgrade"> |
---|
| 2781 | <iref primary="true" item="Upgrade header" x:for-anchor=""/> |
---|
| 2782 | <iref primary="true" item="Headers" subitem="Upgrade" x:for-anchor=""/> |
---|
[229] | 2783 | <x:anchor-alias value="Upgrade"/> |
---|
[8] | 2784 | <t> |
---|
| 2785 | The Upgrade general-header allows the client to specify what |
---|
| 2786 | additional communication protocols it supports and would like to use |
---|
| 2787 | if the server finds it appropriate to switch protocols. The server |
---|
| 2788 | &MUST; use the Upgrade header field within a 101 (Switching Protocols) |
---|
| 2789 | response to indicate which protocol(s) are being switched. |
---|
| 2790 | </t> |
---|
| 2791 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> |
---|
[229] | 2792 | <x:ref>Upgrade</x:ref> = "Upgrade" ":" 1#<x:ref>product</x:ref> |
---|
[8] | 2793 | </artwork></figure> |
---|
| 2794 | <t> |
---|
| 2795 | For example, |
---|
| 2796 | </t> |
---|
| 2797 | <figure><artwork type="example"> |
---|
| 2798 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
---|
| 2799 | </artwork></figure> |
---|
| 2800 | <t> |
---|
| 2801 | The Upgrade header field is intended to provide a simple mechanism |
---|
| 2802 | for transition from HTTP/1.1 to some other, incompatible protocol. It |
---|
| 2803 | does so by allowing the client to advertise its desire to use another |
---|
| 2804 | protocol, such as a later version of HTTP with a higher major version |
---|
| 2805 | number, even though the current request has been made using HTTP/1.1. |
---|
| 2806 | This eases the difficult transition between incompatible protocols by |
---|
| 2807 | allowing the client to initiate a request in the more commonly |
---|
| 2808 | supported protocol while indicating to the server that it would like |
---|
| 2809 | to use a "better" protocol if available (where "better" is determined |
---|
| 2810 | by the server, possibly according to the nature of the method and/or |
---|
| 2811 | resource being requested). |
---|
| 2812 | </t> |
---|
| 2813 | <t> |
---|
| 2814 | The Upgrade header field only applies to switching application-layer |
---|
| 2815 | protocols upon the existing transport-layer connection. Upgrade |
---|
| 2816 | cannot be used to insist on a protocol change; its acceptance and use |
---|
| 2817 | by the server is optional. The capabilities and nature of the |
---|
| 2818 | application-layer communication after the protocol change is entirely |
---|
| 2819 | dependent upon the new protocol chosen, although the first action |
---|
| 2820 | after changing the protocol &MUST; be a response to the initial HTTP |
---|
| 2821 | request containing the Upgrade header field. |
---|
| 2822 | </t> |
---|
| 2823 | <t> |
---|
| 2824 | The Upgrade header field only applies to the immediate connection. |
---|
| 2825 | Therefore, the upgrade keyword &MUST; be supplied within a Connection |
---|
| 2826 | header field (<xref target="header.connection"/>) whenever Upgrade is present in an |
---|
| 2827 | HTTP/1.1 message. |
---|
| 2828 | </t> |
---|
| 2829 | <t> |
---|
| 2830 | The Upgrade header field cannot be used to indicate a switch to a |
---|
| 2831 | protocol on a different connection. For that purpose, it is more |
---|
| 2832 | appropriate to use a 301, 302, 303, or 305 redirection response. |
---|
| 2833 | </t> |
---|
| 2834 | <t> |
---|
| 2835 | This specification only defines the protocol name "HTTP" for use by |
---|
| 2836 | the family of Hypertext Transfer Protocols, as defined by the HTTP |
---|
| 2837 | version rules of <xref target="http.version"/> and future updates to this |
---|
| 2838 | specification. Any token can be used as a protocol name; however, it |
---|
| 2839 | will only be useful if both the client and server associate the name |
---|
| 2840 | with the same protocol. |
---|
| 2841 | </t> |
---|
| 2842 | </section> |
---|
| 2843 | |
---|
| 2844 | <section title="Via" anchor="header.via"> |
---|
| 2845 | <iref primary="true" item="Via header" x:for-anchor=""/> |
---|
| 2846 | <iref primary="true" item="Headers" subitem="Via" x:for-anchor=""/> |
---|
[229] | 2847 | <x:anchor-alias value="protocol-name"/> |
---|
| 2848 | <x:anchor-alias value="protocol-version"/> |
---|
| 2849 | <x:anchor-alias value="pseudonym"/> |
---|
| 2850 | <x:anchor-alias value="received-by"/> |
---|
| 2851 | <x:anchor-alias value="received-protocol"/> |
---|
| 2852 | <x:anchor-alias value="Via"/> |
---|
[8] | 2853 | <t> |
---|
| 2854 | The Via general-header field &MUST; be used by gateways and proxies to |
---|
| 2855 | indicate the intermediate protocols and recipients between the user |
---|
| 2856 | agent and the server on requests, and between the origin server and |
---|
[257] | 2857 | the client on responses. It is analogous to the "Received" field defined in |
---|
| 2858 | <xref target="RFC2822" x:fmt="of" x:sec="3.6.7"/> and is intended to be used for tracking message forwards, |
---|
[8] | 2859 | avoiding request loops, and identifying the protocol capabilities of |
---|
| 2860 | all senders along the request/response chain. |
---|
| 2861 | </t> |
---|
| 2862 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/> |
---|
[229] | 2863 | <x:ref>Via</x:ref> = "Via" ":" 1#( <x:ref>received-protocol</x:ref> <x:ref>received-by</x:ref> [ <x:ref>comment</x:ref> ] ) |
---|
| 2864 | <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref> |
---|
| 2865 | <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref> |
---|
| 2866 | <x:ref>protocol-version</x:ref> = <x:ref>token</x:ref> |
---|
| 2867 | <x:ref>received-by</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) | <x:ref>pseudonym</x:ref> |
---|
| 2868 | <x:ref>pseudonym</x:ref> = <x:ref>token</x:ref> |
---|
[8] | 2869 | </artwork></figure> |
---|
| 2870 | <t> |
---|
| 2871 | The received-protocol indicates the protocol version of the message |
---|
| 2872 | received by the server or client along each segment of the |
---|
| 2873 | request/response chain. The received-protocol version is appended to |
---|
| 2874 | the Via field value when the message is forwarded so that information |
---|
| 2875 | about the protocol capabilities of upstream applications remains |
---|
| 2876 | visible to all recipients. |
---|
| 2877 | </t> |
---|
| 2878 | <t> |
---|
| 2879 | The protocol-name is optional if and only if it would be "HTTP". The |
---|
| 2880 | received-by field is normally the host and optional port number of a |
---|
| 2881 | recipient server or client that subsequently forwarded the message. |
---|
| 2882 | However, if the real host is considered to be sensitive information, |
---|
| 2883 | it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY; |
---|
| 2884 | be assumed to be the default port of the received-protocol. |
---|
| 2885 | </t> |
---|
| 2886 | <t> |
---|
| 2887 | Multiple Via field values represents each proxy or gateway that has |
---|
| 2888 | forwarded the message. Each recipient &MUST; append its information |
---|
| 2889 | such that the end result is ordered according to the sequence of |
---|
| 2890 | forwarding applications. |
---|
| 2891 | </t> |
---|
| 2892 | <t> |
---|
| 2893 | Comments &MAY; be used in the Via header field to identify the software |
---|
| 2894 | of the recipient proxy or gateway, analogous to the User-Agent and |
---|
| 2895 | Server header fields. However, all comments in the Via field are |
---|
| 2896 | optional and &MAY; be removed by any recipient prior to forwarding the |
---|
| 2897 | message. |
---|
| 2898 | </t> |
---|
| 2899 | <t> |
---|
| 2900 | For example, a request message could be sent from an HTTP/1.0 user |
---|
| 2901 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
---|
[90] | 2902 | forward the request to a public proxy at p.example.net, which completes |
---|
| 2903 | the request by forwarding it to the origin server at www.example.com. |
---|
| 2904 | The request received by www.example.com would then have the following |
---|
[8] | 2905 | Via header field: |
---|
| 2906 | </t> |
---|
| 2907 | <figure><artwork type="example"> |
---|
[90] | 2908 | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
---|
[8] | 2909 | </artwork></figure> |
---|
| 2910 | <t> |
---|
| 2911 | Proxies and gateways used as a portal through a network firewall |
---|
| 2912 | &SHOULD-NOT;, by default, forward the names and ports of hosts within |
---|
| 2913 | the firewall region. This information &SHOULD; only be propagated if |
---|
| 2914 | explicitly enabled. If not enabled, the received-by host of any host |
---|
| 2915 | behind the firewall &SHOULD; be replaced by an appropriate pseudonym |
---|
| 2916 | for that host. |
---|
| 2917 | </t> |
---|
| 2918 | <t> |
---|
| 2919 | For organizations that have strong privacy requirements for hiding |
---|
| 2920 | internal structures, a proxy &MAY; combine an ordered subsequence of |
---|
| 2921 | Via header field entries with identical received-protocol values into |
---|
| 2922 | a single such entry. For example, |
---|
| 2923 | </t> |
---|
| 2924 | <figure><artwork type="example"> |
---|
| 2925 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
---|
| 2926 | </artwork></figure> |
---|
| 2927 | <t> |
---|
| 2928 | could be collapsed to |
---|
| 2929 | </t> |
---|
| 2930 | <figure><artwork type="example"> |
---|
| 2931 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
---|
| 2932 | </artwork></figure> |
---|
| 2933 | <t> |
---|
| 2934 | Applications &SHOULD-NOT; combine multiple entries unless they are all |
---|
| 2935 | under the same organizational control and the hosts have already been |
---|
| 2936 | replaced by pseudonyms. Applications &MUST-NOT; combine entries which |
---|
| 2937 | have different received-protocol values. |
---|
| 2938 | </t> |
---|
| 2939 | </section> |
---|
| 2940 | |
---|
| 2941 | </section> |
---|
| 2942 | |
---|
[29] | 2943 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
[253] | 2944 | <section title="Message Header Registration" anchor="message.header.registration"> |
---|
[8] | 2945 | <t> |
---|
[290] | 2946 | The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated |
---|
| 2947 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
[8] | 2948 | </t> |
---|
[290] | 2949 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
| 2950 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
[253] | 2951 | <ttcol>Header Field Name</ttcol> |
---|
| 2952 | <ttcol>Protocol</ttcol> |
---|
| 2953 | <ttcol>Status</ttcol> |
---|
| 2954 | <ttcol>Reference</ttcol> |
---|
| 2955 | |
---|
| 2956 | <c>Connection</c> |
---|
| 2957 | <c>http</c> |
---|
| 2958 | <c>standard</c> |
---|
| 2959 | <c> |
---|
| 2960 | <xref target="header.connection"/> |
---|
| 2961 | </c> |
---|
| 2962 | <c>Content-Length</c> |
---|
| 2963 | <c>http</c> |
---|
| 2964 | <c>standard</c> |
---|
| 2965 | <c> |
---|
| 2966 | <xref target="header.content-length"/> |
---|
| 2967 | </c> |
---|
| 2968 | <c>Date</c> |
---|
| 2969 | <c>http</c> |
---|
| 2970 | <c>standard</c> |
---|
| 2971 | <c> |
---|
| 2972 | <xref target="header.date"/> |
---|
| 2973 | </c> |
---|
| 2974 | <c>Host</c> |
---|
| 2975 | <c>http</c> |
---|
| 2976 | <c>standard</c> |
---|
| 2977 | <c> |
---|
| 2978 | <xref target="header.host"/> |
---|
| 2979 | </c> |
---|
| 2980 | <c>TE</c> |
---|
| 2981 | <c>http</c> |
---|
| 2982 | <c>standard</c> |
---|
| 2983 | <c> |
---|
| 2984 | <xref target="header.te"/> |
---|
| 2985 | </c> |
---|
| 2986 | <c>Trailer</c> |
---|
| 2987 | <c>http</c> |
---|
| 2988 | <c>standard</c> |
---|
| 2989 | <c> |
---|
| 2990 | <xref target="header.trailer"/> |
---|
| 2991 | </c> |
---|
| 2992 | <c>Transfer-Encoding</c> |
---|
| 2993 | <c>http</c> |
---|
| 2994 | <c>standard</c> |
---|
| 2995 | <c> |
---|
| 2996 | <xref target="header.transfer-encoding"/> |
---|
| 2997 | </c> |
---|
| 2998 | <c>Upgrade</c> |
---|
| 2999 | <c>http</c> |
---|
| 3000 | <c>standard</c> |
---|
| 3001 | <c> |
---|
| 3002 | <xref target="header.upgrade"/> |
---|
| 3003 | </c> |
---|
| 3004 | <c>Via</c> |
---|
| 3005 | <c>http</c> |
---|
| 3006 | <c>standard</c> |
---|
| 3007 | <c> |
---|
| 3008 | <xref target="header.via"/> |
---|
| 3009 | </c> |
---|
| 3010 | </texttable> |
---|
[290] | 3011 | <!--(END)--> |
---|
[253] | 3012 | <t> |
---|
[290] | 3013 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
[253] | 3014 | </t> |
---|
[8] | 3015 | </section> |
---|
[307] | 3016 | |
---|
| 3017 | <section title="URI Scheme Registration" anchor="uri.scheme.registration"> |
---|
| 3018 | <t> |
---|
| 3019 | The entry for the "http" URI Scheme in the registry located at |
---|
| 3020 | <eref target="http://www.iana.org/assignments/uri-schemes.html"/> |
---|
| 3021 | should be updated to point to <xref target="http.url"/> of this document |
---|
| 3022 | (see <xref target="RFC4395"/>). |
---|
| 3023 | </t> |
---|
| 3024 | </section> |
---|
| 3025 | |
---|
[296] | 3026 | <section title="Internet Media Type Registrations" anchor="internet.media.type.http"> |
---|
| 3027 | <t> |
---|
| 3028 | This document serves as the specification for the Internet media types |
---|
| 3029 | "message/http" and "application/http". The following is to be registered with |
---|
| 3030 | IANA (see <xref target="RFC4288"/>). |
---|
| 3031 | </t> |
---|
| 3032 | <section title="Internet Media Type message/http" anchor="internet.media.type.message.http"> |
---|
| 3033 | <iref item="Media Type" subitem="message/http" primary="true"/> |
---|
| 3034 | <iref item="message/http Media Type" primary="true"/> |
---|
| 3035 | <t> |
---|
| 3036 | The message/http type can be used to enclose a single HTTP request or |
---|
| 3037 | response message, provided that it obeys the MIME restrictions for all |
---|
| 3038 | "message" types regarding line length and encodings. |
---|
| 3039 | </t> |
---|
| 3040 | <t> |
---|
| 3041 | <list style="hanging" x:indent="12em"> |
---|
| 3042 | <t hangText="Type name:"> |
---|
| 3043 | message |
---|
| 3044 | </t> |
---|
| 3045 | <t hangText="Subtype name:"> |
---|
| 3046 | http |
---|
| 3047 | </t> |
---|
| 3048 | <t hangText="Required parameters:"> |
---|
| 3049 | none |
---|
| 3050 | </t> |
---|
| 3051 | <t hangText="Optional parameters:"> |
---|
| 3052 | version, msgtype |
---|
| 3053 | <list style="hanging"> |
---|
| 3054 | <t hangText="version:"> |
---|
| 3055 | The HTTP-Version number of the enclosed message |
---|
| 3056 | (e.g., "1.1"). If not present, the version can be |
---|
| 3057 | determined from the first line of the body. |
---|
| 3058 | </t> |
---|
| 3059 | <t hangText="msgtype:"> |
---|
| 3060 | The message type -- "request" or "response". If not |
---|
| 3061 | present, the type can be determined from the first |
---|
| 3062 | line of the body. |
---|
| 3063 | </t> |
---|
| 3064 | </list> |
---|
| 3065 | </t> |
---|
| 3066 | <t hangText="Encoding considerations:"> |
---|
| 3067 | only "7bit", "8bit", or "binary" are permitted |
---|
| 3068 | </t> |
---|
| 3069 | <t hangText="Security considerations:"> |
---|
| 3070 | none |
---|
| 3071 | </t> |
---|
| 3072 | <t hangText="Interoperability considerations:"> |
---|
| 3073 | none |
---|
| 3074 | </t> |
---|
| 3075 | <t hangText="Published specification:"> |
---|
| 3076 | This specification (see <xref target="internet.media.type.message.http"/>). |
---|
| 3077 | </t> |
---|
| 3078 | <t hangText="Applications that use this media type:"> |
---|
| 3079 | </t> |
---|
| 3080 | <t hangText="Additional information:"> |
---|
| 3081 | <list style="hanging"> |
---|
| 3082 | <t hangText="Magic number(s):">none</t> |
---|
| 3083 | <t hangText="File extension(s):">none</t> |
---|
| 3084 | <t hangText="Macintosh file type code(s):">none</t> |
---|
| 3085 | </list> |
---|
| 3086 | </t> |
---|
| 3087 | <t hangText="Person and email address to contact for further information:"> |
---|
| 3088 | See Authors Section. |
---|
| 3089 | </t> |
---|
| 3090 | <t hangText="Intended usage:"> |
---|
| 3091 | COMMON |
---|
| 3092 | </t> |
---|
| 3093 | <t hangText="Restrictions on usage:"> |
---|
| 3094 | none |
---|
| 3095 | </t> |
---|
| 3096 | <t hangText="Author/Change controller:"> |
---|
| 3097 | IESG |
---|
| 3098 | </t> |
---|
| 3099 | </list> |
---|
| 3100 | </t> |
---|
[253] | 3101 | </section> |
---|
[296] | 3102 | <section title="Internet Media Type application/http" anchor="internet.media.type.application.http"> |
---|
| 3103 | <iref item="Media Type" subitem="application/http" primary="true"/> |
---|
| 3104 | <iref item="application/http Media Type" primary="true"/> |
---|
| 3105 | <t> |
---|
| 3106 | The application/http type can be used to enclose a pipeline of one or more |
---|
| 3107 | HTTP request or response messages (not intermixed). |
---|
| 3108 | </t> |
---|
| 3109 | <t> |
---|
| 3110 | <list style="hanging" x:indent="12em"> |
---|
| 3111 | <t hangText="Type name:"> |
---|
| 3112 | application |
---|
| 3113 | </t> |
---|
| 3114 | <t hangText="Subtype name:"> |
---|
| 3115 | http |
---|
| 3116 | </t> |
---|
| 3117 | <t hangText="Required parameters:"> |
---|
| 3118 | none |
---|
| 3119 | </t> |
---|
| 3120 | <t hangText="Optional parameters:"> |
---|
| 3121 | version, msgtype |
---|
| 3122 | <list style="hanging"> |
---|
| 3123 | <t hangText="version:"> |
---|
| 3124 | The HTTP-Version number of the enclosed messages |
---|
| 3125 | (e.g., "1.1"). If not present, the version can be |
---|
| 3126 | determined from the first line of the body. |
---|
| 3127 | </t> |
---|
| 3128 | <t hangText="msgtype:"> |
---|
| 3129 | The message type -- "request" or "response". If not |
---|
| 3130 | present, the type can be determined from the first |
---|
| 3131 | line of the body. |
---|
| 3132 | </t> |
---|
| 3133 | </list> |
---|
| 3134 | </t> |
---|
| 3135 | <t hangText="Encoding considerations:"> |
---|
| 3136 | HTTP messages enclosed by this type |
---|
| 3137 | are in "binary" format; use of an appropriate |
---|
| 3138 | Content-Transfer-Encoding is required when |
---|
| 3139 | transmitted via E-mail. |
---|
| 3140 | </t> |
---|
| 3141 | <t hangText="Security considerations:"> |
---|
| 3142 | none |
---|
| 3143 | </t> |
---|
| 3144 | <t hangText="Interoperability considerations:"> |
---|
| 3145 | none |
---|
| 3146 | </t> |
---|
| 3147 | <t hangText="Published specification:"> |
---|
| 3148 | This specification (see <xref target="internet.media.type.application.http"/>). |
---|
| 3149 | </t> |
---|
| 3150 | <t hangText="Applications that use this media type:"> |
---|
| 3151 | </t> |
---|
| 3152 | <t hangText="Additional information:"> |
---|
| 3153 | <list style="hanging"> |
---|
| 3154 | <t hangText="Magic number(s):">none</t> |
---|
| 3155 | <t hangText="File extension(s):">none</t> |
---|
| 3156 | <t hangText="Macintosh file type code(s):">none</t> |
---|
| 3157 | </list> |
---|
| 3158 | </t> |
---|
| 3159 | <t hangText="Person and email address to contact for further information:"> |
---|
| 3160 | See Authors Section. |
---|
| 3161 | </t> |
---|
| 3162 | <t hangText="Intended usage:"> |
---|
| 3163 | COMMON |
---|
| 3164 | </t> |
---|
| 3165 | <t hangText="Restrictions on usage:"> |
---|
| 3166 | none |
---|
| 3167 | </t> |
---|
| 3168 | <t hangText="Author/Change controller:"> |
---|
| 3169 | IESG |
---|
| 3170 | </t> |
---|
| 3171 | </list> |
---|
| 3172 | </t> |
---|
| 3173 | </section> |
---|
| 3174 | </section> |
---|
[307] | 3175 | |
---|
[296] | 3176 | </section> |
---|
[8] | 3177 | |
---|
| 3178 | <section title="Security Considerations" anchor="security.considerations"> |
---|
| 3179 | <t> |
---|
| 3180 | This section is meant to inform application developers, information |
---|
| 3181 | providers, and users of the security limitations in HTTP/1.1 as |
---|
| 3182 | described by this document. The discussion does not include |
---|
| 3183 | definitive solutions to the problems revealed, though it does make |
---|
| 3184 | some suggestions for reducing security risks. |
---|
| 3185 | </t> |
---|
| 3186 | |
---|
| 3187 | <section title="Personal Information" anchor="personal.information"> |
---|
| 3188 | <t> |
---|
| 3189 | HTTP clients are often privy to large amounts of personal information |
---|
| 3190 | (e.g. the user's name, location, mail address, passwords, encryption |
---|
| 3191 | keys, etc.), and &SHOULD; be very careful to prevent unintentional |
---|
[172] | 3192 | leakage of this information. |
---|
[8] | 3193 | We very strongly recommend that a convenient interface be provided |
---|
| 3194 | for the user to control dissemination of such information, and that |
---|
| 3195 | designers and implementors be particularly careful in this area. |
---|
| 3196 | History shows that errors in this area often create serious security |
---|
| 3197 | and/or privacy problems and generate highly adverse publicity for the |
---|
| 3198 | implementor's company. |
---|
| 3199 | </t> |
---|
[29] | 3200 | </section> |
---|
[8] | 3201 | |
---|
| 3202 | <section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information"> |
---|
| 3203 | <t> |
---|
| 3204 | A server is in the position to save personal data about a user's |
---|
| 3205 | requests which might identify their reading patterns or subjects of |
---|
| 3206 | interest. This information is clearly confidential in nature and its |
---|
| 3207 | handling can be constrained by law in certain countries. People using |
---|
[172] | 3208 | HTTP to provide data are responsible for ensuring that |
---|
[8] | 3209 | such material is not distributed without the permission of any |
---|
| 3210 | individuals that are identifiable by the published results. |
---|
| 3211 | </t> |
---|
| 3212 | </section> |
---|
| 3213 | |
---|
| 3214 | <section title="Attacks Based On File and Path Names" anchor="attack.pathname"> |
---|
| 3215 | <t> |
---|
| 3216 | Implementations of HTTP origin servers &SHOULD; be careful to restrict |
---|
| 3217 | the documents returned by HTTP requests to be only those that were |
---|
| 3218 | intended by the server administrators. If an HTTP server translates |
---|
| 3219 | HTTP URIs directly into file system calls, the server &MUST; take |
---|
| 3220 | special care not to serve files that were not intended to be |
---|
| 3221 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
---|
| 3222 | other operating systems use ".." as a path component to indicate a |
---|
| 3223 | directory level above the current one. On such a system, an HTTP |
---|
| 3224 | server &MUST; disallow any such construct in the Request-URI if it |
---|
| 3225 | would otherwise allow access to a resource outside those intended to |
---|
| 3226 | be accessible via the HTTP server. Similarly, files intended for |
---|
| 3227 | reference only internally to the server (such as access control |
---|
| 3228 | files, configuration files, and script code) &MUST; be protected from |
---|
| 3229 | inappropriate retrieval, since they might contain sensitive |
---|
| 3230 | information. Experience has shown that minor bugs in such HTTP server |
---|
| 3231 | implementations have turned into security risks. |
---|
| 3232 | </t> |
---|
| 3233 | </section> |
---|
| 3234 | |
---|
| 3235 | <section title="DNS Spoofing" anchor="dns.spoofing"> |
---|
| 3236 | <t> |
---|
| 3237 | Clients using HTTP rely heavily on the Domain Name Service, and are |
---|
| 3238 | thus generally prone to security attacks based on the deliberate |
---|
| 3239 | mis-association of IP addresses and DNS names. Clients need to be |
---|
| 3240 | cautious in assuming the continuing validity of an IP number/DNS name |
---|
| 3241 | association. |
---|
| 3242 | </t> |
---|
| 3243 | <t> |
---|
| 3244 | In particular, HTTP clients &SHOULD; rely on their name resolver for |
---|
| 3245 | confirmation of an IP number/DNS name association, rather than |
---|
| 3246 | caching the result of previous host name lookups. Many platforms |
---|
| 3247 | already can cache host name lookups locally when appropriate, and |
---|
| 3248 | they &SHOULD; be configured to do so. It is proper for these lookups to |
---|
| 3249 | be cached, however, only when the TTL (Time To Live) information |
---|
| 3250 | reported by the name server makes it likely that the cached |
---|
| 3251 | information will remain useful. |
---|
| 3252 | </t> |
---|
| 3253 | <t> |
---|
| 3254 | If HTTP clients cache the results of host name lookups in order to |
---|
| 3255 | achieve a performance improvement, they &MUST; observe the TTL |
---|
| 3256 | information reported by DNS. |
---|
| 3257 | </t> |
---|
| 3258 | <t> |
---|
| 3259 | If HTTP clients do not observe this rule, they could be spoofed when |
---|
| 3260 | a previously-accessed server's IP address changes. As network |
---|
| 3261 | renumbering is expected to become increasingly common <xref target="RFC1900"/>, the |
---|
| 3262 | possibility of this form of attack will grow. Observing this |
---|
| 3263 | requirement thus reduces this potential security vulnerability. |
---|
| 3264 | </t> |
---|
| 3265 | <t> |
---|
| 3266 | This requirement also improves the load-balancing behavior of clients |
---|
| 3267 | for replicated servers using the same DNS name and reduces the |
---|
| 3268 | likelihood of a user's experiencing failure in accessing sites which |
---|
| 3269 | use that strategy. |
---|
| 3270 | </t> |
---|
| 3271 | </section> |
---|
| 3272 | |
---|
| 3273 | <section title="Proxies and Caching" anchor="attack.proxies"> |
---|
| 3274 | <t> |
---|
| 3275 | By their very nature, HTTP proxies are men-in-the-middle, and |
---|
| 3276 | represent an opportunity for man-in-the-middle attacks. Compromise of |
---|
| 3277 | the systems on which the proxies run can result in serious security |
---|
| 3278 | and privacy problems. Proxies have access to security-related |
---|
| 3279 | information, personal information about individual users and |
---|
| 3280 | organizations, and proprietary information belonging to users and |
---|
| 3281 | content providers. A compromised proxy, or a proxy implemented or |
---|
| 3282 | configured without regard to security and privacy considerations, |
---|
| 3283 | might be used in the commission of a wide range of potential attacks. |
---|
| 3284 | </t> |
---|
| 3285 | <t> |
---|
| 3286 | Proxy operators should protect the systems on which proxies run as |
---|
| 3287 | they would protect any system that contains or transports sensitive |
---|
| 3288 | information. In particular, log information gathered at proxies often |
---|
| 3289 | contains highly sensitive personal information, and/or information |
---|
| 3290 | about organizations. Log information should be carefully guarded, and |
---|
| 3291 | appropriate guidelines for use developed and followed. (<xref target="abuse.of.server.log.information"/>). |
---|
| 3292 | </t> |
---|
| 3293 | <t> |
---|
| 3294 | Proxy implementors should consider the privacy and security |
---|
| 3295 | implications of their design and coding decisions, and of the |
---|
| 3296 | configuration options they provide to proxy operators (especially the |
---|
| 3297 | default configuration). |
---|
| 3298 | </t> |
---|
| 3299 | <t> |
---|
| 3300 | Users of a proxy need to be aware that they are no trustworthier than |
---|
| 3301 | the people who run the proxy; HTTP itself cannot solve this problem. |
---|
| 3302 | </t> |
---|
| 3303 | <t> |
---|
| 3304 | The judicious use of cryptography, when appropriate, may suffice to |
---|
| 3305 | protect against a broad range of security and privacy attacks. Such |
---|
| 3306 | cryptography is beyond the scope of the HTTP/1.1 specification. |
---|
| 3307 | </t> |
---|
[29] | 3308 | </section> |
---|
[8] | 3309 | |
---|
| 3310 | <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS"> |
---|
| 3311 | <t> |
---|
| 3312 | They exist. They are hard to defend against. Research continues. |
---|
| 3313 | Beware. |
---|
| 3314 | </t> |
---|
| 3315 | </section> |
---|
| 3316 | </section> |
---|
| 3317 | |
---|
| 3318 | <section title="Acknowledgments" anchor="ack"> |
---|
| 3319 | <t> |
---|
| 3320 | This specification makes heavy use of the augmented BNF and generic |
---|
[133] | 3321 | constructs defined by David H. Crocker for <xref target="RFC822ABNF"/>. Similarly, it |
---|
[8] | 3322 | reuses many of the definitions provided by Nathaniel Borenstein and |
---|
| 3323 | Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this |
---|
| 3324 | specification will help reduce past confusion over the relationship |
---|
| 3325 | between HTTP and Internet mail message formats. |
---|
| 3326 | </t> |
---|
| 3327 | <t> |
---|
[172] | 3328 | HTTP has evolved considerably over the years. It has |
---|
[8] | 3329 | benefited from a large and active developer community--the many |
---|
| 3330 | people who have participated on the www-talk mailing list--and it is |
---|
| 3331 | that community which has been most responsible for the success of |
---|
| 3332 | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
---|
| 3333 | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
---|
| 3334 | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
---|
| 3335 | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
---|
| 3336 | VanHeyningen deserve special recognition for their efforts in |
---|
| 3337 | defining early aspects of the protocol. |
---|
| 3338 | </t> |
---|
| 3339 | <t> |
---|
| 3340 | This document has benefited greatly from the comments of all those |
---|
| 3341 | participating in the HTTP-WG. In addition to those already mentioned, |
---|
| 3342 | the following individuals have contributed to this specification: |
---|
| 3343 | </t> |
---|
| 3344 | <t> |
---|
[98] | 3345 | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
---|
| 3346 | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |
---|
| 3347 | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, |
---|
| 3348 | Koen Holtman, Alex Hopmann, Bob Jernigan, Shel Kaphan, Rohit Khare, |
---|
| 3349 | John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, |
---|
| 3350 | Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert Lunde, |
---|
| 3351 | John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David Morris, |
---|
| 3352 | Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott Powers, Owen Rees, |
---|
| 3353 | Luigi Rizzo, David Robinson, Marc Salomon, Rich Salz, |
---|
| 3354 | Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, |
---|
| 3355 | Simon E. Spero, Richard N. Taylor, Robert S. Thau, |
---|
| 3356 | Bill (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko, |
---|
| 3357 | Josh Cohen. |
---|
| 3358 | </t> |
---|
| 3359 | <t> |
---|
[33] | 3360 | Thanks to the "cave men" of Palo Alto. You know who you are. |
---|
| 3361 | </t> |
---|
| 3362 | <t> |
---|
[115] | 3363 | Jim Gettys (the editor of <xref target="RFC2616"/>) wishes particularly |
---|
| 3364 | to thank Roy Fielding, the editor of <xref target="RFC2068"/>, along |
---|
[33] | 3365 | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen |
---|
| 3366 | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and |
---|
| 3367 | Larry Masinter for their help. And thanks go particularly to Jeff |
---|
| 3368 | Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. |
---|
| 3369 | </t> |
---|
| 3370 | <t> |
---|
| 3371 | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |
---|
| 3372 | Frystyk implemented RFC 2068 early, and we wish to thank them for the |
---|
| 3373 | discovery of many of the problems that this document attempts to |
---|
| 3374 | rectify. |
---|
| 3375 | </t> |
---|
[8] | 3376 | </section> |
---|
| 3377 | |
---|
| 3378 | </middle> |
---|
| 3379 | <back> |
---|
| 3380 | |
---|
[119] | 3381 | <references title="Normative References"> |
---|
| 3382 | |
---|
[121] | 3383 | <reference anchor="ISO-8859-1"> |
---|
| 3384 | <front> |
---|
| 3385 | <title> |
---|
| 3386 | Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1 |
---|
| 3387 | </title> |
---|
| 3388 | <author> |
---|
| 3389 | <organization>International Organization for Standardization</organization> |
---|
| 3390 | </author> |
---|
| 3391 | <date year="1998"/> |
---|
| 3392 | </front> |
---|
| 3393 | <seriesInfo name="ISO/IEC" value="8859-1:1998"/> |
---|
| 3394 | </reference> |
---|
| 3395 | |
---|
[31] | 3396 | <reference anchor="Part2"> |
---|
[119] | 3397 | <front> |
---|
| 3398 | <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> |
---|
| 3399 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 3400 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 3401 | <address><email>fielding@gbiv.com</email></address> |
---|
| 3402 | </author> |
---|
| 3403 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3404 | <organization>One Laptop per Child</organization> |
---|
| 3405 | <address><email>jg@laptop.org</email></address> |
---|
| 3406 | </author> |
---|
| 3407 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3408 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 3409 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 3410 | </author> |
---|
| 3411 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 3412 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3413 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 3414 | </author> |
---|
| 3415 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3416 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 3417 | <address><email>LMM@acm.org</email></address> |
---|
| 3418 | </author> |
---|
| 3419 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 3420 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3421 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3422 | </author> |
---|
| 3423 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3424 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 3425 | <address><email>timbl@w3.org</email></address> |
---|
| 3426 | </author> |
---|
| 3427 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 3428 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 3429 | <address><email>ylafon@w3.org</email></address> |
---|
| 3430 | </author> |
---|
| 3431 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 3432 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 3433 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 3434 | </author> |
---|
| 3435 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 3436 | </front> |
---|
| 3437 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> |
---|
| 3438 | <x:source href="p2-semantics.xml" basename="p2-semantics"/> |
---|
[31] | 3439 | </reference> |
---|
| 3440 | |
---|
| 3441 | <reference anchor="Part3"> |
---|
[119] | 3442 | <front> |
---|
| 3443 | <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
| 3444 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 3445 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 3446 | <address><email>fielding@gbiv.com</email></address> |
---|
| 3447 | </author> |
---|
| 3448 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3449 | <organization>One Laptop per Child</organization> |
---|
| 3450 | <address><email>jg@laptop.org</email></address> |
---|
| 3451 | </author> |
---|
| 3452 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3453 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 3454 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 3455 | </author> |
---|
| 3456 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 3457 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3458 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 3459 | </author> |
---|
| 3460 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3461 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 3462 | <address><email>LMM@acm.org</email></address> |
---|
| 3463 | </author> |
---|
| 3464 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 3465 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3466 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3467 | </author> |
---|
| 3468 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3469 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 3470 | <address><email>timbl@w3.org</email></address> |
---|
| 3471 | </author> |
---|
| 3472 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 3473 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 3474 | <address><email>ylafon@w3.org</email></address> |
---|
| 3475 | </author> |
---|
| 3476 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 3477 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 3478 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 3479 | </author> |
---|
| 3480 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 3481 | </front> |
---|
| 3482 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/> |
---|
| 3483 | <x:source href="p3-payload.xml" basename="p3-payload"/> |
---|
[31] | 3484 | </reference> |
---|
| 3485 | |
---|
[138] | 3486 | <reference anchor="Part5"> |
---|
| 3487 | <front> |
---|
| 3488 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
| 3489 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 3490 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 3491 | <address><email>fielding@gbiv.com</email></address> |
---|
| 3492 | </author> |
---|
| 3493 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3494 | <organization>One Laptop per Child</organization> |
---|
| 3495 | <address><email>jg@laptop.org</email></address> |
---|
| 3496 | </author> |
---|
| 3497 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3498 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 3499 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 3500 | </author> |
---|
| 3501 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 3502 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3503 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 3504 | </author> |
---|
| 3505 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3506 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 3507 | <address><email>LMM@acm.org</email></address> |
---|
| 3508 | </author> |
---|
| 3509 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 3510 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3511 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3512 | </author> |
---|
| 3513 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3514 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 3515 | <address><email>timbl@w3.org</email></address> |
---|
| 3516 | </author> |
---|
| 3517 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 3518 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 3519 | <address><email>ylafon@w3.org</email></address> |
---|
| 3520 | </author> |
---|
| 3521 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 3522 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 3523 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 3524 | </author> |
---|
| 3525 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 3526 | </front> |
---|
| 3527 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/> |
---|
| 3528 | <x:source href="p5-range.xml" basename="p5-range"/> |
---|
| 3529 | </reference> |
---|
| 3530 | |
---|
[31] | 3531 | <reference anchor="Part6"> |
---|
[119] | 3532 | <front> |
---|
| 3533 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
| 3534 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 3535 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 3536 | <address><email>fielding@gbiv.com</email></address> |
---|
| 3537 | </author> |
---|
| 3538 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3539 | <organization>One Laptop per Child</organization> |
---|
| 3540 | <address><email>jg@laptop.org</email></address> |
---|
| 3541 | </author> |
---|
| 3542 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3543 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 3544 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 3545 | </author> |
---|
| 3546 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 3547 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3548 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 3549 | </author> |
---|
| 3550 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3551 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 3552 | <address><email>LMM@acm.org</email></address> |
---|
| 3553 | </author> |
---|
| 3554 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 3555 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 3556 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3557 | </author> |
---|
| 3558 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3559 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 3560 | <address><email>timbl@w3.org</email></address> |
---|
| 3561 | </author> |
---|
| 3562 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 3563 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 3564 | <address><email>ylafon@w3.org</email></address> |
---|
| 3565 | </author> |
---|
| 3566 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 3567 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 3568 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 3569 | </author> |
---|
| 3570 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 3571 | </front> |
---|
| 3572 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
| 3573 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
[31] | 3574 | </reference> |
---|
| 3575 | |
---|
[129] | 3576 | <reference anchor="RFC822ABNF"> |
---|
| 3577 | <front> |
---|
| 3578 | <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> |
---|
| 3579 | <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> |
---|
| 3580 | <organization>University of Delaware, Dept. of Electrical Engineering</organization> |
---|
| 3581 | <address><email>DCrocker@UDel-Relay</email></address> |
---|
| 3582 | </author> |
---|
| 3583 | <date month="August" day="13" year="1982"/> |
---|
| 3584 | </front> |
---|
| 3585 | <seriesInfo name="STD" value="11"/> |
---|
| 3586 | <seriesInfo name="RFC" value="822"/> |
---|
| 3587 | </reference> |
---|
| 3588 | |
---|
[131] | 3589 | <reference anchor="RFC2045"> |
---|
| 3590 | <front> |
---|
| 3591 | <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> |
---|
| 3592 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
| 3593 | <organization>Innosoft International, Inc.</organization> |
---|
| 3594 | <address><email>ned@innosoft.com</email></address> |
---|
| 3595 | </author> |
---|
| 3596 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
| 3597 | <organization>First Virtual Holdings</organization> |
---|
| 3598 | <address><email>nsb@nsb.fv.com</email></address> |
---|
| 3599 | </author> |
---|
| 3600 | <date month="November" year="1996"/> |
---|
| 3601 | </front> |
---|
| 3602 | <seriesInfo name="RFC" value="2045"/> |
---|
| 3603 | </reference> |
---|
| 3604 | |
---|
| 3605 | <reference anchor="RFC2047"> |
---|
| 3606 | <front> |
---|
| 3607 | <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> |
---|
| 3608 | <author initials="K." surname="Moore" fullname="Keith Moore"> |
---|
| 3609 | <organization>University of Tennessee</organization> |
---|
| 3610 | <address><email>moore@cs.utk.edu</email></address> |
---|
| 3611 | </author> |
---|
| 3612 | <date month="November" year="1996"/> |
---|
| 3613 | </front> |
---|
| 3614 | <seriesInfo name="RFC" value="2047"/> |
---|
| 3615 | </reference> |
---|
| 3616 | |
---|
[119] | 3617 | <reference anchor="RFC2119"> |
---|
| 3618 | <front> |
---|
| 3619 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
| 3620 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
| 3621 | <organization>Harvard University</organization> |
---|
| 3622 | <address><email>sob@harvard.edu</email></address> |
---|
| 3623 | </author> |
---|
| 3624 | <date month="March" year="1997"/> |
---|
| 3625 | </front> |
---|
| 3626 | <seriesInfo name="BCP" value="14"/> |
---|
| 3627 | <seriesInfo name="RFC" value="2119"/> |
---|
| 3628 | </reference> |
---|
| 3629 | |
---|
[132] | 3630 | <reference anchor="RFC2396"> |
---|
| 3631 | <front> |
---|
| 3632 | <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> |
---|
| 3633 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3634 | <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> |
---|
| 3635 | <address><email>timbl@w3.org</email></address> |
---|
| 3636 | </author> |
---|
| 3637 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3638 | <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> |
---|
| 3639 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3640 | </author> |
---|
| 3641 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3642 | <organization abbrev="Xerox Corporation">Xerox PARC</organization> |
---|
| 3643 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3644 | </author> |
---|
| 3645 | <date month="August" year="1998"/> |
---|
| 3646 | </front> |
---|
| 3647 | <seriesInfo name="RFC" value="2396"/> |
---|
| 3648 | </reference> |
---|
| 3649 | |
---|
| 3650 | <reference anchor="USASCII"> |
---|
| 3651 | <front> |
---|
| 3652 | <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title> |
---|
| 3653 | <author> |
---|
| 3654 | <organization>American National Standards Institute</organization> |
---|
| 3655 | </author> |
---|
| 3656 | <date year="1986"/> |
---|
| 3657 | </front> |
---|
| 3658 | <seriesInfo name="ANSI" value="X3.4"/> |
---|
| 3659 | </reference> |
---|
| 3660 | |
---|
[119] | 3661 | </references> |
---|
| 3662 | |
---|
| 3663 | <references title="Informative References"> |
---|
| 3664 | |
---|
[129] | 3665 | <reference anchor="Nie1997" target="http://doi.acm.org/10.1145/263105.263157"> |
---|
| 3666 | <front> |
---|
| 3667 | <title>Network Performance Effects of HTTP/1.1, CSS1, and PNG</title> |
---|
| 3668 | <author initials="H.F.." surname="Nielsen" fullname="H.F. Nielsen"> |
---|
| 3669 | <organization/> |
---|
| 3670 | </author> |
---|
| 3671 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
| 3672 | <organization/> |
---|
| 3673 | </author> |
---|
| 3674 | <author initials="E." surname="Prud'hommeaux" fullname="E. Prud'hommeaux"> |
---|
| 3675 | <organization/> |
---|
| 3676 | </author> |
---|
| 3677 | <author initials="H." surname="Lie" fullname="H. Lie"> |
---|
| 3678 | <organization/> |
---|
| 3679 | </author> |
---|
| 3680 | <author initials="C." surname="Lilley" fullname="C. Lilley"> |
---|
| 3681 | <organization/> |
---|
| 3682 | </author> |
---|
| 3683 | <date year="1997" month="September"/> |
---|
| 3684 | </front> |
---|
| 3685 | <seriesInfo name="ACM" value="Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication SIGCOMM '97"/> |
---|
| 3686 | </reference> |
---|
| 3687 | |
---|
[275] | 3688 | <reference anchor="Pad1995" target="http://portal.acm.org/citation.cfm?id=219094"> |
---|
[129] | 3689 | <front> |
---|
| 3690 | <title>Improving HTTP Latency</title> |
---|
| 3691 | <author initials="V.N." surname="Padmanabhan" fullname="Venkata N. Padmanabhan"> |
---|
| 3692 | <organization/> |
---|
| 3693 | </author> |
---|
| 3694 | <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3695 | <organization/> |
---|
| 3696 | </author> |
---|
| 3697 | <date year="1995" month="December"/> |
---|
| 3698 | </front> |
---|
| 3699 | <seriesInfo name="Computer Networks and ISDN Systems" value="v. 28, pp. 25-35"/> |
---|
| 3700 | </reference> |
---|
| 3701 | |
---|
| 3702 | <reference anchor="RFC822"> |
---|
| 3703 | <front> |
---|
| 3704 | <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> |
---|
| 3705 | <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> |
---|
| 3706 | <organization>University of Delaware, Dept. of Electrical Engineering</organization> |
---|
| 3707 | <address><email>DCrocker@UDel-Relay</email></address> |
---|
| 3708 | </author> |
---|
| 3709 | <date month="August" day="13" year="1982"/> |
---|
| 3710 | </front> |
---|
| 3711 | <seriesInfo name="STD" value="11"/> |
---|
| 3712 | <seriesInfo name="RFC" value="822"/> |
---|
| 3713 | </reference> |
---|
| 3714 | |
---|
| 3715 | <reference anchor="RFC959"> |
---|
| 3716 | <front> |
---|
| 3717 | <title abbrev="File Transfer Protocol">File Transfer Protocol</title> |
---|
| 3718 | <author initials="J." surname="Postel" fullname="J. Postel"> |
---|
| 3719 | <organization>Information Sciences Institute (ISI)</organization> |
---|
| 3720 | </author> |
---|
| 3721 | <author initials="J." surname="Reynolds" fullname="J. Reynolds"> |
---|
| 3722 | <organization/> |
---|
| 3723 | </author> |
---|
| 3724 | <date month="October" year="1985"/> |
---|
| 3725 | </front> |
---|
| 3726 | <seriesInfo name="STD" value="9"/> |
---|
| 3727 | <seriesInfo name="RFC" value="959"/> |
---|
| 3728 | </reference> |
---|
| 3729 | |
---|
| 3730 | <reference anchor="RFC1123"> |
---|
| 3731 | <front> |
---|
| 3732 | <title>Requirements for Internet Hosts - Application and Support</title> |
---|
| 3733 | <author initials="R." surname="Braden" fullname="Robert Braden"> |
---|
| 3734 | <organization>University of Southern California (USC), Information Sciences Institute</organization> |
---|
| 3735 | <address><email>Braden@ISI.EDU</email></address> |
---|
| 3736 | </author> |
---|
| 3737 | <date month="October" year="1989"/> |
---|
| 3738 | </front> |
---|
| 3739 | <seriesInfo name="STD" value="3"/> |
---|
| 3740 | <seriesInfo name="RFC" value="1123"/> |
---|
| 3741 | </reference> |
---|
| 3742 | |
---|
| 3743 | <reference anchor="RFC1305"> |
---|
| 3744 | <front> |
---|
| 3745 | <title>Network Time Protocol (Version 3) Specification, Implementation</title> |
---|
| 3746 | <author initials="D." surname="Mills" fullname="David L. Mills"> |
---|
| 3747 | <organization>University of Delaware, Electrical Engineering Department</organization> |
---|
| 3748 | <address><email>mills@udel.edu</email></address> |
---|
| 3749 | </author> |
---|
| 3750 | <date month="March" year="1992"/> |
---|
| 3751 | </front> |
---|
| 3752 | <seriesInfo name="RFC" value="1305"/> |
---|
| 3753 | </reference> |
---|
| 3754 | |
---|
| 3755 | <reference anchor="RFC1436"> |
---|
| 3756 | <front> |
---|
| 3757 | <title abbrev="Gopher">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</title> |
---|
| 3758 | <author initials="F." surname="Anklesaria" fullname="Farhad Anklesaria"> |
---|
| 3759 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3760 | <address><email>fxa@boombox.micro.umn.edu</email></address> |
---|
| 3761 | </author> |
---|
| 3762 | <author initials="M." surname="McCahill" fullname="Mark McCahill"> |
---|
| 3763 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3764 | <address><email>mpm@boombox.micro.umn.edu</email></address> |
---|
| 3765 | </author> |
---|
| 3766 | <author initials="P." surname="Lindner" fullname="Paul Lindner"> |
---|
| 3767 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3768 | <address><email>lindner@boombox.micro.umn.edu</email></address> |
---|
| 3769 | </author> |
---|
| 3770 | <author initials="D." surname="Johnson" fullname="David Johnson"> |
---|
| 3771 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3772 | <address><email>dmj@boombox.micro.umn.edu</email></address> |
---|
| 3773 | </author> |
---|
| 3774 | <author initials="D." surname="Torrey" fullname="Daniel Torrey"> |
---|
| 3775 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3776 | <address><email>daniel@boombox.micro.umn.edu</email></address> |
---|
| 3777 | </author> |
---|
| 3778 | <author initials="B." surname="Alberti" fullname="Bob Alberti"> |
---|
| 3779 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3780 | <address><email>alberti@boombox.micro.umn.edu</email></address> |
---|
| 3781 | </author> |
---|
| 3782 | <date month="March" year="1993"/> |
---|
| 3783 | </front> |
---|
| 3784 | <seriesInfo name="RFC" value="1436"/> |
---|
| 3785 | </reference> |
---|
| 3786 | |
---|
| 3787 | <reference anchor="RFC1630"> |
---|
| 3788 | <front> |
---|
| 3789 | <title abbrev="URIs in WWW">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</title> |
---|
| 3790 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3791 | <organization>CERN, World-Wide Web project</organization> |
---|
| 3792 | <address><email>timbl@info.cern.ch</email></address> |
---|
| 3793 | </author> |
---|
| 3794 | <date month="June" year="1994"/> |
---|
| 3795 | </front> |
---|
| 3796 | <seriesInfo name="RFC" value="1630"/> |
---|
| 3797 | </reference> |
---|
| 3798 | |
---|
[151] | 3799 | <reference anchor="RFC1737"> |
---|
| 3800 | <front> |
---|
| 3801 | <title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title> |
---|
| 3802 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3803 | <organization>Xerox Palo Alto Research Center</organization> |
---|
| 3804 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3805 | </author> |
---|
| 3806 | <author initials="K." surname="Sollins" fullname="Karen Sollins"> |
---|
| 3807 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3808 | <address><email>sollins@lcs.mit.edu</email></address> |
---|
| 3809 | </author> |
---|
| 3810 | <date month="December" year="1994"/> |
---|
| 3811 | </front> |
---|
| 3812 | <seriesInfo name="RFC" value="1737"/> |
---|
| 3813 | </reference> |
---|
| 3814 | |
---|
[129] | 3815 | <reference anchor="RFC1738"> |
---|
| 3816 | <front> |
---|
| 3817 | <title>Uniform Resource Locators (URL)</title> |
---|
| 3818 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3819 | <organization>CERN, World-Wide Web project</organization> |
---|
| 3820 | <address><email>timbl@info.cern.ch</email></address> |
---|
| 3821 | </author> |
---|
| 3822 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3823 | <organization>Xerox PARC</organization> |
---|
| 3824 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3825 | </author> |
---|
| 3826 | <author initials="M." surname="McCahill" fullname="Mark McCahill"> |
---|
| 3827 | <organization>University of Minnesota, Computer and Information Services</organization> |
---|
| 3828 | <address><email>mpm@boombox.micro.umn.edu</email></address> |
---|
| 3829 | </author> |
---|
| 3830 | <date month="December" year="1994"/> |
---|
| 3831 | </front> |
---|
| 3832 | <seriesInfo name="RFC" value="1738"/> |
---|
| 3833 | </reference> |
---|
| 3834 | |
---|
| 3835 | <reference anchor="RFC1808"> |
---|
| 3836 | <front> |
---|
| 3837 | <title>Relative Uniform Resource Locators</title> |
---|
| 3838 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3839 | <organization>University of California Irvine, Department of Information and Computer Science</organization> |
---|
| 3840 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3841 | </author> |
---|
| 3842 | <date month="June" year="1995"/> |
---|
| 3843 | </front> |
---|
| 3844 | <seriesInfo name="RFC" value="1808"/> |
---|
| 3845 | </reference> |
---|
| 3846 | |
---|
| 3847 | <reference anchor="RFC1900"> |
---|
| 3848 | <front> |
---|
| 3849 | <title>Renumbering Needs Work</title> |
---|
| 3850 | <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter"> |
---|
| 3851 | <organization>CERN, Computing and Networks Division</organization> |
---|
| 3852 | <address><email>brian@dxcoms.cern.ch</email></address> |
---|
| 3853 | </author> |
---|
| 3854 | <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter"> |
---|
| 3855 | <organization>cisco Systems</organization> |
---|
| 3856 | <address><email>yakov@cisco.com</email></address> |
---|
| 3857 | </author> |
---|
| 3858 | <date month="February" year="1996"/> |
---|
| 3859 | </front> |
---|
| 3860 | <seriesInfo name="RFC" value="1900"/> |
---|
| 3861 | </reference> |
---|
| 3862 | |
---|
| 3863 | <reference anchor="RFC1945"> |
---|
| 3864 | <front> |
---|
| 3865 | <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> |
---|
| 3866 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3867 | <organization>MIT, Laboratory for Computer Science</organization> |
---|
| 3868 | <address><email>timbl@w3.org</email></address> |
---|
| 3869 | </author> |
---|
| 3870 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3871 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
| 3872 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3873 | </author> |
---|
| 3874 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
| 3875 | <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> |
---|
| 3876 | <address><email>frystyk@w3.org</email></address> |
---|
| 3877 | </author> |
---|
| 3878 | <date month="May" year="1996"/> |
---|
| 3879 | </front> |
---|
| 3880 | <seriesInfo name="RFC" value="1945"/> |
---|
| 3881 | </reference> |
---|
| 3882 | |
---|
[119] | 3883 | <reference anchor="RFC2068"> |
---|
| 3884 | <front> |
---|
| 3885 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
| 3886 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3887 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
| 3888 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3889 | </author> |
---|
| 3890 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3891 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3892 | <address><email>jg@w3.org</email></address> |
---|
| 3893 | </author> |
---|
| 3894 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3895 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
| 3896 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 3897 | </author> |
---|
| 3898 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
| 3899 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3900 | <address><email>frystyk@w3.org</email></address> |
---|
| 3901 | </author> |
---|
| 3902 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3903 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3904 | <address><email>timbl@w3.org</email></address> |
---|
| 3905 | </author> |
---|
| 3906 | <date month="January" year="1997"/> |
---|
| 3907 | </front> |
---|
| 3908 | <seriesInfo name="RFC" value="2068"/> |
---|
| 3909 | </reference> |
---|
| 3910 | |
---|
[310] | 3911 | <reference anchor='RFC2109'> |
---|
| 3912 | <front> |
---|
| 3913 | <title>HTTP State Management Mechanism</title> |
---|
| 3914 | <author initials='D.M.' surname='Kristol' fullname='David M. Kristol'> |
---|
| 3915 | <organization>Bell Laboratories, Lucent Technologies</organization> |
---|
| 3916 | <address><email>dmk@bell-labs.com</email></address> |
---|
| 3917 | </author> |
---|
| 3918 | <author initials='L.' surname='Montulli' fullname='Lou Montulli'> |
---|
| 3919 | <organization>Netscape Communications Corp.</organization> |
---|
| 3920 | <address><email>montulli@netscape.com</email></address> |
---|
| 3921 | </author> |
---|
| 3922 | <date year='1997' month='February' /> |
---|
| 3923 | </front> |
---|
| 3924 | <seriesInfo name='RFC' value='2109' /> |
---|
| 3925 | </reference> |
---|
| 3926 | |
---|
[129] | 3927 | <reference anchor="RFC2145"> |
---|
| 3928 | <front> |
---|
| 3929 | <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title> |
---|
| 3930 | <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3931 | <organization>Western Research Laboratory</organization> |
---|
| 3932 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 3933 | </author> |
---|
| 3934 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3935 | <organization>Department of Information and Computer Science</organization> |
---|
| 3936 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3937 | </author> |
---|
| 3938 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3939 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3940 | <address><email>jg@w3.org</email></address> |
---|
| 3941 | </author> |
---|
| 3942 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
| 3943 | <organization>W3 Consortium</organization> |
---|
| 3944 | <address><email>frystyk@w3.org</email></address> |
---|
| 3945 | </author> |
---|
| 3946 | <date month="May" year="1997"/> |
---|
| 3947 | </front> |
---|
| 3948 | <seriesInfo name="RFC" value="2145"/> |
---|
| 3949 | </reference> |
---|
| 3950 | |
---|
| 3951 | <reference anchor="RFC2324"> |
---|
| 3952 | <front> |
---|
| 3953 | <title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title> |
---|
| 3954 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 3955 | <organization>Xerox Palo Alto Research Center</organization> |
---|
| 3956 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3957 | </author> |
---|
| 3958 | <date month="April" day="1" year="1998"/> |
---|
| 3959 | </front> |
---|
| 3960 | <seriesInfo name="RFC" value="2324"/> |
---|
| 3961 | </reference> |
---|
| 3962 | |
---|
[36] | 3963 | <reference anchor="RFC2616"> |
---|
[119] | 3964 | <front> |
---|
| 3965 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
| 3966 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
| 3967 | <organization>University of California, Irvine</organization> |
---|
| 3968 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3969 | </author> |
---|
| 3970 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
| 3971 | <organization>W3C</organization> |
---|
| 3972 | <address><email>jg@w3.org</email></address> |
---|
| 3973 | </author> |
---|
| 3974 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
| 3975 | <organization>Compaq Computer Corporation</organization> |
---|
| 3976 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 3977 | </author> |
---|
| 3978 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
| 3979 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3980 | <address><email>frystyk@w3.org</email></address> |
---|
| 3981 | </author> |
---|
| 3982 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
| 3983 | <organization>Xerox Corporation</organization> |
---|
| 3984 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3985 | </author> |
---|
| 3986 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
| 3987 | <organization>Microsoft Corporation</organization> |
---|
| 3988 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3989 | </author> |
---|
| 3990 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
| 3991 | <organization>W3C</organization> |
---|
| 3992 | <address><email>timbl@w3.org</email></address> |
---|
| 3993 | </author> |
---|
| 3994 | <date month="June" year="1999"/> |
---|
| 3995 | </front> |
---|
| 3996 | <seriesInfo name="RFC" value="2616"/> |
---|
[36] | 3997 | </reference> |
---|
| 3998 | |
---|
[313] | 3999 | <reference anchor='RFC2818'> |
---|
| 4000 | <front> |
---|
| 4001 | <title>HTTP Over TLS</title> |
---|
| 4002 | <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'> |
---|
| 4003 | <organization>RTFM, Inc.</organization> |
---|
| 4004 | <address><email>ekr@rtfm.com</email></address> |
---|
| 4005 | </author> |
---|
| 4006 | <date year='2000' month='May' /> |
---|
| 4007 | </front> |
---|
| 4008 | <seriesInfo name='RFC' value='2818' /> |
---|
| 4009 | </reference> |
---|
| 4010 | |
---|
[129] | 4011 | <reference anchor="RFC2821"> |
---|
| 4012 | <front> |
---|
| 4013 | <title>Simple Mail Transfer Protocol</title> |
---|
| 4014 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
| 4015 | <organization>AT&T Laboratories</organization> |
---|
| 4016 | <address><email>klensin@research.att.com</email></address> |
---|
| 4017 | </author> |
---|
| 4018 | <date year="2001" month="April"/> |
---|
| 4019 | </front> |
---|
| 4020 | <seriesInfo name="RFC" value="2821"/> |
---|
| 4021 | </reference> |
---|
| 4022 | |
---|
[133] | 4023 | <reference anchor="RFC2822"> |
---|
| 4024 | <front> |
---|
| 4025 | <title>Internet Message Format</title> |
---|
| 4026 | <author initials="P." surname="Resnick" fullname="P. Resnick"> |
---|
| 4027 | <organization>QUALCOMM Incorporated</organization> |
---|
| 4028 | </author> |
---|
| 4029 | <date year="2001" month="April"/> |
---|
| 4030 | </front> |
---|
| 4031 | <seriesInfo name="RFC" value="2822"/> |
---|
| 4032 | </reference> |
---|
| 4033 | |
---|
[310] | 4034 | <reference anchor='RFC2965'> |
---|
| 4035 | <front> |
---|
| 4036 | <title>HTTP State Management Mechanism</title> |
---|
| 4037 | <author initials='D. M.' surname='Kristol' fullname='David M. Kristol'> |
---|
| 4038 | <organization>Bell Laboratories, Lucent Technologies</organization> |
---|
| 4039 | <address><email>dmk@bell-labs.com</email></address> |
---|
| 4040 | </author> |
---|
| 4041 | <author initials='L.' surname='Montulli' fullname='Lou Montulli'> |
---|
| 4042 | <organization>Epinions.com, Inc.</organization> |
---|
| 4043 | <address><email>lou@montulli.org</email></address> |
---|
| 4044 | </author> |
---|
| 4045 | <date year='2000' month='October' /> |
---|
| 4046 | </front> |
---|
| 4047 | <seriesInfo name='RFC' value='2965' /> |
---|
| 4048 | </reference> |
---|
| 4049 | |
---|
[253] | 4050 | <reference anchor='RFC3864'> |
---|
| 4051 | <front> |
---|
| 4052 | <title>Registration Procedures for Message Header Fields</title> |
---|
| 4053 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
| 4054 | <organization>Nine by Nine</organization> |
---|
| 4055 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
| 4056 | </author> |
---|
| 4057 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
| 4058 | <organization>BEA Systems</organization> |
---|
| 4059 | <address><email>mnot@pobox.com</email></address> |
---|
| 4060 | </author> |
---|
| 4061 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
| 4062 | <organization>HP Labs</organization> |
---|
| 4063 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 4064 | </author> |
---|
| 4065 | <date year='2004' month='September' /> |
---|
| 4066 | </front> |
---|
| 4067 | <seriesInfo name='BCP' value='90' /> |
---|
| 4068 | <seriesInfo name='RFC' value='3864' /> |
---|
| 4069 | </reference> |
---|
| 4070 | |
---|
[125] | 4071 | <reference anchor='RFC3977'> |
---|
| 4072 | <front> |
---|
| 4073 | <title>Network News Transfer Protocol (NNTP)</title> |
---|
| 4074 | <author initials='C.' surname='Feather' fullname='C. Feather'> |
---|
| 4075 | <organization>THUS plc</organization> |
---|
| 4076 | <address><email>clive@demon.net</email></address> |
---|
| 4077 | </author> |
---|
| 4078 | <date year='2006' month='October' /> |
---|
| 4079 | </front> |
---|
| 4080 | <seriesInfo name="RFC" value="3977"/> |
---|
| 4081 | </reference> |
---|
| 4082 | |
---|
[197] | 4083 | <reference anchor="RFC4288"> |
---|
| 4084 | <front> |
---|
| 4085 | <title>Media Type Specifications and Registration Procedures</title> |
---|
| 4086 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
| 4087 | <organization>Sun Microsystems</organization> |
---|
| 4088 | <address> |
---|
| 4089 | <email>ned.freed@mrochek.com</email> |
---|
| 4090 | </address> |
---|
| 4091 | </author> |
---|
| 4092 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
| 4093 | <organization/> |
---|
| 4094 | <address> |
---|
| 4095 | <email>klensin+ietf@jck.com</email> |
---|
| 4096 | </address> |
---|
| 4097 | </author> |
---|
| 4098 | <date year="2005" month="December"/> |
---|
| 4099 | </front> |
---|
| 4100 | <seriesInfo name="BCP" value="13"/> |
---|
| 4101 | <seriesInfo name="RFC" value="4288"/> |
---|
| 4102 | </reference> |
---|
| 4103 | |
---|
[307] | 4104 | <reference anchor='RFC4395'> |
---|
| 4105 | <front> |
---|
| 4106 | <title>Guidelines and Registration Procedures for New URI Schemes</title> |
---|
| 4107 | <author initials='T.' surname='Hansen' fullname='T. Hansen'> |
---|
| 4108 | <organization>AT&T Laboratories</organization> |
---|
| 4109 | <address> |
---|
| 4110 | <email>tony+urireg@maillennium.att.com</email> |
---|
| 4111 | </address> |
---|
| 4112 | </author> |
---|
| 4113 | <author initials='T.' surname='Hardie' fullname='T. Hardie'> |
---|
| 4114 | <organization>Qualcomm, Inc.</organization> |
---|
| 4115 | <address> |
---|
| 4116 | <email>hardie@qualcomm.com</email> |
---|
| 4117 | </address> |
---|
| 4118 | </author> |
---|
| 4119 | <author initials='L.' surname='Masinter' fullname='L. Masinter'> |
---|
| 4120 | <organization>Adobe Systems</organization> |
---|
| 4121 | <address> |
---|
| 4122 | <email>LMM@acm.org</email> |
---|
| 4123 | </address> |
---|
| 4124 | </author> |
---|
| 4125 | <date year='2006' month='February' /> |
---|
| 4126 | </front> |
---|
| 4127 | <seriesInfo name='BCP' value='115' /> |
---|
| 4128 | <seriesInfo name='RFC' value='4395' /> |
---|
| 4129 | </reference> |
---|
| 4130 | |
---|
[310] | 4131 | <reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/0105018"> |
---|
| 4132 | <front> |
---|
| 4133 | <title>HTTP Cookies: Standards, Privacy, and Politics</title> |
---|
| 4134 | <author initials="D." surname="Kristol" fullname="David M. Kristol"> |
---|
| 4135 | <organization/> |
---|
| 4136 | </author> |
---|
| 4137 | <date year="2001" month="November"/> |
---|
| 4138 | </front> |
---|
| 4139 | <seriesInfo name="ACM Transactions on Internet Technology" value="Vol. 1, #2"/> |
---|
| 4140 | </reference> |
---|
| 4141 | |
---|
[129] | 4142 | <reference anchor="Spe" target="http://sunsite.unc.edu/mdma-release/http-prob.html"> |
---|
| 4143 | <front> |
---|
| 4144 | <title>Analysis of HTTP Performance Problems</title> |
---|
| 4145 | <author initials="S." surname="Spero" fullname="Simon E. Spero"> |
---|
| 4146 | <organization/> |
---|
| 4147 | </author> |
---|
| 4148 | <date/> |
---|
| 4149 | </front> |
---|
[8] | 4150 | </reference> |
---|
| 4151 | |
---|
[129] | 4152 | <reference anchor="Tou1998" target="http://www.isi.edu/touch/pubs/http-perf96/"> |
---|
| 4153 | <front> |
---|
| 4154 | <title>Analysis of HTTP Performance</title> |
---|
| 4155 | <author initials="J." surname="Touch" fullname="Joe Touch"> |
---|
| 4156 | <organization>USC/Information Sciences Institute</organization> |
---|
| 4157 | <address><email>touch@isi.edu</email></address> |
---|
| 4158 | </author> |
---|
| 4159 | <author initials="J." surname="Heidemann" fullname="John Heidemann"> |
---|
| 4160 | <organization>USC/Information Sciences Institute</organization> |
---|
| 4161 | <address><email>johnh@isi.edu</email></address> |
---|
| 4162 | </author> |
---|
| 4163 | <author initials="K." surname="Obraczka" fullname="Katia Obraczka"> |
---|
| 4164 | <organization>USC/Information Sciences Institute</organization> |
---|
| 4165 | <address><email>katia@isi.edu</email></address> |
---|
| 4166 | </author> |
---|
| 4167 | <date year="1998" month="Aug"/> |
---|
| 4168 | </front> |
---|
| 4169 | <seriesInfo name="ISI Research Report" value="ISI/RR-98-463"/> |
---|
| 4170 | <annotation>(original report dated Aug. 1996)</annotation> |
---|
[8] | 4171 | </reference> |
---|
| 4172 | |
---|
[129] | 4173 | <reference anchor="WAIS"> |
---|
[97] | 4174 | <front> |
---|
[129] | 4175 | <title>WAIS Interface Protocol Prototype Functional Specification (v1.5)</title> |
---|
| 4176 | <author initials="F." surname="Davis" fullname="F. Davis"> |
---|
| 4177 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4178 | </author> |
---|
[129] | 4179 | <author initials="B." surname="Kahle" fullname="B. Kahle"> |
---|
| 4180 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4181 | </author> |
---|
[129] | 4182 | <author initials="H." surname="Morris" fullname="H. Morris"> |
---|
| 4183 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4184 | </author> |
---|
[129] | 4185 | <author initials="J." surname="Salem" fullname="J. Salem"> |
---|
| 4186 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4187 | </author> |
---|
[129] | 4188 | <author initials="T." surname="Shen" fullname="T. Shen"> |
---|
| 4189 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4190 | </author> |
---|
[129] | 4191 | <author initials="R." surname="Wang" fullname="R. Wang"> |
---|
| 4192 | <organization>Thinking Machines Corporation</organization> |
---|
[97] | 4193 | </author> |
---|
[129] | 4194 | <author initials="J." surname="Sui" fullname="J. Sui"> |
---|
| 4195 | <organization>Thinking Machines Corporation</organization> |
---|
| 4196 | </author> |
---|
| 4197 | <author initials="M." surname="Grinbaum" fullname="M. Grinbaum"> |
---|
| 4198 | <organization>Thinking Machines Corporation</organization> |
---|
| 4199 | </author> |
---|
| 4200 | <date month="April" year="1990"/> |
---|
[97] | 4201 | </front> |
---|
[129] | 4202 | <seriesInfo name="Thinking Machines Corporation" value=""/> |
---|
[8] | 4203 | </reference> |
---|
| 4204 | |
---|
[129] | 4205 | </references> |
---|
| 4206 | |
---|
| 4207 | |
---|
[8] | 4208 | <section title="Tolerant Applications" anchor="tolerant.applications"> |
---|
| 4209 | <t> |
---|
| 4210 | Although this document specifies the requirements for the generation |
---|
| 4211 | of HTTP/1.1 messages, not all applications will be correct in their |
---|
| 4212 | implementation. We therefore recommend that operational applications |
---|
| 4213 | be tolerant of deviations whenever those deviations can be |
---|
| 4214 | interpreted unambiguously. |
---|
| 4215 | </t> |
---|
| 4216 | <t> |
---|
| 4217 | Clients &SHOULD; be tolerant in parsing the Status-Line and servers |
---|
| 4218 | tolerant when parsing the Request-Line. In particular, they &SHOULD; |
---|
[154] | 4219 | accept any amount of SP or HTAB characters between fields, even though |
---|
[8] | 4220 | only a single SP is required. |
---|
| 4221 | </t> |
---|
| 4222 | <t> |
---|
| 4223 | The line terminator for message-header fields is the sequence CRLF. |
---|
| 4224 | However, we recommend that applications, when parsing such headers, |
---|
| 4225 | recognize a single LF as a line terminator and ignore the leading CR. |
---|
| 4226 | </t> |
---|
| 4227 | <t> |
---|
| 4228 | The character set of an entity-body &SHOULD; be labeled as the lowest |
---|
| 4229 | common denominator of the character codes used within that body, with |
---|
| 4230 | the exception that not labeling the entity is preferred over labeling |
---|
[29] | 4231 | the entity with the labels US-ASCII or ISO-8859-1. See &payload;. |
---|
[8] | 4232 | </t> |
---|
| 4233 | <t> |
---|
| 4234 | Additional rules for requirements on parsing and encoding of dates |
---|
| 4235 | and other potential problems with date encodings include: |
---|
| 4236 | </t> |
---|
| 4237 | <t> |
---|
| 4238 | <list style="symbols"> |
---|
| 4239 | <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date |
---|
| 4240 | which appears to be more than 50 years in the future is in fact |
---|
| 4241 | in the past (this helps solve the "year 2000" problem).</t> |
---|
| 4242 | |
---|
| 4243 | <t>An HTTP/1.1 implementation &MAY; internally represent a parsed |
---|
| 4244 | Expires date as earlier than the proper value, but &MUST-NOT; |
---|
| 4245 | internally represent a parsed Expires date as later than the |
---|
| 4246 | proper value.</t> |
---|
| 4247 | |
---|
| 4248 | <t>All expiration-related calculations &MUST; be done in GMT. The |
---|
| 4249 | local time zone &MUST-NOT; influence the calculation or comparison |
---|
| 4250 | of an age or expiration time.</t> |
---|
| 4251 | |
---|
| 4252 | <t>If an HTTP header incorrectly carries a date value with a time |
---|
| 4253 | zone other than GMT, it &MUST; be converted into GMT using the |
---|
| 4254 | most conservative possible conversion.</t> |
---|
| 4255 | </list> |
---|
| 4256 | </t> |
---|
| 4257 | </section> |
---|
| 4258 | |
---|
| 4259 | <section title="Conversion of Date Formats" anchor="conversion.of.date.formats"> |
---|
| 4260 | <t> |
---|
| 4261 | HTTP/1.1 uses a restricted set of date formats (<xref target="full.date"/>) to |
---|
| 4262 | simplify the process of date comparison. Proxies and gateways from |
---|
| 4263 | other protocols &SHOULD; ensure that any Date header field present in a |
---|
| 4264 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
---|
| 4265 | if necessary. |
---|
| 4266 | </t> |
---|
| 4267 | </section> |
---|
| 4268 | |
---|
| 4269 | <section title="Compatibility with Previous Versions" anchor="compatibility"> |
---|
| 4270 | <t> |
---|
| 4271 | It is beyond the scope of a protocol specification to mandate |
---|
| 4272 | compliance with previous versions. HTTP/1.1 was deliberately |
---|
| 4273 | designed, however, to make supporting previous versions easy. It is |
---|
| 4274 | worth noting that, at the time of composing this specification |
---|
| 4275 | (1996), we would expect commercial HTTP/1.1 servers to: |
---|
| 4276 | <list style="symbols"> |
---|
| 4277 | <t>recognize the format of the Request-Line for HTTP/0.9, 1.0, and |
---|
| 4278 | 1.1 requests;</t> |
---|
| 4279 | |
---|
| 4280 | <t>understand any valid request in the format of HTTP/0.9, 1.0, or |
---|
| 4281 | 1.1;</t> |
---|
| 4282 | |
---|
| 4283 | <t>respond appropriately with a message in the same major version |
---|
| 4284 | used by the client.</t> |
---|
| 4285 | </list> |
---|
| 4286 | </t> |
---|
| 4287 | <t> |
---|
| 4288 | And we would expect HTTP/1.1 clients to: |
---|
| 4289 | <list style="symbols"> |
---|
| 4290 | <t>recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
---|
| 4291 | responses;</t> |
---|
| 4292 | |
---|
| 4293 | <t>understand any valid response in the format of HTTP/0.9, 1.0, or |
---|
| 4294 | 1.1.</t> |
---|
| 4295 | </list> |
---|
| 4296 | </t> |
---|
| 4297 | <t> |
---|
| 4298 | For most implementations of HTTP/1.0, each connection is established |
---|
| 4299 | by the client prior to the request and closed by the server after |
---|
| 4300 | sending the response. Some implementations implement the Keep-Alive |
---|
[97] | 4301 | version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. |
---|
[8] | 4302 | </t> |
---|
| 4303 | |
---|
| 4304 | <section title="Changes from HTTP/1.0" anchor="changes.from.1.0"> |
---|
| 4305 | <t> |
---|
| 4306 | This section summarizes major differences between versions HTTP/1.0 |
---|
| 4307 | and HTTP/1.1. |
---|
| 4308 | </t> |
---|
| 4309 | |
---|
| 4310 | <section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> |
---|
| 4311 | <t> |
---|
| 4312 | The requirements that clients and servers support the Host request-header, |
---|
| 4313 | report an error if the Host request-header (<xref target="header.host"/>) is |
---|
| 4314 | missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-uri"/>) |
---|
| 4315 | are among the most important changes defined by this |
---|
| 4316 | specification. |
---|
| 4317 | </t> |
---|
| 4318 | <t> |
---|
| 4319 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
---|
| 4320 | addresses and servers; there was no other established mechanism for |
---|
| 4321 | distinguishing the intended server of a request than the IP address |
---|
| 4322 | to which that request was directed. The changes outlined above will |
---|
| 4323 | allow the Internet, once older HTTP clients are no longer common, to |
---|
| 4324 | support multiple Web sites from a single IP address, greatly |
---|
| 4325 | simplifying large operational Web servers, where allocation of many |
---|
| 4326 | IP addresses to a single host has created serious problems. The |
---|
| 4327 | Internet will also be able to recover the IP addresses that have been |
---|
| 4328 | allocated for the sole purpose of allowing special-purpose domain |
---|
| 4329 | names to be used in root-level HTTP URLs. Given the rate of growth of |
---|
| 4330 | the Web, and the number of servers already deployed, it is extremely |
---|
| 4331 | important that all implementations of HTTP (including updates to |
---|
| 4332 | existing HTTP/1.0 applications) correctly implement these |
---|
| 4333 | requirements: |
---|
| 4334 | <list style="symbols"> |
---|
| 4335 | <t>Both clients and servers &MUST; support the Host request-header.</t> |
---|
| 4336 | |
---|
| 4337 | <t>A client that sends an HTTP/1.1 request &MUST; send a Host header.</t> |
---|
| 4338 | |
---|
| 4339 | <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1 |
---|
| 4340 | request does not include a Host request-header.</t> |
---|
| 4341 | |
---|
| 4342 | <t>Servers &MUST; accept absolute URIs.</t> |
---|
| 4343 | </list> |
---|
| 4344 | </t> |
---|
| 4345 | </section> |
---|
| 4346 | </section> |
---|
| 4347 | |
---|
| 4348 | <section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections"> |
---|
| 4349 | <t> |
---|
| 4350 | Some clients and servers might wish to be compatible with some |
---|
| 4351 | previous implementations of persistent connections in HTTP/1.0 |
---|
| 4352 | clients and servers. Persistent connections in HTTP/1.0 are |
---|
| 4353 | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
---|
| 4354 | experimental implementations of persistent connections are faulty, |
---|
| 4355 | and the new facilities in HTTP/1.1 are designed to rectify these |
---|
| 4356 | problems. The problem was that some existing 1.0 clients may be |
---|
| 4357 | sending Keep-Alive to a proxy server that doesn't understand |
---|
| 4358 | Connection, which would then erroneously forward it to the next |
---|
| 4359 | inbound server, which would establish the Keep-Alive connection and |
---|
| 4360 | result in a hung HTTP/1.0 proxy waiting for the close on the |
---|
| 4361 | response. The result is that HTTP/1.0 clients must be prevented from |
---|
| 4362 | using Keep-Alive when talking to proxies. |
---|
| 4363 | </t> |
---|
| 4364 | <t> |
---|
| 4365 | However, talking to proxies is the most important use of persistent |
---|
| 4366 | connections, so that prohibition is clearly unacceptable. Therefore, |
---|
| 4367 | we need some other mechanism for indicating a persistent connection |
---|
| 4368 | is desired, which is safe to use even when talking to an old proxy |
---|
| 4369 | that ignores Connection. Persistent connections are the default for |
---|
| 4370 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
---|
| 4371 | declaring non-persistence. See <xref target="header.connection"/>. |
---|
| 4372 | </t> |
---|
| 4373 | <t> |
---|
| 4374 | The original HTTP/1.0 form of persistent connections (the Connection: |
---|
[97] | 4375 | Keep-Alive and Keep-Alive header) is documented in <xref target="RFC2068"/>. |
---|
[8] | 4376 | </t> |
---|
| 4377 | </section> |
---|
| 4378 | |
---|
| 4379 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
| 4380 | <t> |
---|
| 4381 | This specification has been carefully audited to correct and |
---|
| 4382 | disambiguate key word usage; RFC 2068 had many problems in respect to |
---|
[97] | 4383 | the conventions laid out in <xref target="RFC2119"/>. |
---|
[8] | 4384 | </t> |
---|
| 4385 | <t> |
---|
| 4386 | Transfer-coding and message lengths all interact in ways that |
---|
| 4387 | required fixing exactly when chunked encoding is used (to allow for |
---|
| 4388 | transfer encoding that may not be self delimiting); it was important |
---|
[138] | 4389 | to straighten out exactly how message lengths are computed. (Sections |
---|
| 4390 | <xref target="transfer.codings" format="counter"/>, <xref target="message.length" format="counter"/>, |
---|
| 4391 | <xref target="header.content-length" format="counter"/>, |
---|
| 4392 | see also <xref target="Part3"/>, <xref target="Part5"/> and <xref target="Part6"/>) |
---|
[8] | 4393 | </t> |
---|
| 4394 | <t> |
---|
| 4395 | The use and interpretation of HTTP version numbers has been clarified |
---|
[97] | 4396 | by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol |
---|
[8] | 4397 | version they support to deal with problems discovered in HTTP/1.0 |
---|
| 4398 | implementations (<xref target="http.version"/>) |
---|
| 4399 | </t> |
---|
| 4400 | <t> |
---|
| 4401 | Transfer-coding had significant problems, particularly with |
---|
| 4402 | interactions with chunked encoding. The solution is that transfer-codings |
---|
| 4403 | become as full fledged as content-codings. This involves |
---|
| 4404 | adding an IANA registry for transfer-codings (separate from content |
---|
| 4405 | codings), a new header field (TE) and enabling trailer headers in the |
---|
| 4406 | future. Transfer encoding is a major performance benefit, so it was |
---|
| 4407 | worth fixing <xref target="Nie1997"/>. TE also solves another, obscure, downward |
---|
| 4408 | interoperability problem that could have occurred due to interactions |
---|
| 4409 | between authentication trailers, chunked encoding and HTTP/1.0 |
---|
| 4410 | clients.(Section <xref target="transfer.codings" format="counter"/>, <xref target="chunked.transfer.encoding" format="counter"/>, |
---|
| 4411 | and <xref target="header.te" format="counter"/>) |
---|
| 4412 | </t> |
---|
| 4413 | </section> |
---|
[99] | 4414 | |
---|
| 4415 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
[103] | 4416 | <t> |
---|
[188] | 4417 | The CHAR rule does not allow the NUL character anymore (this affects |
---|
[238] | 4418 | the comment and quoted-string rules). Furthermore, the quoted-pair |
---|
| 4419 | rule does not allow escaping NUL, CR or LF anymore. |
---|
[188] | 4420 | (<xref target="basic.rules"/>) |
---|
| 4421 | </t> |
---|
| 4422 | <t> |
---|
[111] | 4423 | Clarify that HTTP-Version is case sensitive. |
---|
| 4424 | (<xref target="http.version"/>) |
---|
| 4425 | </t> |
---|
| 4426 | <t> |
---|
[104] | 4427 | Remove reference to non-existant identity transfer-coding value tokens. |
---|
| 4428 | (Sections <xref format="counter" target="transfer.codings"/> and |
---|
| 4429 | <xref format="counter" target="message.length"/>) |
---|
| 4430 | </t> |
---|
| 4431 | <t> |
---|
[103] | 4432 | Clarification that the chunk length does not include |
---|
| 4433 | the count of the octets in the chunk header and trailer. |
---|
| 4434 | (<xref target="chunked.transfer.encoding"/>) |
---|
| 4435 | </t> |
---|
[107] | 4436 | <t> |
---|
[110] | 4437 | Fix BNF to add query, as the abs_path production in |
---|
| 4438 | <xref x:sec="3" x:fmt="of" target="RFC2396"/> doesn't define it. |
---|
| 4439 | (<xref target="request-uri"/>) |
---|
| 4440 | </t> |
---|
| 4441 | <t> |
---|
[107] | 4442 | Clarify exactly when close connection options must be sent. |
---|
| 4443 | (<xref target="header.connection"/>) |
---|
| 4444 | </t> |
---|
[8] | 4445 | </section> |
---|
[115] | 4446 | </section> |
---|
[99] | 4447 | |
---|
[252] | 4448 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
[115] | 4449 | |
---|
| 4450 | <section title="Since RFC2616"> |
---|
| 4451 | <t> |
---|
| 4452 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
| 4453 | </t> |
---|
[99] | 4454 | </section> |
---|
[115] | 4455 | |
---|
| 4456 | <section title="Since draft-ietf-httpbis-p1-messaging-00"> |
---|
| 4457 | <t> |
---|
[116] | 4458 | Closed issues: |
---|
| 4459 | <list style="symbols"> |
---|
| 4460 | <t> |
---|
| 4461 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1"/>: |
---|
| 4462 | "HTTP Version should be case sensitive" |
---|
| 4463 | (<eref target="http://purl.org/NET/http-errata#verscase"/>) |
---|
| 4464 | </t> |
---|
| 4465 | <t> |
---|
| 4466 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2"/>: |
---|
| 4467 | "'unsafe' characters" |
---|
| 4468 | (<eref target="http://purl.org/NET/http-errata#unsafe-uri"/>) |
---|
| 4469 | </t> |
---|
| 4470 | <t> |
---|
| 4471 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3"/>: |
---|
| 4472 | "Chunk Size Definition" |
---|
| 4473 | (<eref target="http://purl.org/NET/http-errata#chunk-size"/>) |
---|
| 4474 | </t> |
---|
| 4475 | <t> |
---|
| 4476 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4"/>: |
---|
| 4477 | "Message Length" |
---|
| 4478 | (<eref target="http://purl.org/NET/http-errata#msg-len-chars"/>) |
---|
| 4479 | </t> |
---|
| 4480 | <t> |
---|
| 4481 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8"/>: |
---|
| 4482 | "Media Type Registrations" |
---|
| 4483 | (<eref target="http://purl.org/NET/http-errata#media-reg"/>) |
---|
| 4484 | </t> |
---|
| 4485 | <t> |
---|
| 4486 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11"/>: |
---|
| 4487 | "URI includes query" |
---|
| 4488 | (<eref target="http://purl.org/NET/http-errata#uriquery"/>) |
---|
| 4489 | </t> |
---|
| 4490 | <t> |
---|
| 4491 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15"/>: |
---|
| 4492 | "No close on 1xx responses" |
---|
| 4493 | (<eref target="http://purl.org/NET/http-errata#noclose1xx"/>) |
---|
| 4494 | </t> |
---|
| 4495 | <t> |
---|
| 4496 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16"/>: |
---|
| 4497 | "Remove 'identity' token references" |
---|
| 4498 | (<eref target="http://purl.org/NET/http-errata#identity"/>) |
---|
| 4499 | </t> |
---|
| 4500 | <t> |
---|
[127] | 4501 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26"/>: |
---|
| 4502 | "Import query BNF" |
---|
| 4503 | </t> |
---|
| 4504 | <t> |
---|
[128] | 4505 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31"/>: |
---|
| 4506 | "qdtext BNF" |
---|
| 4507 | </t> |
---|
| 4508 | <t> |
---|
[152] | 4509 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
| 4510 | "Normative and Informative references" |
---|
| 4511 | </t> |
---|
| 4512 | <t> |
---|
[116] | 4513 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42"/>: |
---|
| 4514 | "RFC2606 Compliance" |
---|
| 4515 | </t> |
---|
| 4516 | <t> |
---|
| 4517 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45"/>: |
---|
| 4518 | "RFC977 reference" |
---|
| 4519 | </t> |
---|
| 4520 | <t> |
---|
| 4521 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46"/>: |
---|
| 4522 | "RFC1700 references" |
---|
| 4523 | </t> |
---|
| 4524 | <t> |
---|
| 4525 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47"/>: |
---|
| 4526 | "inconsistency in date format explanation" |
---|
| 4527 | </t> |
---|
| 4528 | <t> |
---|
| 4529 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48"/>: |
---|
| 4530 | "Date reference typo" |
---|
| 4531 | </t> |
---|
[123] | 4532 | <t> |
---|
[129] | 4533 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65"/>: |
---|
| 4534 | "Informative references" |
---|
| 4535 | </t> |
---|
| 4536 | <t> |
---|
[123] | 4537 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66"/>: |
---|
| 4538 | "ISO-8859-1 Reference" |
---|
| 4539 | </t> |
---|
[131] | 4540 | <t> |
---|
| 4541 | <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86"/>: |
---|
| 4542 | "Normative up-to-date references" |
---|
| 4543 | </t> |
---|
[116] | 4544 | </list> |
---|
[115] | 4545 | </t> |
---|
[119] | 4546 | <t> |
---|
| 4547 | Other changes: |
---|
[152] | 4548 | <list style="symbols"> |
---|
[119] | 4549 | <t> |
---|
[152] | 4550 | Update media type registrations to use RFC4288 template. |
---|
[119] | 4551 | </t> |
---|
[154] | 4552 | <t> |
---|
[155] | 4553 | Use names of RFC4234 core rules DQUOTE and HTAB, |
---|
| 4554 | fix broken ABNF for chunk-data |
---|
| |
---|