[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>"> |
---|
[29] | 14 | <!ENTITY ID-VERSION "latest"> |
---|
[704] | 15 | <!ENTITY ID-MONTH "October"> |
---|
[439] | 16 | <!ENTITY ID-YEAR "2009"> |
---|
[424] | 17 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 18 | <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 19 | <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 20 | <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 21 | <!ENTITY range "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 22 | <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 23 | <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[695] | 24 | <!ENTITY caching-combining-headers "<xref target='Part6' x:rel='#combining.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 25 | <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[205] | 26 | <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 27 | <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 28 | <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[580] | 29 | <!ENTITY full-date "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 30 | <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 31 | <!ENTITY http-version "<xref target='Part1' x:rel='#http.version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 32 | <!ENTITY use100 "<xref target='Part1' x:rel='#use.of.the.100.status' 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 header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 35 | <!ENTITY header-accept-charset "<xref target='Part3' x:rel='#header.accept-charset' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 36 | <!ENTITY header-accept-encoding "<xref target='Part3' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 37 | <!ENTITY header-accept-language "<xref target='Part3' x:rel='#header.accept-language' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 38 | <!ENTITY header-accept-ranges "<xref target='Part5' x:rel='#header.accept-ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 39 | <!ENTITY header-age "<xref target='Part6' x:rel='#header.age' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 40 | <!ENTITY header-authorization "<xref target='Part7' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 41 | <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 42 | <!ENTITY header-content-location "<xref target='Part3' x:rel='#header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 43 | <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 44 | <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 45 | <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[688] | 46 | <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[31] | 47 | <!ENTITY header-host "<xref target='Part1' x:rel='#header.host' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 48 | <!ENTITY header-if-match "<xref target='Part4' x:rel='#header.if-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 49 | <!ENTITY header-if-modified-since "<xref target='Part4' x:rel='#header.if-modified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 50 | <!ENTITY header-if-none-match "<xref target='Part4' x:rel='#header.if-none-match' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 51 | <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 52 | <!ENTITY header-if-unmodified-since "<xref target='Part4' x:rel='#header.if-unmodified-since' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 53 | <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 54 | <!ENTITY header-proxy-authenticate "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 55 | <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 56 | <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 57 | <!ENTITY header-upgrade "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 58 | <!ENTITY header-te "<xref target='Part1' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 59 | <!ENTITY header-vary "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 60 | <!ENTITY header-via "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 61 | <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 62 | <!ENTITY header-www-authenticate "<xref target='Part7' x:rel='#header.www-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 63 | <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[190] | 64 | <!ENTITY product-tokens "<xref target='Part1' x:rel='#product.tokens' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[263] | 65 | <!ENTITY media-type-message-http "<xref target='Part1' x:rel='#internet.media.type.message.http' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[700] | 66 | <!ENTITY status-206 "<xref target='Part5' x:rel='#status.206' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 67 | <!ENTITY status-304 "<xref target='Part4' x:rel='#status.304' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 68 | <!ENTITY status-401 "<xref target='Part7' x:rel='#status.401' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 69 | <!ENTITY status-407 "<xref target='Part7' x:rel='#status.407' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 70 | <!ENTITY status-412 "<xref target='Part4' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
| 71 | <!ENTITY status-416 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
[8] | 72 | ]> |
---|
| 73 | <?rfc toc="yes" ?> |
---|
[29] | 74 | <?rfc symrefs="yes" ?> |
---|
| 75 | <?rfc sortrefs="yes" ?> |
---|
[8] | 76 | <?rfc compact="yes"?> |
---|
| 77 | <?rfc subcompact="no" ?> |
---|
| 78 | <?rfc linkmailto="no" ?> |
---|
| 79 | <?rfc editing="no" ?> |
---|
[203] | 80 | <?rfc comments="yes"?> |
---|
| 81 | <?rfc inline="yes"?> |
---|
[8] | 82 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
| 83 | <?rfc-ext include-references-in-index="yes" ?> |
---|
[308] | 84 | <rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="draft" |
---|
[446] | 85 | ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" |
---|
[286] | 86 | xmlns:x='http://purl.org/net/xml2rfc/ext' |
---|
| 87 | xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'> |
---|
[8] | 88 | <front> |
---|
| 89 | |
---|
[120] | 90 | <title abbrev="HTTP/1.1, Part 2">HTTP/1.1, part 2: Message Semantics</title> |
---|
[8] | 91 | |
---|
[29] | 92 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 93 | <organization abbrev="Day Software">Day Software</organization> |
---|
[8] | 94 | <address> |
---|
| 95 | <postal> |
---|
[29] | 96 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
| 97 | <city>Newport Beach</city> |
---|
[8] | 98 | <region>CA</region> |
---|
[29] | 99 | <code>92660</code> |
---|
| 100 | <country>USA</country> |
---|
[8] | 101 | </postal> |
---|
[29] | 102 | <phone>+1-949-706-5300</phone> |
---|
| 103 | <facsimile>+1-949-706-5305</facsimile> |
---|
| 104 | <email>fielding@gbiv.com</email> |
---|
| 105 | <uri>http://roy.gbiv.com/</uri> |
---|
[8] | 106 | </address> |
---|
| 107 | </author> |
---|
| 108 | |
---|
[29] | 109 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 110 | <organization>One Laptop per Child</organization> |
---|
[8] | 111 | <address> |
---|
| 112 | <postal> |
---|
[29] | 113 | <street>21 Oak Knoll Road</street> |
---|
| 114 | <city>Carlisle</city> |
---|
[8] | 115 | <region>MA</region> |
---|
[29] | 116 | <code>01741</code> |
---|
| 117 | <country>USA</country> |
---|
[8] | 118 | </postal> |
---|
[29] | 119 | <email>jg@laptop.org</email> |
---|
| 120 | <uri>http://www.laptop.org/</uri> |
---|
[8] | 121 | </address> |
---|
| 122 | </author> |
---|
| 123 | |
---|
| 124 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
[29] | 125 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
[8] | 126 | <address> |
---|
| 127 | <postal> |
---|
[29] | 128 | <street>HP Labs, Large Scale Systems Group</street> |
---|
| 129 | <street>1501 Page Mill Road, MS 1177</street> |
---|
[8] | 130 | <city>Palo Alto</city> |
---|
| 131 | <region>CA</region> |
---|
[29] | 132 | <code>94304</code> |
---|
| 133 | <country>USA</country> |
---|
[8] | 134 | </postal> |
---|
[29] | 135 | <email>JeffMogul@acm.org</email> |
---|
[8] | 136 | </address> |
---|
| 137 | </author> |
---|
| 138 | |
---|
| 139 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
[29] | 140 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
[8] | 141 | <address> |
---|
| 142 | <postal> |
---|
[29] | 143 | <street>1 Microsoft Way</street> |
---|
| 144 | <city>Redmond</city> |
---|
| 145 | <region>WA</region> |
---|
| 146 | <code>98052</code> |
---|
| 147 | <country>USA</country> |
---|
[8] | 148 | </postal> |
---|
[29] | 149 | <email>henrikn@microsoft.com</email> |
---|
[8] | 150 | </address> |
---|
| 151 | </author> |
---|
| 152 | |
---|
| 153 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
[29] | 154 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
[8] | 155 | <address> |
---|
| 156 | <postal> |
---|
[29] | 157 | <street>345 Park Ave</street> |
---|
| 158 | <city>San Jose</city> |
---|
[8] | 159 | <region>CA</region> |
---|
[29] | 160 | <code>95110</code> |
---|
| 161 | <country>USA</country> |
---|
[8] | 162 | </postal> |
---|
[29] | 163 | <email>LMM@acm.org</email> |
---|
| 164 | <uri>http://larry.masinter.net/</uri> |
---|
[8] | 165 | </address> |
---|
| 166 | </author> |
---|
| 167 | |
---|
| 168 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 169 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 170 | <address> |
---|
| 171 | <postal> |
---|
| 172 | <street>1 Microsoft Way</street> |
---|
| 173 | <city>Redmond</city> |
---|
| 174 | <region>WA</region> |
---|
| 175 | <code>98052</code> |
---|
| 176 | </postal> |
---|
| 177 | <email>paulle@microsoft.com</email> |
---|
| 178 | </address> |
---|
| 179 | </author> |
---|
| 180 | |
---|
| 181 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 182 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 183 | <address> |
---|
| 184 | <postal> |
---|
[34] | 185 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
| 186 | <street>The Stata Center, Building 32</street> |
---|
| 187 | <street>32 Vassar Street</street> |
---|
[8] | 188 | <city>Cambridge</city> |
---|
| 189 | <region>MA</region> |
---|
| 190 | <code>02139</code> |
---|
[29] | 191 | <country>USA</country> |
---|
[8] | 192 | </postal> |
---|
| 193 | <email>timbl@w3.org</email> |
---|
[34] | 194 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
[8] | 195 | </address> |
---|
| 196 | </author> |
---|
| 197 | |
---|
[95] | 198 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
[94] | 199 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 200 | <address> |
---|
| 201 | <postal> |
---|
| 202 | <street>W3C / ERCIM</street> |
---|
| 203 | <street>2004, rte des Lucioles</street> |
---|
| 204 | <city>Sophia-Antipolis</city> |
---|
| 205 | <region>AM</region> |
---|
| 206 | <code>06902</code> |
---|
| 207 | <country>France</country> |
---|
| 208 | </postal> |
---|
| 209 | <email>ylafon@w3.org</email> |
---|
| 210 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
| 211 | </address> |
---|
| 212 | </author> |
---|
| 213 | |
---|
[95] | 214 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 215 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 216 | <address> |
---|
| 217 | <postal> |
---|
| 218 | <street>Hafenweg 16</street> |
---|
| 219 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
| 220 | <country>Germany</country> |
---|
| 221 | </postal> |
---|
[609] | 222 | <phone>+49 251 2807760</phone> |
---|
| 223 | <facsimile>+49 251 2807761</facsimile> |
---|
| 224 | <email>julian.reschke@greenbytes.de</email> |
---|
| 225 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
[95] | 226 | </address> |
---|
| 227 | </author> |
---|
| 228 | |
---|
[31] | 229 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
[440] | 230 | <workgroup>HTTPbis Working Group</workgroup> |
---|
[8] | 231 | |
---|
| 232 | <abstract> |
---|
| 233 | <t> |
---|
| 234 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
| 235 | protocol for distributed, collaborative, hypermedia information |
---|
[29] | 236 | systems. HTTP has been in use by the World Wide Web global information |
---|
[35] | 237 | initiative since 1990. This document is Part 2 of the seven-part specification |
---|
[29] | 238 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
[42] | 239 | obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages |
---|
[29] | 240 | as expressed by request methods, request-header fields, response status codes, |
---|
| 241 | and response-header fields. |
---|
[8] | 242 | </t> |
---|
| 243 | </abstract> |
---|
[36] | 244 | |
---|
| 245 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
| 246 | <t> |
---|
| 247 | Discussion of this draft should take place on the HTTPBIS working group |
---|
| 248 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
[324] | 249 | at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/11"/> |
---|
[36] | 250 | and related documents (including fancy diffs) can be found at |
---|
[324] | 251 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
[36] | 252 | </t> |
---|
[153] | 253 | <t> |
---|
[604] | 254 | The changes in this draft are summarized in <xref target="changes.since.07"/>. |
---|
[153] | 255 | </t> |
---|
[36] | 256 | </note> |
---|
[8] | 257 | </front> |
---|
| 258 | <middle> |
---|
| 259 | <section title="Introduction" anchor="introduction"> |
---|
| 260 | <t> |
---|
[162] | 261 | This document defines HTTP/1.1 request and response semantics. Each HTTP |
---|
| 262 | message, as defined in &messaging;, is in the form of either a request or |
---|
| 263 | a response. An HTTP server listens on a connection for HTTP requests and |
---|
| 264 | responds to each request, in the order received on that connection, with |
---|
| 265 | one or more HTTP response messages. This document defines the commonly |
---|
| 266 | agreed upon semantics of the HTTP uniform interface, the intentions defined |
---|
| 267 | by each request method, and the various response messages that might be |
---|
| 268 | expected as a result of applying that method for the requested resource. |
---|
[8] | 269 | </t> |
---|
| 270 | <t> |
---|
[162] | 271 | This document is currently disorganized in order to minimize the changes |
---|
| 272 | between drafts and enable reviewers to see the smaller errata changes. |
---|
| 273 | The next draft will reorganize the sections to better reflect the content. |
---|
| 274 | In particular, the sections will be ordered according to the typical |
---|
| 275 | processing of an HTTP request message (after message parsing): resource |
---|
| 276 | mapping, general header fields, methods, request modifiers, response |
---|
| 277 | status, and resource metadata. The current mess reflects how widely |
---|
| 278 | dispersed these topics and associated requirements had become in |
---|
| 279 | <xref target="RFC2616"/>. |
---|
[8] | 280 | </t> |
---|
[96] | 281 | |
---|
| 282 | <section title="Requirements" anchor="intro.requirements"> |
---|
| 283 | <t> |
---|
| 284 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
| 285 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
| 286 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
| 287 | </t> |
---|
| 288 | <t> |
---|
| 289 | An implementation is not compliant if it fails to satisfy one or more |
---|
| 290 | of the &MUST; or &REQUIRED; level requirements for the protocols it |
---|
| 291 | implements. An implementation that satisfies all the &MUST; or &REQUIRED; |
---|
| 292 | level and all the &SHOULD; level requirements for its protocols is said |
---|
| 293 | to be "unconditionally compliant"; one that satisfies all the &MUST; |
---|
| 294 | level requirements but not all the &SHOULD; level requirements for its |
---|
| 295 | protocols is said to be "conditionally compliant." |
---|
| 296 | </t> |
---|
[8] | 297 | </section> |
---|
| 298 | |
---|
[424] | 299 | <section title="Syntax Notation" anchor="notation"> |
---|
[425] | 300 | <x:anchor-alias value="CR"/> |
---|
| 301 | <x:anchor-alias value="DIGIT"/> |
---|
| 302 | <x:anchor-alias value="LF"/> |
---|
| 303 | <x:anchor-alias value="VCHAR"/> |
---|
| 304 | <x:anchor-alias value="WSP"/> |
---|
[424] | 305 | <t> |
---|
[543] | 306 | This specification uses the ABNF syntax defined in ¬ation; (which |
---|
| 307 | extends the syntax defined in <xref target="RFC5234"/> with a list rule). |
---|
| 308 | <xref target="collected.abnf"/> shows the collected ABNF, with the list |
---|
| 309 | rule expanded. |
---|
| 310 | </t> |
---|
| 311 | <t> |
---|
[425] | 312 | The following core rules are included by |
---|
| 313 | reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: |
---|
| 314 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
| 315 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
| 316 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
| 317 | OCTET (any 8-bit sequence of data), SP (space), |
---|
| 318 | VCHAR (any visible USASCII character), |
---|
| 319 | and WSP (whitespace). |
---|
[424] | 320 | </t> |
---|
| 321 | |
---|
| 322 | <section title="Core Rules" anchor="core.rules"> |
---|
[398] | 323 | <x:anchor-alias value="obs-text"/> |
---|
[229] | 324 | <x:anchor-alias value="quoted-string"/> |
---|
| 325 | <x:anchor-alias value="token"/> |
---|
[356] | 326 | <x:anchor-alias value="OWS"/> |
---|
| 327 | <x:anchor-alias value="RWS"/> |
---|
[205] | 328 | <t> |
---|
[424] | 329 | The core rules below are defined in &basic-rules;: |
---|
[205] | 330 | </t> |
---|
| 331 | <figure><artwork type="abnf2616"> |
---|
[229] | 332 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in &basic-rules;> |
---|
| 333 | <x:ref>token</x:ref> = <token, defined in &basic-rules;> |
---|
[356] | 334 | <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> |
---|
| 335 | <x:ref>RWS</x:ref> = <RWS, defined in &basic-rules;> |
---|
[398] | 336 | <x:ref>obs-text</x:ref> = <obs-text, defined in &basic-rules;> |
---|
[205] | 337 | </artwork></figure> |
---|
[424] | 338 | </section> |
---|
| 339 | |
---|
| 340 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
[374] | 341 | <x:anchor-alias value="absolute-URI"/> |
---|
[229] | 342 | <x:anchor-alias value="Accept"/> |
---|
| 343 | <x:anchor-alias value="Accept-Charset"/> |
---|
| 344 | <x:anchor-alias value="Accept-Encoding"/> |
---|
| 345 | <x:anchor-alias value="Accept-Language"/> |
---|
| 346 | <x:anchor-alias value="Accept-Ranges"/> |
---|
| 347 | <x:anchor-alias value="Age"/> |
---|
| 348 | <x:anchor-alias value="Authorization"/> |
---|
[688] | 349 | <x:anchor-alias value="comment"/> |
---|
[229] | 350 | <x:anchor-alias value="ETag"/> |
---|
| 351 | <x:anchor-alias value="Host"/> |
---|
| 352 | <x:anchor-alias value="HTTP-date"/> |
---|
| 353 | <x:anchor-alias value="If-Match"/> |
---|
| 354 | <x:anchor-alias value="If-Modified-Since"/> |
---|
| 355 | <x:anchor-alias value="If-None-Match"/> |
---|
| 356 | <x:anchor-alias value="If-Range"/> |
---|
| 357 | <x:anchor-alias value="If-Unmodified-Since"/> |
---|
[391] | 358 | <x:anchor-alias value="partial-URI"/> |
---|
[229] | 359 | <x:anchor-alias value="product"/> |
---|
| 360 | <x:anchor-alias value="Proxy-Authenticate"/> |
---|
| 361 | <x:anchor-alias value="Proxy-Authorization"/> |
---|
| 362 | <x:anchor-alias value="Range"/> |
---|
| 363 | <x:anchor-alias value="TE"/> |
---|
[632] | 364 | <x:anchor-alias value="URI"/> |
---|
[229] | 365 | <x:anchor-alias value="Vary"/> |
---|
| 366 | <x:anchor-alias value="WWW-Authenticate"/> |
---|
[424] | 367 | <t> |
---|
[206] | 368 | The ABNF rules below are defined in other parts: |
---|
| 369 | </t> |
---|
[207] | 370 | <figure><!--Part1--><artwork type="abnf2616"> |
---|
[374] | 371 | <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> |
---|
[688] | 372 | <x:ref>comment</x:ref> = <comment, defined in &header-fields;> |
---|
[374] | 373 | <x:ref>Host</x:ref> = <Host, defined in &uri;> |
---|
[229] | 374 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> |
---|
[391] | 375 | <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> |
---|
[229] | 376 | <x:ref>product</x:ref> = <product, defined in &product-tokens;> |
---|
| 377 | <x:ref>TE</x:ref> = <TE, defined in &header-te;> |
---|
[632] | 378 | <x:ref>URI</x:ref> = <URI, defined in &uri;> |
---|
[207] | 379 | </artwork></figure> |
---|
| 380 | <figure><!--Part3--><artwork type="abnf2616"> |
---|
[229] | 381 | <x:ref>Accept</x:ref> = <Accept, defined in &header-accept;> |
---|
| 382 | <x:ref>Accept-Charset</x:ref> = |
---|
[206] | 383 | <Accept-Charset, defined in &header-accept-charset;> |
---|
[229] | 384 | <x:ref>Accept-Encoding</x:ref> = |
---|
[206] | 385 | <Accept-Encoding, defined in &header-accept-encoding;> |
---|
[229] | 386 | <x:ref>Accept-Language</x:ref> = |
---|
[206] | 387 | <Accept-Language, defined in &header-accept-language;> |
---|
[207] | 388 | </artwork></figure> |
---|
| 389 | <figure><!--Part4--><artwork type="abnf2616"> |
---|
[229] | 390 | <x:ref>ETag</x:ref> = <ETag, defined in &header-etag;> |
---|
| 391 | <x:ref>If-Match</x:ref> = <If-Match, defined in &header-if-match;> |
---|
| 392 | <x:ref>If-Modified-Since</x:ref> = |
---|
[206] | 393 | <If-Modified-Since, defined in &header-if-modified-since;> |
---|
[229] | 394 | <x:ref>If-None-Match</x:ref> = <If-None-Match, defined in &header-if-none-match;> |
---|
| 395 | <x:ref>If-Unmodified-Since</x:ref> = |
---|
[206] | 396 | <If-Unmodified-Since, defined in &header-if-unmodified-since;> |
---|
[207] | 397 | </artwork></figure> |
---|
| 398 | <figure><!--Part5--><artwork type="abnf2616"> |
---|
[229] | 399 | <x:ref>Accept-Ranges</x:ref> = <Accept-Ranges, defined in &header-accept-ranges;> |
---|
| 400 | <x:ref>If-Range</x:ref> = <If-Range, defined in &header-if-range;> |
---|
| 401 | <x:ref>Range</x:ref> = <Range, defined in &header-range;> |
---|
[207] | 402 | </artwork></figure> |
---|
| 403 | <figure><!--Part6--><artwork type="abnf2616"> |
---|
[229] | 404 | <x:ref>Age</x:ref> = <Age, defined in &header-age;> |
---|
| 405 | <x:ref>Vary</x:ref> = <Vary, defined in &header-vary;> |
---|
[207] | 406 | </artwork><!--Part7--></figure> |
---|
| 407 | <figure><artwork type="abnf2616"> |
---|
[229] | 408 | <x:ref>Authorization</x:ref> = <Authorization, defined in &header-authorization;> |
---|
| 409 | <x:ref>Proxy-Authenticate</x:ref> = |
---|
[206] | 410 | <Proxy-Authenticate, defined in &header-proxy-authenticate;> |
---|
[229] | 411 | <x:ref>Proxy-Authorization</x:ref> = |
---|
[206] | 412 | <Proxy-Authorization, defined in &header-proxy-authorization;> |
---|
[229] | 413 | <x:ref>WWW-Authenticate</x:ref> = |
---|
[206] | 414 | <WWW-Authenticate, defined in &header-www-authenticate;> |
---|
| 415 | </artwork></figure> |
---|
[205] | 416 | </section> |
---|
[424] | 417 | </section> |
---|
| 418 | </section> |
---|
[205] | 419 | |
---|
[8] | 420 | <section title="Method" anchor="method"> |
---|
[229] | 421 | <x:anchor-alias value="Method"/> |
---|
| 422 | <x:anchor-alias value="extension-method"/> |
---|
[8] | 423 | <t> |
---|
| 424 | The Method token indicates the method to be performed on the |
---|
[391] | 425 | resource identified by the request-target. The method is case-sensitive. |
---|
[8] | 426 | </t> |
---|
| 427 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> |
---|
[272] | 428 | <x:ref>Method</x:ref> = <x:abnf-char-sequence>"OPTIONS"</x:abnf-char-sequence> ; "OPTIONS", <xref target="OPTIONS"/> |
---|
[334] | 429 | / <x:abnf-char-sequence>"GET"</x:abnf-char-sequence> ; "GET", <xref target="GET"/> |
---|
| 430 | / <x:abnf-char-sequence>"HEAD"</x:abnf-char-sequence> ; "HEAD", <xref target="HEAD"/> |
---|
| 431 | / <x:abnf-char-sequence>"POST"</x:abnf-char-sequence> ; "POST", <xref target="POST"/> |
---|
| 432 | / <x:abnf-char-sequence>"PUT"</x:abnf-char-sequence> ; "PUT", <xref target="PUT"/> |
---|
| 433 | / <x:abnf-char-sequence>"DELETE"</x:abnf-char-sequence> ; "DELETE", <xref target="DELETE"/> |
---|
| 434 | / <x:abnf-char-sequence>"TRACE"</x:abnf-char-sequence> ; "TRACE", <xref target="TRACE"/> |
---|
| 435 | / <x:abnf-char-sequence>"CONNECT"</x:abnf-char-sequence> ; "CONNECT", <xref target="CONNECT"/> |
---|
| 436 | / <x:ref>extension-method</x:ref> |
---|
[229] | 437 | <x:ref>extension-method</x:ref> = <x:ref>token</x:ref> |
---|
[8] | 438 | </artwork></figure> |
---|
| 439 | <t> |
---|
| 440 | The list of methods allowed by a resource can be specified in an |
---|
| 441 | Allow header field (<xref target="header.allow"/>). The return code of the response |
---|
| 442 | always notifies the client whether a method is currently allowed on a |
---|
| 443 | resource, since the set of allowed methods can change dynamically. An |
---|
| 444 | origin server &SHOULD; return the status code 405 (Method Not Allowed) |
---|
| 445 | if the method is known by the origin server but not allowed for the |
---|
| 446 | requested resource, and 501 (Not Implemented) if the method is |
---|
| 447 | unrecognized or not implemented by the origin server. The methods GET |
---|
| 448 | and HEAD &MUST; be supported by all general-purpose servers. All other |
---|
| 449 | methods are &OPTIONAL;; however, if the above methods are implemented, |
---|
| 450 | they &MUST; be implemented with the same semantics as those specified |
---|
| 451 | in <xref target="method.definitions"/>. |
---|
| 452 | </t> |
---|
[270] | 453 | |
---|
| 454 | <section title="Method Registry" anchor="method.registry"> |
---|
| 455 | <t> |
---|
| 456 | The HTTP Method Registry defines the name space for the Method token in the |
---|
| 457 | Request line of an HTTP request. |
---|
| 458 | </t> |
---|
| 459 | <t> |
---|
[286] | 460 | Registrations &MUST; include the following fields: |
---|
| 461 | <list style="symbols"> |
---|
| 462 | <t>Method Name (see <xref target="method"/>)</t> |
---|
| 463 | <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t> |
---|
| 464 | <t>Pointer to specification text</t> |
---|
| 465 | </list> |
---|
| 466 | </t> |
---|
| 467 | <t> |
---|
[270] | 468 | Values to be added to this name space are subject to IETF review |
---|
[591] | 469 | (<xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
[270] | 470 | </t> |
---|
| 471 | <t> |
---|
[672] | 472 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>. |
---|
[270] | 473 | </t> |
---|
[8] | 474 | </section> |
---|
[270] | 475 | </section> |
---|
[8] | 476 | |
---|
| 477 | <section title="Request Header Fields" anchor="request.header.fields"> |
---|
[229] | 478 | <x:anchor-alias value="request-header"/> |
---|
[8] | 479 | <t> |
---|
| 480 | The request-header fields allow the client to pass additional |
---|
| 481 | information about the request, and about the client itself, to the |
---|
| 482 | server. These fields act as request modifiers, with semantics |
---|
| 483 | equivalent to the parameters on a programming language method |
---|
| 484 | invocation. |
---|
| 485 | </t> |
---|
| 486 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-header"/> |
---|
[229] | 487 | <x:ref>request-header</x:ref> = <x:ref>Accept</x:ref> ; &header-accept; |
---|
[334] | 488 | / <x:ref>Accept-Charset</x:ref> ; &header-accept-charset; |
---|
| 489 | / <x:ref>Accept-Encoding</x:ref> ; &header-accept-encoding; |
---|
| 490 | / <x:ref>Accept-Language</x:ref> ; &header-accept-language; |
---|
| 491 | / <x:ref>Authorization</x:ref> ; &header-authorization; |
---|
| 492 | / <x:ref>Expect</x:ref> ; <xref target="header.expect"/> |
---|
| 493 | / <x:ref>From</x:ref> ; <xref target="header.from"/> |
---|
| 494 | / <x:ref>Host</x:ref> ; &header-host; |
---|
| 495 | / <x:ref>If-Match</x:ref> ; &header-if-match; |
---|
| 496 | / <x:ref>If-Modified-Since</x:ref> ; &header-if-modified-since; |
---|
| 497 | / <x:ref>If-None-Match</x:ref> ; &header-if-none-match; |
---|
| 498 | / <x:ref>If-Range</x:ref> ; &header-if-range; |
---|
| 499 | / <x:ref>If-Unmodified-Since</x:ref> ; &header-if-unmodified-since; |
---|
| 500 | / <x:ref>Max-Forwards</x:ref> ; <xref target="header.max-forwards"/> |
---|
| 501 | / <x:ref>Proxy-Authorization</x:ref> ; &header-proxy-authorization; |
---|
| 502 | / <x:ref>Range</x:ref> ; &header-range; |
---|
| 503 | / <x:ref>Referer</x:ref> ; <xref target="header.referer"/> |
---|
| 504 | / <x:ref>TE</x:ref> ; &header-te; |
---|
| 505 | / <x:ref>User-Agent</x:ref> ; <xref target="header.user-agent"/> |
---|
[8] | 506 | </artwork></figure> |
---|
| 507 | <t> |
---|
| 508 | Request-header field names can be extended reliably only in |
---|
| 509 | combination with a change in the protocol version. However, new or |
---|
| 510 | experimental header fields &MAY; be given the semantics of request-header |
---|
| 511 | fields if all parties in the communication recognize them to |
---|
| 512 | be request-header fields. Unrecognized header fields are treated as |
---|
| 513 | entity-header fields. |
---|
| 514 | </t> |
---|
| 515 | </section> |
---|
| 516 | |
---|
| 517 | <section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase"> |
---|
[229] | 518 | <x:anchor-alias value="Reason-Phrase"/> |
---|
| 519 | <x:anchor-alias value="Status-Code"/> |
---|
[426] | 520 | <x:anchor-alias value="extension-code"/> |
---|
[8] | 521 | <t> |
---|
| 522 | The Status-Code element is a 3-digit integer result code of the |
---|
[149] | 523 | attempt to understand and satisfy the request. The status codes listed |
---|
| 524 | below are defined in <xref target="status.codes"/>. |
---|
| 525 | The Reason-Phrase is intended to give a short |
---|
[8] | 526 | textual description of the Status-Code. The Status-Code is intended |
---|
| 527 | for use by automata and the Reason-Phrase is intended for the human |
---|
| 528 | user. The client is not required to examine or display the Reason-Phrase. |
---|
| 529 | </t> |
---|
| 530 | <t> |
---|
| 531 | The individual values of the numeric status codes defined for |
---|
| 532 | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |
---|
| 533 | presented below. The reason phrases listed here are only |
---|
| 534 | recommendations -- they &MAY; be replaced by local equivalents without |
---|
| 535 | affecting the protocol. |
---|
| 536 | </t> |
---|
| 537 | <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] | 538 | <x:ref>Status-Code</x:ref> = |
---|
[8] | 539 | "100" ; <xref target="status.100"/>: Continue |
---|
[334] | 540 | / "101" ; <xref target="status.101"/>: Switching Protocols |
---|
| 541 | / "200" ; <xref target="status.200"/>: OK |
---|
| 542 | / "201" ; <xref target="status.201"/>: Created |
---|
| 543 | / "202" ; <xref target="status.202"/>: Accepted |
---|
| 544 | / "203" ; <xref target="status.203"/>: Non-Authoritative Information |
---|
| 545 | / "204" ; <xref target="status.204"/>: No Content |
---|
| 546 | / "205" ; <xref target="status.205"/>: Reset Content |
---|
[700] | 547 | / "206" ; &status-206;: Partial Content |
---|
[334] | 548 | / "300" ; <xref target="status.300"/>: Multiple Choices |
---|
| 549 | / "301" ; <xref target="status.301"/>: Moved Permanently |
---|
| 550 | / "302" ; <xref target="status.302"/>: Found |
---|
| 551 | / "303" ; <xref target="status.303"/>: See Other |
---|
[700] | 552 | / "304" ; &status-304;: Not Modified |
---|
[334] | 553 | / "305" ; <xref target="status.305"/>: Use Proxy |
---|
| 554 | / "307" ; <xref target="status.307"/>: Temporary Redirect |
---|
| 555 | / "400" ; <xref target="status.400"/>: Bad Request |
---|
[700] | 556 | / "401" ; &status-401;: Unauthorized |
---|
[334] | 557 | / "402" ; <xref target="status.402"/>: Payment Required |
---|
| 558 | / "403" ; <xref target="status.403"/>: Forbidden |
---|
| 559 | / "404" ; <xref target="status.404"/>: Not Found |
---|
| 560 | / "405" ; <xref target="status.405"/>: Method Not Allowed |
---|
| 561 | / "406" ; <xref target="status.406"/>: Not Acceptable |
---|
[700] | 562 | / "407" ; &status-407;: Proxy Authentication Required |
---|
[334] | 563 | / "408" ; <xref target="status.408"/>: Request Time-out |
---|
| 564 | / "409" ; <xref target="status.409"/>: Conflict |
---|
| 565 | / "410" ; <xref target="status.410"/>: Gone |
---|
| 566 | / "411" ; <xref target="status.411"/>: Length Required |
---|
[700] | 567 | / "412" ; &status-412;: Precondition Failed |
---|
[334] | 568 | / "413" ; <xref target="status.413"/>: Request Entity Too Large |
---|
[465] | 569 | / "414" ; <xref target="status.414"/>: URI Too Long |
---|
[334] | 570 | / "415" ; <xref target="status.415"/>: Unsupported Media Type |
---|
[700] | 571 | / "416" ; status-416;: Requested range not satisfiable |
---|
[334] | 572 | / "417" ; <xref target="status.417"/>: Expectation Failed |
---|
| 573 | / "500" ; <xref target="status.500"/>: Internal Server Error |
---|
| 574 | / "501" ; <xref target="status.501"/>: Not Implemented |
---|
| 575 | / "502" ; <xref target="status.502"/>: Bad Gateway |
---|
| 576 | / "503" ; <xref target="status.503"/>: Service Unavailable |
---|
| 577 | / "504" ; <xref target="status.504"/>: Gateway Time-out |
---|
| 578 | / "505" ; <xref target="status.505"/>: HTTP Version not supported |
---|
| 579 | / <x:ref>extension-code</x:ref> |
---|
[8] | 580 | |
---|
[229] | 581 | <x:ref>extension-code</x:ref> = 3<x:ref>DIGIT</x:ref> |
---|
[398] | 582 | <x:ref>Reason-Phrase</x:ref> = *( <x:ref>WSP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) |
---|
[8] | 583 | </artwork></figure> |
---|
| 584 | <t> |
---|
| 585 | HTTP status codes are extensible. HTTP applications are not required |
---|
| 586 | to understand the meaning of all registered status codes, though such |
---|
| 587 | understanding is obviously desirable. However, applications &MUST; |
---|
| 588 | understand the class of any status code, as indicated by the first |
---|
| 589 | digit, and treat any unrecognized response as being equivalent to the |
---|
| 590 | x00 status code of that class, with the exception that an |
---|
| 591 | unrecognized response &MUST-NOT; be cached. For example, if an |
---|
| 592 | unrecognized status code of 431 is received by the client, it can |
---|
| 593 | safely assume that there was something wrong with its request and |
---|
| 594 | treat the response as if it had received a 400 status code. In such |
---|
| 595 | cases, user agents &SHOULD; present to the user the entity returned |
---|
| 596 | with the response, since that entity is likely to include human-readable |
---|
| 597 | information which will explain the unusual status. |
---|
| 598 | </t> |
---|
[262] | 599 | |
---|
| 600 | <section title="Status Code Registry" anchor="status.code.registry"> |
---|
| 601 | <t> |
---|
| 602 | The HTTP Status Code Registry defines the name space for the Status-Code |
---|
| 603 | token in the Status line of an HTTP response. |
---|
| 604 | </t> |
---|
| 605 | <t> |
---|
| 606 | Values to be added to this name space are subject to IETF review |
---|
[591] | 607 | (<xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
[262] | 608 | </t> |
---|
| 609 | <t> |
---|
| 610 | The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. |
---|
| 611 | </t> |
---|
[8] | 612 | </section> |
---|
| 613 | |
---|
[262] | 614 | </section> |
---|
| 615 | |
---|
[8] | 616 | <section title="Response Header Fields" anchor="response.header.fields"> |
---|
[229] | 617 | <x:anchor-alias value="response-header"/> |
---|
[8] | 618 | <t> |
---|
| 619 | The response-header fields allow the server to pass additional |
---|
| 620 | information about the response which cannot be placed in the Status-Line. |
---|
| 621 | These header fields give information about the server and about |
---|
[391] | 622 | further access to the resource identified by the request-target. |
---|
[8] | 623 | </t> |
---|
| 624 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> |
---|
[229] | 625 | <x:ref>response-header</x:ref> = <x:ref>Accept-Ranges</x:ref> ; &header-accept-ranges; |
---|
[334] | 626 | / <x:ref>Age</x:ref> ; &header-age; |
---|
| 627 | / <x:ref>Allow</x:ref> ; <xref target="header.allow"/> |
---|
| 628 | / <x:ref>ETag</x:ref> ; &header-etag; |
---|
| 629 | / <x:ref>Location</x:ref> ; <xref target="header.location"/> |
---|
| 630 | / <x:ref>Proxy-Authenticate</x:ref> ; &header-proxy-authenticate; |
---|
| 631 | / <x:ref>Retry-After</x:ref> ; <xref target="header.retry-after"/> |
---|
| 632 | / <x:ref>Server</x:ref> ; <xref target="header.server"/> |
---|
| 633 | / <x:ref>Vary</x:ref> ; &header-vary; |
---|
| 634 | / <x:ref>WWW-Authenticate</x:ref> ; &header-www-authenticate; |
---|
[8] | 635 | </artwork></figure> |
---|
| 636 | <t> |
---|
| 637 | Response-header field names can be extended reliably only in |
---|
| 638 | combination with a change in the protocol version. However, new or |
---|
| 639 | experimental header fields &MAY; be given the semantics of response-header |
---|
| 640 | fields if all parties in the communication recognize them to |
---|
| 641 | be response-header fields. Unrecognized header fields are treated as |
---|
| 642 | entity-header fields. |
---|
| 643 | </t> |
---|
| 644 | </section> |
---|
| 645 | |
---|
| 646 | <section title="Entity" anchor="entity"> |
---|
| 647 | <t> |
---|
| 648 | Request and Response messages &MAY; transfer an entity if not otherwise |
---|
| 649 | restricted by the request method or response status code. An entity |
---|
| 650 | consists of entity-header fields and an entity-body, although some |
---|
[29] | 651 | responses will only include the entity-headers. HTTP entity-body and |
---|
| 652 | entity-header fields are defined in &payload;. |
---|
[8] | 653 | </t> |
---|
| 654 | <t> |
---|
| 655 | An entity-body is only present in a message when a message-body is |
---|
[29] | 656 | present, as described in &message-body;. The entity-body is obtained |
---|
[8] | 657 | from the message-body by decoding any Transfer-Encoding that might |
---|
| 658 | have been applied to ensure safe and proper transfer of the message. |
---|
| 659 | </t> |
---|
[695] | 660 | |
---|
| 661 | <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation"> |
---|
| 662 | <t> |
---|
| 663 | It is sometimes necessary to determine the identity of the resource |
---|
| 664 | associated with a representation. |
---|
| 665 | </t> |
---|
| 666 | <t> |
---|
| 667 | An HTTP request representation, when present, is always associated with an |
---|
| 668 | anonymous (i.e., unidentified) resource. |
---|
| 669 | </t> |
---|
| 670 | <t> |
---|
| 671 | In the common case, an HTTP response is a representation of the resource |
---|
| 672 | located at the request-URI. However, this is not always the case. To |
---|
| 673 | determine the URI of the resource a response is associated with, the |
---|
| 674 | following rules are used (first match winning): |
---|
| 675 | </t> |
---|
| 676 | <t><list style="numbers"> |
---|
| 677 | <t>If the response status code is 200 or 203 and the request method was GET, |
---|
| 678 | the response is a representation of the resource at the request-URI.</t> |
---|
| 679 | <t>If the response status is 204, 206, or 304 and the request method was GET |
---|
| 680 | or HEAD, the response is a partial representation of the resource at the |
---|
| 681 | request-URI (see &caching-combining-headers;).</t> |
---|
| 682 | <t>If the response has a Content-Location header, and that URI is the same |
---|
| 683 | as the request-URI <cref>(see [ref])</cref>, the response is a representation of the |
---|
| 684 | resource at the request-URI.</t> |
---|
| 685 | <t>If the response has a Content-Location header, and that URI is not the |
---|
| 686 | same as the request-URI, the response asserts that it is a representation of |
---|
| 687 | the resource at the Content-Location URI (but it may not be).</t> |
---|
| 688 | <t>Otherwise, the response is a representation of an anonymous (i.e., |
---|
| 689 | unidentified) resource.</t> |
---|
| 690 | </list></t> |
---|
| 691 | <t> |
---|
| 692 | <cref anchor="TODO-req-uri"> |
---|
| 693 | Note that 'request-URI' is used here; however, we need to come up with a |
---|
| 694 | term to denote "the URI that can be inferred from examining the |
---|
| 695 | request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />). |
---|
| 696 | Also, the comparison function is going to have to be defined somewhere, |
---|
| 697 | because we already need to compare URIs for things like cache invalidation.</cref> |
---|
| 698 | </t> |
---|
[8] | 699 | </section> |
---|
| 700 | |
---|
[695] | 701 | </section> |
---|
[8] | 702 | |
---|
[695] | 703 | |
---|
[8] | 704 | <section title="Method Definitions" anchor="method.definitions"> |
---|
| 705 | <t> |
---|
| 706 | The set of common methods for HTTP/1.1 is defined below. Although |
---|
| 707 | this set can be expanded, additional methods cannot be assumed to |
---|
| 708 | share the same semantics for separately extended clients and servers. |
---|
| 709 | </t> |
---|
| 710 | |
---|
| 711 | <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent"> |
---|
| 712 | |
---|
| 713 | <section title="Safe Methods" anchor="safe.methods"> |
---|
[286] | 714 | <iref item="Safe Methods" primary="true"/> |
---|
[8] | 715 | <t> |
---|
| 716 | Implementors should be aware that the software represents the user in |
---|
| 717 | their interactions over the Internet, and should be careful to allow |
---|
| 718 | the user to be aware of any actions they might take which may have an |
---|
| 719 | unexpected significance to themselves or others. |
---|
| 720 | </t> |
---|
| 721 | <t> |
---|
| 722 | In particular, the convention has been established that the GET and |
---|
| 723 | HEAD methods &SHOULD-NOT; have the significance of taking an action |
---|
[286] | 724 | other than retrieval. These methods ought to be considered "<x:dfn anchor="safe">safe</x:dfn>". |
---|
[8] | 725 | This allows user agents to represent other methods, such as POST, PUT |
---|
| 726 | and DELETE, in a special way, so that the user is made aware of the |
---|
| 727 | fact that a possibly unsafe action is being requested. |
---|
| 728 | </t> |
---|
| 729 | <t> |
---|
| 730 | Naturally, it is not possible to ensure that the server does not |
---|
| 731 | generate side-effects as a result of performing a GET request; in |
---|
| 732 | fact, some dynamic resources consider that a feature. The important |
---|
| 733 | distinction here is that the user did not request the side-effects, |
---|
| 734 | so therefore cannot be held accountable for them. |
---|
| 735 | </t> |
---|
| 736 | </section> |
---|
| 737 | |
---|
| 738 | <section title="Idempotent Methods" anchor="idempotent.methods"> |
---|
[286] | 739 | <iref item="Idempotent Methods" primary="true"/> |
---|
[8] | 740 | <t> |
---|
[657] | 741 | Methods can also have the property of "idempotence" in that, aside |
---|
| 742 | from error or expiration issues, the intended effect of multiple |
---|
| 743 | identical requests is the same as for a single request. |
---|
| 744 | The methods PUT, DELETE, and all safe methods are idempotent. |
---|
| 745 | It is important to note that idempotence refers only to changes |
---|
| 746 | requested by the client: a server is free to change its state due |
---|
| 747 | to multiple requests for the purpose of tracking those requests, |
---|
| 748 | versioning of results, etc. |
---|
[8] | 749 | </t> |
---|
| 750 | </section> |
---|
| 751 | </section> |
---|
| 752 | |
---|
| 753 | <section title="OPTIONS" anchor="OPTIONS"> |
---|
[286] | 754 | <rdf:Description> |
---|
| 755 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
| 756 | </rdf:Description> |
---|
[8] | 757 | <iref primary="true" item="OPTIONS method" x:for-anchor=""/> |
---|
| 758 | <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> |
---|
| 759 | <t> |
---|
| 760 | The OPTIONS method represents a request for information about the |
---|
| 761 | communication options available on the request/response chain |
---|
[391] | 762 | identified by the request-target. This method allows the client to |
---|
[8] | 763 | determine the options and/or requirements associated with a resource, |
---|
| 764 | or the capabilities of a server, without implying a resource action |
---|
| 765 | or initiating a resource retrieval. |
---|
| 766 | </t> |
---|
| 767 | <t> |
---|
| 768 | Responses to this method are not cacheable. |
---|
| 769 | </t> |
---|
| 770 | <t> |
---|
| 771 | If the OPTIONS request includes an entity-body (as indicated by the |
---|
| 772 | presence of Content-Length or Transfer-Encoding), then the media type |
---|
| 773 | &MUST; be indicated by a Content-Type field. Although this |
---|
| 774 | specification does not define any use for such a body, future |
---|
| 775 | extensions to HTTP might use the OPTIONS body to make more detailed |
---|
[280] | 776 | queries on the server. |
---|
[8] | 777 | </t> |
---|
| 778 | <t> |
---|
[391] | 779 | If the request-target is an asterisk ("*"), the OPTIONS request is |
---|
[8] | 780 | intended to apply to the server in general rather than to a specific |
---|
| 781 | resource. Since a server's communication options typically depend on |
---|
| 782 | the resource, the "*" request is only useful as a "ping" or "no-op" |
---|
| 783 | type of method; it does nothing beyond allowing the client to test |
---|
| 784 | the capabilities of the server. For example, this can be used to test |
---|
| 785 | a proxy for HTTP/1.1 compliance (or lack thereof). |
---|
| 786 | </t> |
---|
| 787 | <t> |
---|
[391] | 788 | If the request-target is not an asterisk, the OPTIONS request applies |
---|
[8] | 789 | only to the options that are available when communicating with that |
---|
| 790 | resource. |
---|
| 791 | </t> |
---|
| 792 | <t> |
---|
| 793 | A 200 response &SHOULD; include any header fields that indicate |
---|
| 794 | optional features implemented by the server and applicable to that |
---|
| 795 | resource (e.g., Allow), possibly including extensions not defined by |
---|
| 796 | this specification. The response body, if any, &SHOULD; also include |
---|
| 797 | information about the communication options. The format for such a |
---|
| 798 | body is not defined by this specification, but might be defined by |
---|
| 799 | future extensions to HTTP. Content negotiation &MAY; be used to select |
---|
| 800 | the appropriate response format. If no response body is included, the |
---|
| 801 | response &MUST; include a Content-Length field with a field-value of |
---|
| 802 | "0". |
---|
| 803 | </t> |
---|
| 804 | <t> |
---|
| 805 | The Max-Forwards request-header field &MAY; be used to target a |
---|
| 806 | specific proxy in the request chain. When a proxy receives an OPTIONS |
---|
[374] | 807 | request on an absolute-URI for which request forwarding is permitted, |
---|
[8] | 808 | the proxy &MUST; check for a Max-Forwards field. If the Max-Forwards |
---|
| 809 | field-value is zero ("0"), the proxy &MUST-NOT; forward the message; |
---|
| 810 | instead, the proxy &SHOULD; respond with its own communication options. |
---|
| 811 | If the Max-Forwards field-value is an integer greater than zero, the |
---|
| 812 | proxy &MUST; decrement the field-value when it forwards the request. If |
---|
| 813 | no Max-Forwards field is present in the request, then the forwarded |
---|
| 814 | request &MUST-NOT; include a Max-Forwards field. |
---|
| 815 | </t> |
---|
| 816 | </section> |
---|
| 817 | |
---|
| 818 | <section title="GET" anchor="GET"> |
---|
[286] | 819 | <rdf:Description> |
---|
| 820 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
| 821 | </rdf:Description> |
---|
[8] | 822 | <iref primary="true" item="GET method" x:for-anchor=""/> |
---|
| 823 | <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> |
---|
| 824 | <t> |
---|
| 825 | The GET method means retrieve whatever information (in the form of an |
---|
[391] | 826 | entity) is identified by the request-target. If the request-target refers |
---|
[8] | 827 | to a data-producing process, it is the produced data which shall be |
---|
| 828 | returned as the entity in the response and not the source text of the |
---|
| 829 | process, unless that text happens to be the output of the process. |
---|
| 830 | </t> |
---|
| 831 | <t> |
---|
| 832 | The semantics of the GET method change to a "conditional GET" if the |
---|
| 833 | request message includes an If-Modified-Since, If-Unmodified-Since, |
---|
| 834 | If-Match, If-None-Match, or If-Range header field. A conditional GET |
---|
| 835 | method requests that the entity be transferred only under the |
---|
| 836 | circumstances described by the conditional header field(s). The |
---|
| 837 | conditional GET method is intended to reduce unnecessary network |
---|
| 838 | usage by allowing cached entities to be refreshed without requiring |
---|
| 839 | multiple requests or transferring data already held by the client. |
---|
| 840 | </t> |
---|
| 841 | <t> |
---|
| 842 | The semantics of the GET method change to a "partial GET" if the |
---|
| 843 | request message includes a Range header field. A partial GET requests |
---|
[29] | 844 | that only part of the entity be transferred, as described in &header-range;. |
---|
[8] | 845 | The partial GET method is intended to reduce unnecessary |
---|
| 846 | network usage by allowing partially-retrieved entities to be |
---|
| 847 | completed without transferring data already held by the client. |
---|
| 848 | </t> |
---|
| 849 | <t> |
---|
| 850 | The response to a GET request is cacheable if and only if it meets |
---|
[29] | 851 | the requirements for HTTP caching described in &caching;. |
---|
[8] | 852 | </t> |
---|
| 853 | <t> |
---|
| 854 | See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms. |
---|
| 855 | </t> |
---|
| 856 | </section> |
---|
| 857 | |
---|
| 858 | <section title="HEAD" anchor="HEAD"> |
---|
[286] | 859 | <rdf:Description> |
---|
| 860 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
| 861 | </rdf:Description> |
---|
[8] | 862 | <iref primary="true" item="HEAD method" x:for-anchor=""/> |
---|
| 863 | <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/> |
---|
| 864 | <t> |
---|
| 865 | The HEAD method is identical to GET except that the server &MUST-NOT; |
---|
| 866 | return a message-body in the response. The metainformation contained |
---|
| 867 | in the HTTP headers in response to a HEAD request &SHOULD; be identical |
---|
| 868 | to the information sent in response to a GET request. This method can |
---|
| 869 | be used for obtaining metainformation about the entity implied by the |
---|
| 870 | request without transferring the entity-body itself. This method is |
---|
| 871 | often used for testing hypertext links for validity, accessibility, |
---|
| 872 | and recent modification. |
---|
| 873 | </t> |
---|
| 874 | <t> |
---|
| 875 | The response to a HEAD request &MAY; be cacheable in the sense that the |
---|
| 876 | information contained in the response &MAY; be used to update a |
---|
| 877 | previously cached entity from that resource. If the new field values |
---|
| 878 | indicate that the cached entity differs from the current entity (as |
---|
| 879 | would be indicated by a change in Content-Length, Content-MD5, ETag |
---|
| 880 | or Last-Modified), then the cache &MUST; treat the cache entry as |
---|
| 881 | stale. |
---|
| 882 | </t> |
---|
| 883 | </section> |
---|
| 884 | |
---|
| 885 | <section title="POST" anchor="POST"> |
---|
| 886 | <iref primary="true" item="POST method" x:for-anchor=""/> |
---|
| 887 | <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/> |
---|
| 888 | <t> |
---|
| 889 | The POST method is used to request that the origin server accept the |
---|
[78] | 890 | entity enclosed in the request as data to be processed by the resource |
---|
[391] | 891 | identified by the request-target in the Request-Line. POST is designed |
---|
[8] | 892 | to allow a uniform method to cover the following functions: |
---|
| 893 | <list style="symbols"> |
---|
| 894 | <t> |
---|
| 895 | Annotation of existing resources; |
---|
| 896 | </t> |
---|
| 897 | <t> |
---|
| 898 | Posting a message to a bulletin board, newsgroup, mailing list, |
---|
| 899 | or similar group of articles; |
---|
| 900 | </t> |
---|
| 901 | <t> |
---|
| 902 | Providing a block of data, such as the result of submitting a |
---|
| 903 | form, to a data-handling process; |
---|
| 904 | </t> |
---|
| 905 | <t> |
---|
| 906 | Extending a database through an append operation. |
---|
| 907 | </t> |
---|
| 908 | </list> |
---|
| 909 | </t> |
---|
| 910 | <t> |
---|
| 911 | The actual function performed by the POST method is determined by the |
---|
[391] | 912 | server and is usually dependent on the request-target. |
---|
[8] | 913 | </t> |
---|
| 914 | <t> |
---|
| 915 | The action performed by the POST method might not result in a |
---|
| 916 | resource that can be identified by a URI. In this case, either 200 |
---|
| 917 | (OK) or 204 (No Content) is the appropriate response status, |
---|
| 918 | depending on whether or not the response includes an entity that |
---|
| 919 | describes the result. |
---|
| 920 | </t> |
---|
| 921 | <t> |
---|
| 922 | If a resource has been created on the origin server, the response |
---|
| 923 | &SHOULD; be 201 (Created) and contain an entity which describes the |
---|
| 924 | status of the request and refers to the new resource, and a Location |
---|
| 925 | header (see <xref target="header.location"/>). |
---|
| 926 | </t> |
---|
| 927 | <t> |
---|
| 928 | Responses to this method are not cacheable, unless the response |
---|
| 929 | includes appropriate Cache-Control or Expires header fields. However, |
---|
| 930 | the 303 (See Other) response can be used to direct the user agent to |
---|
| 931 | retrieve a cacheable resource. |
---|
| 932 | </t> |
---|
| 933 | </section> |
---|
| 934 | |
---|
| 935 | <section title="PUT" anchor="PUT"> |
---|
| 936 | <iref primary="true" item="PUT method" x:for-anchor=""/> |
---|
| 937 | <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> |
---|
| 938 | <t> |
---|
[241] | 939 | The PUT method requests that the enclosed entity be stored at the |
---|
[391] | 940 | supplied request-target. If the request-target refers to an already |
---|
[8] | 941 | existing resource, the enclosed entity &SHOULD; be considered as a |
---|
| 942 | modified version of the one residing on the origin server. If the |
---|
[391] | 943 | request-target does not point to an existing resource, and that URI is |
---|
[8] | 944 | capable of being defined as a new resource by the requesting user |
---|
| 945 | agent, the origin server can create the resource with that URI. If a |
---|
[391] | 946 | new resource is created at the request-target, the origin server &MUST; |
---|
[609] | 947 | inform the user agent |
---|
[8] | 948 | via the 201 (Created) response. If an existing resource is modified, |
---|
| 949 | either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent |
---|
| 950 | to indicate successful completion of the request. If the resource |
---|
[391] | 951 | could not be created or modified with the request-target, an appropriate |
---|
[8] | 952 | error response &SHOULD; be given that reflects the nature of the |
---|
| 953 | problem. The recipient of the entity &MUST-NOT; ignore any Content-* |
---|
[333] | 954 | headers (headers starting with the prefix 'Content-') that it does |
---|
| 955 | not understand or implement |
---|
[8] | 956 | and &MUST; return a 501 (Not Implemented) response in such cases. |
---|
| 957 | </t> |
---|
| 958 | <t> |
---|
[391] | 959 | If the request passes through a cache and the request-target identifies |
---|
[8] | 960 | one or more currently cached entities, those entries &SHOULD; be |
---|
| 961 | treated as stale. Responses to this method are not cacheable. |
---|
| 962 | </t> |
---|
| 963 | <t> |
---|
| 964 | The fundamental difference between the POST and PUT requests is |
---|
[391] | 965 | reflected in the different meaning of the request-target. The URI in a |
---|
[8] | 966 | POST request identifies the resource that will handle the enclosed |
---|
| 967 | entity. That resource might be a data-accepting process, a gateway to |
---|
| 968 | some other protocol, or a separate entity that accepts annotations. |
---|
| 969 | In contrast, the URI in a PUT request identifies the entity enclosed |
---|
| 970 | with the request -- the user agent knows what URI is intended and the |
---|
| 971 | server &MUST-NOT; attempt to apply the request to some other resource. |
---|
| 972 | If the server desires that the request be applied to a different URI, |
---|
| 973 | it &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; |
---|
| 974 | then make its own decision regarding whether or not to redirect the |
---|
| 975 | request. |
---|
| 976 | </t> |
---|
| 977 | <t> |
---|
| 978 | A single resource &MAY; be identified by many different URIs. For |
---|
| 979 | example, an article might have a URI for identifying "the current |
---|
| 980 | version" which is separate from the URI identifying each particular |
---|
| 981 | version. In this case, a PUT request on a general URI might result in |
---|
| 982 | several other URIs being defined by the origin server. |
---|
| 983 | </t> |
---|
| 984 | <t> |
---|
| 985 | HTTP/1.1 does not define how a PUT method affects the state of an |
---|
| 986 | origin server. |
---|
| 987 | </t> |
---|
| 988 | <t> |
---|
| 989 | Unless otherwise specified for a particular entity-header, the |
---|
| 990 | entity-headers in the PUT request &SHOULD; be applied to the resource |
---|
| 991 | created or modified by the PUT. |
---|
| 992 | </t> |
---|
| 993 | </section> |
---|
| 994 | |
---|
| 995 | <section title="DELETE" anchor="DELETE"> |
---|
| 996 | <iref primary="true" item="DELETE method" x:for-anchor=""/> |
---|
| 997 | <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> |
---|
| 998 | <t> |
---|
| 999 | The DELETE method requests that the origin server delete the resource |
---|
[391] | 1000 | identified by the request-target. This method &MAY; be overridden by human |
---|
[8] | 1001 | intervention (or other means) on the origin server. The client cannot |
---|
| 1002 | be guaranteed that the operation has been carried out, even if the |
---|
| 1003 | status code returned from the origin server indicates that the action |
---|
| 1004 | has been completed successfully. However, the server &SHOULD-NOT; |
---|
| 1005 | indicate success unless, at the time the response is given, it |
---|
| 1006 | intends to delete the resource or move it to an inaccessible |
---|
| 1007 | location. |
---|
| 1008 | </t> |
---|
| 1009 | <t> |
---|
| 1010 | A successful response &SHOULD; be 200 (OK) if the response includes an |
---|
| 1011 | entity describing the status, 202 (Accepted) if the action has not |
---|
| 1012 | yet been enacted, or 204 (No Content) if the action has been enacted |
---|
| 1013 | but the response does not include an entity. |
---|
| 1014 | </t> |
---|
| 1015 | <t> |
---|
[391] | 1016 | If the request passes through a cache and the request-target identifies |
---|
[8] | 1017 | one or more currently cached entities, those entries &SHOULD; be |
---|
| 1018 | treated as stale. Responses to this method are not cacheable. |
---|
| 1019 | </t> |
---|
| 1020 | </section> |
---|
| 1021 | |
---|
| 1022 | <section title="TRACE" anchor="TRACE"> |
---|
[286] | 1023 | <rdf:Description> |
---|
| 1024 | <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> |
---|
| 1025 | </rdf:Description> |
---|
[8] | 1026 | <iref primary="true" item="TRACE method" x:for-anchor=""/> |
---|
| 1027 | <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/> |
---|
| 1028 | <t> |
---|
| 1029 | The TRACE method is used to invoke a remote, application-layer loop-back |
---|
| 1030 | of the request message. The final recipient of the request |
---|
| 1031 | &SHOULD; reflect the message received back to the client as the |
---|
| 1032 | entity-body of a 200 (OK) response. The final recipient is either the |
---|
| 1033 | origin server or the first proxy or gateway to receive a Max-Forwards |
---|
| 1034 | value of zero (0) in the request (see <xref target="header.max-forwards"/>). A TRACE request |
---|
| 1035 | &MUST-NOT; include an entity. |
---|
| 1036 | </t> |
---|
| 1037 | <t> |
---|
| 1038 | TRACE allows the client to see what is being received at the other |
---|
| 1039 | end of the request chain and use that data for testing or diagnostic |
---|
[29] | 1040 | information. The value of the Via header field (&header-via;) is of |
---|
[8] | 1041 | particular interest, since it acts as a trace of the request chain. |
---|
| 1042 | Use of the Max-Forwards header field allows the client to limit the |
---|
| 1043 | length of the request chain, which is useful for testing a chain of |
---|
| 1044 | proxies forwarding messages in an infinite loop. |
---|
| 1045 | </t> |
---|
| 1046 | <t> |
---|
| 1047 | If the request is valid, the response &SHOULD; contain the entire |
---|
| 1048 | request message in the entity-body, with a Content-Type of |
---|
[263] | 1049 | "message/http" (see &media-type-message-http;). Responses to this method |
---|
| 1050 | &MUST-NOT; be cached. |
---|
[8] | 1051 | </t> |
---|
| 1052 | </section> |
---|
| 1053 | |
---|
| 1054 | <section title="CONNECT" anchor="CONNECT"> |
---|
| 1055 | <iref primary="true" item="CONNECT method" x:for-anchor=""/> |
---|
| 1056 | <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> |
---|
| 1057 | <t> |
---|
| 1058 | This specification reserves the method name CONNECT for use with a |
---|
| 1059 | proxy that can dynamically switch to being a tunnel (e.g. SSL |
---|
[274] | 1060 | tunneling <xref target="RFC2817"/>). |
---|
[8] | 1061 | </t> |
---|
| 1062 | </section> |
---|
| 1063 | </section> |
---|
| 1064 | |
---|
| 1065 | |
---|
| 1066 | <section title="Status Code Definitions" anchor="status.codes"> |
---|
| 1067 | <t> |
---|
[579] | 1068 | Each Status-Code is described below, including any metainformation required |
---|
| 1069 | in the response. |
---|
[8] | 1070 | </t> |
---|
| 1071 | |
---|
| 1072 | <section title="Informational 1xx" anchor="status.1xx"> |
---|
| 1073 | <t> |
---|
| 1074 | This class of status code indicates a provisional response, |
---|
| 1075 | consisting only of the Status-Line and optional headers, and is |
---|
| 1076 | terminated by an empty line. There are no required headers for this |
---|
| 1077 | class of status code. Since HTTP/1.0 did not define any 1xx status |
---|
| 1078 | codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client |
---|
| 1079 | except under experimental conditions. |
---|
| 1080 | </t> |
---|
| 1081 | <t> |
---|
| 1082 | A client &MUST; be prepared to accept one or more 1xx status responses |
---|
| 1083 | prior to a regular response, even if the client does not expect a 100 |
---|
| 1084 | (Continue) status message. Unexpected 1xx status responses &MAY; be |
---|
| 1085 | ignored by a user agent. |
---|
| 1086 | </t> |
---|
| 1087 | <t> |
---|
| 1088 | Proxies &MUST; forward 1xx responses, unless the connection between the |
---|
| 1089 | proxy and its client has been closed, or unless the proxy itself |
---|
| 1090 | requested the generation of the 1xx response. (For example, if a |
---|
| 1091 | proxy adds a "Expect: 100-continue" field when it forwards a request, |
---|
| 1092 | then it need not forward the corresponding 100 (Continue) |
---|
| 1093 | response(s).) |
---|
| 1094 | </t> |
---|
| 1095 | |
---|
| 1096 | <section title="100 Continue" anchor="status.100"> |
---|
| 1097 | <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/> |
---|
| 1098 | <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/> |
---|
| 1099 | <t> |
---|
| 1100 | The client &SHOULD; continue with its request. This interim response is |
---|
| 1101 | used to inform the client that the initial part of the request has |
---|
| 1102 | been received and has not yet been rejected by the server. The client |
---|
| 1103 | &SHOULD; continue by sending the remainder of the request or, if the |
---|
| 1104 | request has already been completed, ignore this response. The server |
---|
| 1105 | &MUST; send a final response after the request has been completed. See |
---|
[29] | 1106 | &use100; for detailed discussion of the use and handling of this |
---|
[8] | 1107 | status code. |
---|
| 1108 | </t> |
---|
| 1109 | </section> |
---|
| 1110 | |
---|
| 1111 | <section title="101 Switching Protocols" anchor="status.101"> |
---|
| 1112 | <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/> |
---|
| 1113 | <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/> |
---|
| 1114 | <t> |
---|
| 1115 | The server understands and is willing to comply with the client's |
---|
[29] | 1116 | request, via the Upgrade message header field (&header-upgrade;), for a |
---|
[8] | 1117 | change in the application protocol being used on this connection. The |
---|
| 1118 | server will switch protocols to those defined by the response's |
---|
| 1119 | Upgrade header field immediately after the empty line which |
---|
| 1120 | terminates the 101 response. |
---|
| 1121 | </t> |
---|
| 1122 | <t> |
---|
| 1123 | The protocol &SHOULD; be switched only when it is advantageous to do |
---|
| 1124 | so. For example, switching to a newer version of HTTP is advantageous |
---|
| 1125 | over older versions, and switching to a real-time, synchronous |
---|
| 1126 | protocol might be advantageous when delivering resources that use |
---|
| 1127 | such features. |
---|
| 1128 | </t> |
---|
| 1129 | </section> |
---|
| 1130 | </section> |
---|
| 1131 | |
---|
| 1132 | <section title="Successful 2xx" anchor="status.2xx"> |
---|
| 1133 | <t> |
---|
| 1134 | This class of status code indicates that the client's request was |
---|
| 1135 | successfully received, understood, and accepted. |
---|
| 1136 | </t> |
---|
| 1137 | |
---|
| 1138 | <section title="200 OK" anchor="status.200"> |
---|
| 1139 | <iref primary="true" item="200 OK (status code)" x:for-anchor=""/> |
---|
| 1140 | <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/> |
---|
| 1141 | <t> |
---|
| 1142 | The request has succeeded. The information returned with the response |
---|
| 1143 | is dependent on the method used in the request, for example: |
---|
| 1144 | <list style="hanging"> |
---|
| 1145 | <t hangText="GET"> |
---|
| 1146 | an entity corresponding to the requested resource is sent in |
---|
| 1147 | the response; |
---|
| 1148 | </t> |
---|
| 1149 | <t hangText="HEAD"> |
---|
| 1150 | the entity-header fields corresponding to the requested |
---|
| 1151 | resource are sent in the response without any message-body; |
---|
| 1152 | </t> |
---|
| 1153 | <t hangText="POST"> |
---|
| 1154 | an entity describing or containing the result of the action; |
---|
| 1155 | </t> |
---|
| 1156 | <t hangText="TRACE"> |
---|
| 1157 | an entity containing the request message as received by the |
---|
| 1158 | end server. |
---|
| 1159 | </t> |
---|
| 1160 | </list> |
---|
| 1161 | </t> |
---|
| 1162 | </section> |
---|
| 1163 | |
---|
| 1164 | <section title="201 Created" anchor="status.201"> |
---|
| 1165 | <iref primary="true" item="201 Created (status code)" x:for-anchor=""/> |
---|
| 1166 | <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/> |
---|
| 1167 | <t> |
---|
| 1168 | The request has been fulfilled and resulted in a new resource being |
---|
| 1169 | created. The newly created resource can be referenced by the URI(s) |
---|
| 1170 | returned in the entity of the response, with the most specific URI |
---|
| 1171 | for the resource given by a Location header field. The response |
---|
| 1172 | &SHOULD; include an entity containing a list of resource |
---|
| 1173 | characteristics and location(s) from which the user or user agent can |
---|
| 1174 | choose the one most appropriate. The entity format is specified by |
---|
| 1175 | the media type given in the Content-Type header field. The origin |
---|
| 1176 | server &MUST; create the resource before returning the 201 status code. |
---|
| 1177 | If the action cannot be carried out immediately, the server &SHOULD; |
---|
| 1178 | respond with 202 (Accepted) response instead. |
---|
| 1179 | </t> |
---|
| 1180 | <t> |
---|
| 1181 | A 201 response &MAY; contain an ETag response header field indicating |
---|
| 1182 | the current value of the entity tag for the requested variant just |
---|
[29] | 1183 | created, see &header-etag;. |
---|
[8] | 1184 | </t> |
---|
| 1185 | </section> |
---|
| 1186 | |
---|
| 1187 | <section title="202 Accepted" anchor="status.202"> |
---|
| 1188 | <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/> |
---|
| 1189 | <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/> |
---|
| 1190 | <t> |
---|
| 1191 | The request has been accepted for processing, but the processing has |
---|
| 1192 | not been completed. The request might or might not eventually be |
---|
| 1193 | acted upon, as it might be disallowed when processing actually takes |
---|
| 1194 | place. There is no facility for re-sending a status code from an |
---|
| 1195 | asynchronous operation such as this. |
---|
| 1196 | </t> |
---|
| 1197 | <t> |
---|
| 1198 | The 202 response is intentionally non-committal. Its purpose is to |
---|
| 1199 | allow a server to accept a request for some other process (perhaps a |
---|
| 1200 | batch-oriented process that is only run once per day) without |
---|
| 1201 | requiring that the user agent's connection to the server persist |
---|
| 1202 | until the process is completed. The entity returned with this |
---|
| 1203 | response &SHOULD; include an indication of the request's current status |
---|
| 1204 | and either a pointer to a status monitor or some estimate of when the |
---|
| 1205 | user can expect the request to be fulfilled. |
---|
| 1206 | </t> |
---|
| 1207 | </section> |
---|
| 1208 | |
---|
| 1209 | <section title="203 Non-Authoritative Information" anchor="status.203"> |
---|
| 1210 | <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/> |
---|
| 1211 | <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> |
---|
| 1212 | <t> |
---|
| 1213 | The returned metainformation in the entity-header is not the |
---|
| 1214 | definitive set as available from the origin server, but is gathered |
---|
| 1215 | from a local or a third-party copy. The set presented &MAY; be a subset |
---|
| 1216 | or superset of the original version. For example, including local |
---|
| 1217 | annotation information about the resource might result in a superset |
---|
| 1218 | of the metainformation known by the origin server. Use of this |
---|
| 1219 | response code is not required and is only appropriate when the |
---|
| 1220 | response would otherwise be 200 (OK). |
---|
| 1221 | </t> |
---|
| 1222 | </section> |
---|
| 1223 | |
---|
| 1224 | <section title="204 No Content" anchor="status.204"> |
---|
| 1225 | <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/> |
---|
| 1226 | <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/> |
---|
| 1227 | <t> |
---|
| 1228 | The server has fulfilled the request but does not need to return an |
---|
| 1229 | entity-body, and might want to return updated metainformation. The |
---|
| 1230 | response &MAY; include new or updated metainformation in the form of |
---|
| 1231 | entity-headers, which if present &SHOULD; be associated with the |
---|
| 1232 | requested variant. |
---|
| 1233 | </t> |
---|
| 1234 | <t> |
---|
| 1235 | If the client is a user agent, it &SHOULD-NOT; change its document view |
---|
| 1236 | from that which caused the request to be sent. This response is |
---|
| 1237 | primarily intended to allow input for actions to take place without |
---|
| 1238 | causing a change to the user agent's active document view, although |
---|
| 1239 | any new or updated metainformation &SHOULD; be applied to the document |
---|
| 1240 | currently in the user agent's active view. |
---|
| 1241 | </t> |
---|
| 1242 | <t> |
---|
| 1243 | The 204 response &MUST-NOT; include a message-body, and thus is always |
---|
| 1244 | terminated by the first empty line after the header fields. |
---|
| 1245 | </t> |
---|
| 1246 | </section> |
---|
| 1247 | |
---|
| 1248 | <section title="205 Reset Content" anchor="status.205"> |
---|
| 1249 | <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/> |
---|
| 1250 | <iref primary="true" item="Status Codes" subitem="205 Reset Content" x:for-anchor=""/> |
---|
| 1251 | <t> |
---|
| 1252 | The server has fulfilled the request and the user agent &SHOULD; reset |
---|
| 1253 | the document view which caused the request to be sent. This response |
---|
| 1254 | is primarily intended to allow input for actions to take place via |
---|
| 1255 | user input, followed by a clearing of the form in which the input is |
---|
| 1256 | given so that the user can easily initiate another input action. The |
---|
| 1257 | response &MUST-NOT; include an entity. |
---|
| 1258 | </t> |
---|
| 1259 | </section> |
---|
| 1260 | |
---|
| 1261 | <section title="206 Partial Content" anchor="status.206"> |
---|
| 1262 | <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/> |
---|
| 1263 | <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/> |
---|
[700] | 1264 | <rdf:Description> |
---|
| 1265 | <redirects-to xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">Part5</redirects-to> |
---|
| 1266 | </rdf:Description> |
---|
[8] | 1267 | <t> |
---|
[29] | 1268 | The server has fulfilled the partial GET request for the resource |
---|
[700] | 1269 | and the enclosed entity is a partial representation as defined in &status-206;. |
---|
[8] | 1270 | </t> |
---|
| 1271 | </section> |
---|
| 1272 | </section> |
---|
| 1273 | |
---|
| 1274 | <section title="Redirection 3xx" anchor="status.3xx"> |
---|
| 1275 | <t> |
---|
| 1276 | This class of status code indicates that further action needs to be |
---|
| 1277 | taken by the user agent in order to fulfill the request. The action |
---|
| 1278 | required &MAY; be carried out by the user agent without interaction |
---|
| 1279 | with the user if and only if the method used in the second request is |
---|
| 1280 | GET or HEAD. A client &SHOULD; detect infinite redirection loops, since |
---|
| 1281 | such loops generate network traffic for each redirection. |
---|
| 1282 | </t> |
---|
[563] | 1283 | <x:note> |
---|
| 1284 | <t> |
---|
[629] | 1285 | <x:h>Note:</x:h> an earlier version of this specification recommended a |
---|
| 1286 | maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>). |
---|
| 1287 | Content developers should be aware that there might be clients that |
---|
| 1288 | implement such a fixed limitation. |
---|
[563] | 1289 | </t> |
---|
| 1290 | </x:note> |
---|
[8] | 1291 | |
---|
| 1292 | <section title="300 Multiple Choices" anchor="status.300"> |
---|
| 1293 | <iref primary="true" item="300 Multiple Choices (status code)" x:for-anchor=""/> |
---|
| 1294 | <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/> |
---|
| 1295 | <t> |
---|
| 1296 | The requested resource corresponds to any one of a set of |
---|
| 1297 | representations, each with its own specific location, and agent-driven |
---|
[29] | 1298 | negotiation information (&content-negotiation;) is being provided so that |
---|
[8] | 1299 | the user (or user agent) can select a preferred representation and |
---|
| 1300 | redirect its request to that location. |
---|
| 1301 | </t> |
---|
| 1302 | <t> |
---|
| 1303 | Unless it was a HEAD request, the response &SHOULD; include an entity |
---|
| 1304 | containing a list of resource characteristics and location(s) from |
---|
| 1305 | which the user or user agent can choose the one most appropriate. The |
---|
| 1306 | entity format is specified by the media type given in the Content-Type |
---|
| 1307 | header field. Depending upon the format and the capabilities of |
---|
| 1308 | the user agent, selection of the most appropriate choice &MAY; be |
---|
| 1309 | performed automatically. However, this specification does not define |
---|
| 1310 | any standard for such automatic selection. |
---|
| 1311 | </t> |
---|
| 1312 | <t> |
---|
| 1313 | If the server has a preferred choice of representation, it &SHOULD; |
---|
| 1314 | include the specific URI for that representation in the Location |
---|
| 1315 | field; user agents &MAY; use the Location field value for automatic |
---|
| 1316 | redirection. This response is cacheable unless indicated otherwise. |
---|
| 1317 | </t> |
---|
| 1318 | </section> |
---|
| 1319 | |
---|
| 1320 | <section title="301 Moved Permanently" anchor="status.301"> |
---|
| 1321 | <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/> |
---|
| 1322 | <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/> |
---|
| 1323 | <t> |
---|
| 1324 | The requested resource has been assigned a new permanent URI and any |
---|
| 1325 | future references to this resource &SHOULD; use one of the returned |
---|
| 1326 | URIs. Clients with link editing capabilities ought to automatically |
---|
[391] | 1327 | re-link references to the request-target to one or more of the new |
---|
[8] | 1328 | references returned by the server, where possible. This response is |
---|
| 1329 | cacheable unless indicated otherwise. |
---|
| 1330 | </t> |
---|
| 1331 | <t> |
---|
| 1332 | The new permanent URI &SHOULD; be given by the Location field in the |
---|
| 1333 | response. Unless the request method was HEAD, the entity of the |
---|
| 1334 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
| 1335 | the new URI(s). |
---|
| 1336 | </t> |
---|
| 1337 | <t> |
---|
[88] | 1338 | If the 301 status code is received in response to a request method |
---|
| 1339 | that is known to be "safe", as defined in <xref target="safe.methods"/>, |
---|
[96] | 1340 | then the request &MAY; be automatically redirected by the user agent without |
---|
[88] | 1341 | confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the |
---|
[8] | 1342 | request unless it can be confirmed by the user, since this might |
---|
| 1343 | change the conditions under which the request was issued. |
---|
| 1344 | </t> |
---|
[563] | 1345 | <x:note> |
---|
| 1346 | <t> |
---|
| 1347 | <x:h>Note:</x:h> When automatically redirecting a POST request after |
---|
| 1348 | receiving a 301 status code, some existing HTTP/1.0 user agents |
---|
| 1349 | will erroneously change it into a GET request. |
---|
| 1350 | </t> |
---|
| 1351 | </x:note> |
---|
[8] | 1352 | </section> |
---|
| 1353 | |
---|
| 1354 | <section title="302 Found" anchor="status.302"> |
---|
| 1355 | <iref primary="true" item="302 Found (status code)" x:for-anchor=""/> |
---|
| 1356 | <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/> |
---|
| 1357 | <t> |
---|
| 1358 | The requested resource resides temporarily under a different URI. |
---|
| 1359 | Since the redirection might be altered on occasion, the client &SHOULD; |
---|
[391] | 1360 | continue to use the request-target for future requests. This response |
---|
[8] | 1361 | is only cacheable if indicated by a Cache-Control or Expires header |
---|
| 1362 | field. |
---|
| 1363 | </t> |
---|
| 1364 | <t> |
---|
| 1365 | The temporary URI &SHOULD; be given by the Location field in the |
---|
| 1366 | response. Unless the request method was HEAD, the entity of the |
---|
| 1367 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
| 1368 | the new URI(s). |
---|
| 1369 | </t> |
---|
| 1370 | <t> |
---|
[88] | 1371 | If the 302 status code is received in response to a request method |
---|
| 1372 | that is known to be "safe", as defined in <xref target="safe.methods"/>, |
---|
[96] | 1373 | then the request &MAY; be automatically redirected by the user agent without |
---|
[88] | 1374 | confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the |
---|
[8] | 1375 | request unless it can be confirmed by the user, since this might |
---|
| 1376 | change the conditions under which the request was issued. |
---|
| 1377 | </t> |
---|
[563] | 1378 | <x:note> |
---|
| 1379 | <t> |
---|
[614] | 1380 | <x:h>Note:</x:h> HTTP/1.0 (<xref target="RFC1945" x:fmt="," x:sec="9.3"/>) |
---|
| 1381 | and the first version of HTTP/1.1 (<xref target="RFC2068" x:fmt="," x:sec ="10.3.3"/>) |
---|
| 1382 | specify that the client is not allowed to change the method on the |
---|
| 1383 | redirected request. However, most existing user agent implementations |
---|
| 1384 | treat 302 as if it were a 303 response, performing a GET on the Location |
---|
| 1385 | field-value regardless of the original request method. Therefore, a |
---|
| 1386 | previous version of this specification |
---|
| 1387 | (<xref target="RFC2616" x:fmt="," x:sec="10.3.3"/>) has added the |
---|
| 1388 | status codes |
---|
| 1389 | <xref target="status.303" format="none">303</xref> and |
---|
| 1390 | <xref target="status.307" format="none">307</xref> for servers that wish |
---|
| 1391 | to make unambiguously clear which kind of reaction is expected of the |
---|
| 1392 | client. |
---|
[563] | 1393 | </t> |
---|
| 1394 | </x:note> |
---|
[8] | 1395 | </section> |
---|
| 1396 | |
---|
| 1397 | <section title="303 See Other" anchor="status.303"> |
---|
| 1398 | <iref primary="true" item="303 See Other (status code)" x:for-anchor=""/> |
---|
| 1399 | <iref primary="true" item="Status Codes" subitem="303 See Other" x:for-anchor=""/> |
---|
| 1400 | <t> |
---|
[242] | 1401 | The server directs the user agent to a different resource, indicated |
---|
| 1402 | by a URI in the Location header field, that provides an indirect |
---|
| 1403 | response to the original request. The user agent &MAY; perform a GET |
---|
| 1404 | request on the URI in the Location field in order to obtain a |
---|
| 1405 | representation corresponding to the response, be redirected again, |
---|
| 1406 | or end with an error status. The Location URI is not a substitute |
---|
| 1407 | reference for the originally requested resource. |
---|
[8] | 1408 | </t> |
---|
| 1409 | <t> |
---|
[242] | 1410 | The 303 status is generally applicable to any HTTP method. It is |
---|
| 1411 | primarily used to allow the output of a POST action to redirect |
---|
| 1412 | the user agent to a selected resource, since doing so provides the |
---|
| 1413 | information corresponding to the POST response in a form that |
---|
| 1414 | can be separately identified, bookmarked, and cached independent |
---|
| 1415 | of the original request. |
---|
[8] | 1416 | </t> |
---|
[242] | 1417 | <t> |
---|
| 1418 | A 303 response to a GET request indicates that the requested |
---|
| 1419 | resource does not have a representation of its own that can be |
---|
| 1420 | transferred by the server over HTTP. The Location URI indicates a |
---|
| 1421 | resource that is descriptive of the requested resource such that |
---|
| 1422 | the follow-on representation may be useful without implying that |
---|
[243] | 1423 | it adequately represents the previously requested resource. |
---|
[242] | 1424 | Note that answers to the questions of what can be represented, what |
---|
| 1425 | representations are adequate, and what might be a useful description |
---|
| 1426 | are outside the scope of HTTP and thus entirely determined by the |
---|
[602] | 1427 | URI owner(s). |
---|
[242] | 1428 | </t> |
---|
| 1429 | <t> |
---|
| 1430 | A 303 response &SHOULD-NOT; be cached unless it is indicated as |
---|
| 1431 | cacheable by Cache-Control or Expires header fields. Except for |
---|
| 1432 | responses to a HEAD request, the entity of a 303 response &SHOULD; |
---|
| 1433 | contain a short hypertext note with a hyperlink to the Location URI. |
---|
| 1434 | </t> |
---|
[8] | 1435 | </section> |
---|
| 1436 | |
---|
| 1437 | <section title="304 Not Modified" anchor="status.304"> |
---|
| 1438 | <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/> |
---|
| 1439 | <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/> |
---|
[700] | 1440 | <rdf:Description> |
---|
| 1441 | <redirects-to xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">Part4</redirects-to> |
---|
| 1442 | </rdf:Description> |
---|
[8] | 1443 | <t> |
---|
[45] | 1444 | The response to the request has not been modified since the conditions |
---|
[700] | 1445 | indicated by the client's conditional GET request, as defined in &status-304;. |
---|
[8] | 1446 | </t> |
---|
| 1447 | </section> |
---|
| 1448 | |
---|
| 1449 | <section title="305 Use Proxy" anchor="status.305"> |
---|
| 1450 | <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/> |
---|
| 1451 | <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/> |
---|
| 1452 | <t> |
---|
[235] | 1453 | The 305 status was defined in a previous version of this specification |
---|
| 1454 | (see <xref target="changes.from.rfc.2616"/>), and is now deprecated. |
---|
[8] | 1455 | </t> |
---|
| 1456 | </section> |
---|
| 1457 | |
---|
| 1458 | <section title="306 (Unused)" anchor="status.306"> |
---|
| 1459 | <iref primary="true" item="306 (Unused) (status code)" x:for-anchor=""/> |
---|
| 1460 | <iref primary="true" item="Status Codes" subitem="306 (Unused)" x:for-anchor=""/> |
---|
| 1461 | <t> |
---|
| 1462 | The 306 status code was used in a previous version of the |
---|
| 1463 | specification, is no longer used, and the code is reserved. |
---|
| 1464 | </t> |
---|
| 1465 | </section> |
---|
| 1466 | |
---|
| 1467 | <section title="307 Temporary Redirect" anchor="status.307"> |
---|
| 1468 | <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/> |
---|
| 1469 | <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/> |
---|
| 1470 | <t> |
---|
| 1471 | The requested resource resides temporarily under a different URI. |
---|
| 1472 | Since the redirection &MAY; be altered on occasion, the client &SHOULD; |
---|
[391] | 1473 | continue to use the request-target for future requests. This response |
---|
[8] | 1474 | is only cacheable if indicated by a Cache-Control or Expires header |
---|
| 1475 | field. |
---|
| 1476 | </t> |
---|
| 1477 | <t> |
---|
| 1478 | The temporary URI &SHOULD; be given by the Location field in the |
---|
| 1479 | response. Unless the request method was HEAD, the entity of the |
---|
| 1480 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
| 1481 | the new URI(s) , since many pre-HTTP/1.1 user agents do not |
---|
| 1482 | understand the 307 status. Therefore, the note &SHOULD; contain the |
---|
| 1483 | information necessary for a user to repeat the original request on |
---|
| 1484 | the new URI. |
---|
| 1485 | </t> |
---|
| 1486 | <t> |
---|
[88] | 1487 | If the 307 status code is received in response to a request method |
---|
| 1488 | that is known to be "safe", as defined in <xref target="safe.methods"/>, |
---|
[96] | 1489 | then the request &MAY; be automatically redirected by the user agent without |
---|
[88] | 1490 | confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the |
---|
[8] | 1491 | request unless it can be confirmed by the user, since this might |
---|
| 1492 | change the conditions under which the request was issued. |
---|
| 1493 | </t> |
---|
| 1494 | </section> |
---|
| 1495 | </section> |
---|
| 1496 | |
---|
| 1497 | <section title="Client Error 4xx" anchor="status.4xx"> |
---|
| 1498 | <t> |
---|
| 1499 | The 4xx class of status code is intended for cases in which the |
---|
| 1500 | client seems to have erred. Except when responding to a HEAD request, |
---|
| 1501 | the server &SHOULD; include an entity containing an explanation of the |
---|
| 1502 | error situation, and whether it is a temporary or permanent |
---|
| 1503 | condition. These status codes are applicable to any request method. |
---|
| 1504 | User agents &SHOULD; display any included entity to the user. |
---|
| 1505 | </t> |
---|
| 1506 | <t> |
---|
| 1507 | If the client is sending data, a server implementation using TCP |
---|
| 1508 | &SHOULD; be careful to ensure that the client acknowledges receipt of |
---|
| 1509 | the packet(s) containing the response, before the server closes the |
---|
| 1510 | input connection. If the client continues sending data to the server |
---|
| 1511 | after the close, the server's TCP stack will send a reset packet to |
---|
| 1512 | the client, which may erase the client's unacknowledged input buffers |
---|
| 1513 | before they can be read and interpreted by the HTTP application. |
---|
| 1514 | </t> |
---|
| 1515 | |
---|
| 1516 | <section title="400 Bad Request" anchor="status.400"> |
---|
| 1517 | <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/> |
---|
| 1518 | <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/> |
---|
| 1519 | <t> |
---|
| 1520 | The request could not be understood by the server due to malformed |
---|
| 1521 | syntax. The client &SHOULD-NOT; repeat the request without |
---|
| 1522 | modifications. |
---|
| 1523 | </t> |
---|
| 1524 | </section> |
---|
| 1525 | |
---|
| 1526 | <section title="401 Unauthorized" anchor="status.401"> |
---|
| 1527 | <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/> |
---|
| 1528 | <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/> |
---|
[700] | 1529 | <rdf:Description> |
---|
| 1530 | <redirects-to xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">Part7</redirects-to> |
---|
| 1531 | </rdf:Description> |
---|
[8] | 1532 | <t> |
---|
[700] | 1533 | The request requires user authentication (see &status-401;). |
---|
[8] | 1534 | </t> |
---|
| 1535 | </section> |
---|
| 1536 | |
---|
| 1537 | <section title="402 Payment Required" anchor="status.402"> |
---|
| 1538 | <iref primary="true" item="402 Payment Required (status code)" x:for-anchor=""/> |
---|
| 1539 | <iref primary="true" item="Status Codes" subitem="402 Payment Required" x:for-anchor=""/> |
---|
| 1540 | <t> |
---|
| 1541 | This code is reserved for future use. |
---|
| 1542 | </t> |
---|
| 1543 | </section> |
---|
| 1544 | |
---|
| 1545 | <section title="403 Forbidden" anchor="status.403"> |
---|
| 1546 | <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/> |
---|
| 1547 | <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/> |
---|
| 1548 | <t> |
---|
| 1549 | The server understood the request, but is refusing to fulfill it. |
---|
| 1550 | Authorization will not help and the request &SHOULD-NOT; be repeated. |
---|
| 1551 | If the request method was not HEAD and the server wishes to make |
---|
| 1552 | public why the request has not been fulfilled, it &SHOULD; describe the |
---|
| 1553 | reason for the refusal in the entity. If the server does not wish to |
---|
| 1554 | make this information available to the client, the status code 404 |
---|
| 1555 | (Not Found) can be used instead. |
---|
| 1556 | </t> |
---|
| 1557 | </section> |
---|
| 1558 | |
---|
| 1559 | <section title="404 Not Found" anchor="status.404"> |
---|
| 1560 | <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/> |
---|
| 1561 | <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> |
---|
| 1562 | <t> |
---|
[391] | 1563 | The server has not found anything matching the request-target. No |
---|
[8] | 1564 | indication is given of whether the condition is temporary or |
---|
| 1565 | permanent. The 410 (Gone) status code &SHOULD; be used if the server |
---|
| 1566 | knows, through some internally configurable mechanism, that an old |
---|
| 1567 | resource is permanently unavailable and has no forwarding address. |
---|
| 1568 | This status code is commonly used when the server does not wish to |
---|
| 1569 | reveal exactly why the request has been refused, or when no other |
---|
| 1570 | response is applicable. |
---|
| 1571 | </t> |
---|
| 1572 | </section> |
---|
| 1573 | |
---|
| 1574 | <section title="405 Method Not Allowed" anchor="status.405"> |
---|
| 1575 | <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/> |
---|
| 1576 | <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> |
---|
| 1577 | <t> |
---|
| 1578 | The method specified in the Request-Line is not allowed for the |
---|
[391] | 1579 | resource identified by the request-target. The response &MUST; include an |
---|
[8] | 1580 | Allow header containing a list of valid methods for the requested |
---|
| 1581 | resource. |
---|
| 1582 | </t> |
---|
| 1583 | </section> |
---|
| 1584 | |
---|
| 1585 | <section title="406 Not Acceptable" anchor="status.406"> |
---|
| 1586 | <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/> |
---|
| 1587 | <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/> |
---|
| 1588 | <t> |
---|
| 1589 | The resource identified by the request is only capable of generating |
---|
| 1590 | response entities which have content characteristics not acceptable |
---|
| 1591 | according to the accept headers sent in the request. |
---|
| 1592 | </t> |
---|
| 1593 | <t> |
---|
| 1594 | Unless it was a HEAD request, the response &SHOULD; include an entity |
---|
| 1595 | containing a list of available entity characteristics and location(s) |
---|
| 1596 | from which the user or user agent can choose the one most |
---|
| 1597 | appropriate. The entity format is specified by the media type given |
---|
| 1598 | in the Content-Type header field. Depending upon the format and the |
---|
| 1599 | capabilities of the user agent, selection of the most appropriate |
---|
| 1600 | choice &MAY; be performed automatically. However, this specification |
---|
| 1601 | does not define any standard for such automatic selection. |
---|
| 1602 | </t> |
---|
[563] | 1603 | <x:note> |
---|
| 1604 | <t> |
---|
| 1605 | <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are |
---|
| 1606 | not acceptable according to the accept headers sent in the |
---|
| 1607 | request. In some cases, this may even be preferable to sending a |
---|
| 1608 | 406 response. User agents are encouraged to inspect the headers of |
---|
| 1609 | an incoming response to determine if it is acceptable. |
---|
| 1610 | </t> |
---|
| 1611 | </x:note> |
---|
[8] | 1612 | <t> |
---|
| 1613 | If the response could be unacceptable, a user agent &SHOULD; |
---|
| 1614 | temporarily stop receipt of more data and query the user for a |
---|
| 1615 | decision on further actions. |
---|
| 1616 | </t> |
---|
| 1617 | </section> |
---|
| 1618 | |
---|
| 1619 | <section title="407 Proxy Authentication Required" anchor="status.407"> |
---|
| 1620 | <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/> |
---|
| 1621 | <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/> |
---|
| 1622 | <t> |
---|
| 1623 | This code is similar to 401 (Unauthorized), but indicates that the |
---|
[700] | 1624 | client must first authenticate itself with the proxy (see &status-407;). |
---|
[8] | 1625 | </t> |
---|
| 1626 | </section> |
---|
| 1627 | |
---|
| 1628 | <section title="408 Request Timeout" anchor="status.408"> |
---|
| 1629 | <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/> |
---|
| 1630 | <iref primary="true" item="Status Codes" subitem="408 Request Timeout" x:for-anchor=""/> |
---|
| 1631 | <t> |
---|
| 1632 | The client did not produce a request within the time that the server |
---|
| 1633 | was prepared to wait. The client &MAY; repeat the request without |
---|
| 1634 | modifications at any later time. |
---|
| 1635 | </t> |
---|
| 1636 | </section> |
---|
| 1637 | |
---|
| 1638 | <section title="409 Conflict" anchor="status.409"> |
---|
| 1639 | <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/> |
---|
| 1640 | <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/> |
---|
| 1641 | <t> |
---|
| 1642 | The request could not be completed due to a conflict with the current |
---|
| 1643 | state of the resource. This code is only allowed in situations where |
---|
| 1644 | it is expected that the user might be able to resolve the conflict |
---|
| 1645 | and resubmit the request. The response body &SHOULD; include enough |
---|
| 1646 | information for the user to recognize the source of the conflict. |
---|
| 1647 | Ideally, the response entity would include enough information for the |
---|
| 1648 | user or user agent to fix the problem; however, that might not be |
---|
| 1649 | possible and is not required. |
---|
| 1650 | </t> |
---|
| 1651 | <t> |
---|
| 1652 | Conflicts are most likely to occur in response to a PUT request. For |
---|
| 1653 | example, if versioning were being used and the entity being PUT |
---|
| 1654 | included changes to a resource which conflict with those made by an |
---|
| 1655 | earlier (third-party) request, the server might use the 409 response |
---|
| 1656 | to indicate that it can't complete the request. In this case, the |
---|
| 1657 | response entity would likely contain a list of the differences |
---|
| 1658 | between the two versions in a format defined by the response |
---|
| 1659 | Content-Type. |
---|
| 1660 | </t> |
---|
| 1661 | </section> |
---|
| 1662 | |
---|
| 1663 | <section title="410 Gone" anchor="status.410"> |
---|
| 1664 | <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/> |
---|
| 1665 | <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/> |
---|
| 1666 | <t> |
---|
| 1667 | The requested resource is no longer available at the server and no |
---|
| 1668 | forwarding address is known. This condition is expected to be |
---|
| 1669 | considered permanent. Clients with link editing capabilities &SHOULD; |
---|
[391] | 1670 | delete references to the request-target after user approval. If the |
---|
[8] | 1671 | server does not know, or has no facility to determine, whether or not |
---|
| 1672 | the condition is permanent, the status code 404 (Not Found) &SHOULD; be |
---|
| 1673 | used instead. This response is cacheable unless indicated otherwise. |
---|
| 1674 | </t> |
---|
| 1675 | <t> |
---|
| 1676 | The 410 response is primarily intended to assist the task of web |
---|
| 1677 | maintenance by notifying the recipient that the resource is |
---|
| 1678 | intentionally unavailable and that the server owners desire that |
---|
| 1679 | remote links to that resource be removed. Such an event is common for |
---|
| 1680 | limited-time, promotional services and for resources belonging to |
---|
| 1681 | individuals no longer working at the server's site. It is not |
---|
| 1682 | necessary to mark all permanently unavailable resources as "gone" or |
---|
| 1683 | to keep the mark for any length of time -- that is left to the |
---|
| 1684 | discretion of the server owner. |
---|
| 1685 | </t> |
---|
| 1686 | </section> |
---|
| 1687 | |
---|
| 1688 | <section title="411 Length Required" anchor="status.411"> |
---|
| 1689 | <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/> |
---|
| 1690 | <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/> |
---|
| 1691 | <t> |
---|
| 1692 | The server refuses to accept the request without a defined Content-Length. |
---|
| 1693 | The client &MAY; repeat the request if it adds a valid |
---|
| 1694 | Content-Length header field containing the length of the message-body |
---|
| 1695 | in the request message. |
---|
| 1696 | </t> |
---|
| 1697 | </section> |
---|
| 1698 | |
---|
| 1699 | <section title="412 Precondition Failed" anchor="status.412"> |
---|
| 1700 | <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/> |
---|
| 1701 | <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/> |
---|
[700] | 1702 | <rdf:Description> |
---|
| 1703 | <redirects-to xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">Part4</redirects-to> |
---|
| 1704 | </rdf:Description> |
---|
[8] | 1705 | <t> |
---|
| 1706 | The precondition given in one or more of the request-header fields |
---|
[45] | 1707 | evaluated to false when it was tested on the server, as defined in |
---|
[700] | 1708 | &status-412;. |
---|
[8] | 1709 | </t> |
---|
| 1710 | </section> |
---|
| 1711 | |
---|
| 1712 | <section title="413 Request Entity Too Large" anchor="status.413"> |
---|
| 1713 | <iref primary="true" item="413 Request Entity Too Large (status code)" x:for-anchor=""/> |
---|
| 1714 | <iref primary="true" item="Status Codes" subitem="413 Request Entity Too Large" x:for-anchor=""/> |
---|
| 1715 | <t> |
---|
| 1716 | The server is refusing to process a request because the request |
---|
| 1717 | entity is larger than the server is willing or able to process. The |
---|
| 1718 | server &MAY; close the connection to prevent the client from continuing |
---|
| 1719 | the request. |
---|
| 1720 | </t> |
---|
| 1721 | <t> |
---|
| 1722 | If the condition is temporary, the server &SHOULD; include a Retry-After |
---|
| 1723 | header field to indicate that it is temporary and after what |
---|
| 1724 | time the client &MAY; try again. |
---|
| 1725 | </t> |
---|
| 1726 | </section> |
---|
| 1727 | |
---|
[465] | 1728 | <section title="414 URI Too Long" anchor="status.414"> |
---|
| 1729 | <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/> |
---|
| 1730 | <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> |
---|
[8] | 1731 | <t> |
---|
[391] | 1732 | The server is refusing to service the request because the request-target |
---|
[8] | 1733 | is longer than the server is willing to interpret. This rare |
---|
| 1734 | condition is only likely to occur when a client has improperly |
---|
| 1735 | converted a POST request to a GET request with long query |
---|
| 1736 | information, when the client has descended into a URI "black hole" of |
---|
| 1737 | redirection (e.g., a redirected URI prefix that points to a suffix of |
---|
| 1738 | itself), or when the server is under attack by a client attempting to |
---|
| 1739 | exploit security holes present in some servers using fixed-length |
---|
[391] | 1740 | buffers for reading or manipulating the request-target. |
---|
[8] | 1741 | </t> |
---|
| 1742 | </section> |
---|
| 1743 | |
---|
| 1744 | <section title="415 Unsupported Media Type" anchor="status.415"> |
---|
| 1745 | <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/> |
---|
| 1746 | <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/> |
---|
| 1747 | <t> |
---|
| 1748 | The server is refusing to service the request because the entity of |
---|
| 1749 | the request is in a format not supported by the requested resource |
---|
| 1750 | for the requested method. |
---|
| 1751 | </t> |
---|
| 1752 | </section> |
---|
| 1753 | |
---|
| 1754 | <section title="416 Requested Range Not Satisfiable" anchor="status.416"> |
---|
| 1755 | <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/> |
---|
| 1756 | <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/> |
---|
[700] | 1757 | <rdf:Description> |
---|
| 1758 | <redirects-to xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">Part5</redirects-to> |
---|
| 1759 | </rdf:Description> |
---|
[8] | 1760 | <t> |
---|
[29] | 1761 | The request included a Range request-header field (&header-range;) and none of |
---|
[8] | 1762 | the range-specifier values in this field overlap the current extent |
---|
[700] | 1763 | of the selected resource. See &status-416; |
---|
[8] | 1764 | </t> |
---|
| 1765 | </section> |
---|
| 1766 | |
---|
| 1767 | <section title="417 Expectation Failed" anchor="status.417"> |
---|
| 1768 | <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/> |
---|
| 1769 | <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/> |
---|
| 1770 | <t> |
---|
| 1771 | The expectation given in an Expect request-header field (see <xref target="header.expect"/>) |
---|
| 1772 | could not be met by this server, or, if the server is a proxy, |
---|
| 1773 | the server has unambiguous evidence that the request could not be met |
---|
| 1774 | by the next-hop server. |
---|
| 1775 | </t> |
---|
| 1776 | </section> |
---|
| 1777 | </section> |
---|
| 1778 | |
---|
| 1779 | <section title="Server Error 5xx" anchor="status.5xx"> |
---|
| 1780 | <t> |
---|
| 1781 | Response status codes beginning with the digit "5" indicate cases in |
---|
| 1782 | which the server is aware that it has erred or is incapable of |
---|
| 1783 | performing the request. Except when responding to a HEAD request, the |
---|
| 1784 | server &SHOULD; include an entity containing an explanation of the |
---|
| 1785 | error situation, and whether it is a temporary or permanent |
---|
| 1786 | condition. User agents &SHOULD; display any included entity to the |
---|
| 1787 | user. These response codes are applicable to any request method. |
---|
| 1788 | </t> |
---|
| 1789 | |
---|
| 1790 | <section title="500 Internal Server Error" anchor="status.500"> |
---|
| 1791 | <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/> |
---|
| 1792 | <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/> |
---|
| 1793 | <t> |
---|
| 1794 | The server encountered an unexpected condition which prevented it |
---|
| 1795 | from fulfilling the request. |
---|
| 1796 | </t> |
---|
| 1797 | </section> |
---|
| 1798 | |
---|
| 1799 | <section title="501 Not Implemented" anchor="status.501"> |
---|
| 1800 | <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/> |
---|
| 1801 | <iref primary="true" item="Status Codes" subitem="501 Not Implemented" x:for-anchor=""/> |
---|
| 1802 | <t> |
---|
| 1803 | The server does not support the functionality required to fulfill the |
---|
| 1804 | request. This is the appropriate response when the server does not |
---|
| 1805 | recognize the request method and is not capable of supporting it for |
---|
| 1806 | any resource. |
---|
| 1807 | </t> |
---|
| 1808 | </section> |
---|
| 1809 | |
---|
| 1810 | <section title="502 Bad Gateway" anchor="status.502"> |
---|
| 1811 | <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/> |
---|
| 1812 | <iref primary="true" item="Status Codes" subitem="502 Bad Gateway" x:for-anchor=""/> |
---|
| 1813 | <t> |
---|
| 1814 | The server, while acting as a gateway or proxy, received an invalid |
---|
| 1815 | response from the upstream server it accessed in attempting to |
---|
| 1816 | fulfill the request. |
---|
| 1817 | </t> |
---|
| 1818 | </section> |
---|
| 1819 | |
---|
| 1820 | <section title="503 Service Unavailable" anchor="status.503"> |
---|
| 1821 | <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/> |
---|
| 1822 | <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/> |
---|
| 1823 | <t> |
---|
| 1824 | The server is currently unable to handle the request due to a |
---|
| 1825 | temporary overloading or maintenance of the server. The implication |
---|
| 1826 | is that this is a temporary condition which will be alleviated after |
---|
| 1827 | some delay. If known, the length of the delay &MAY; be indicated in a |
---|
| 1828 | Retry-After header. If no Retry-After is given, the client &SHOULD; |
---|
| 1829 | handle the response as it would for a 500 response. |
---|
| 1830 | </t> |
---|
[563] | 1831 | <x:note> |
---|
| 1832 | <t> |
---|
| 1833 | <x:h>Note:</x:h> The existence of the 503 status code does not imply that a |
---|
| 1834 | server must use it when becoming overloaded. Some servers may wish |
---|
| 1835 | to simply refuse the connection. |
---|
| 1836 | </t> |
---|
| 1837 | </x:note> |
---|
[8] | 1838 | </section> |
---|
| 1839 | |
---|
| 1840 | <section title="504 Gateway Timeout" anchor="status.504"> |
---|
| 1841 | <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/> |
---|
| 1842 | <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout" x:for-anchor=""/> |
---|
| 1843 | <t> |
---|
| 1844 | The server, while acting as a gateway or proxy, did not receive a |
---|
| 1845 | timely response from the upstream server specified by the URI (e.g. |
---|
| 1846 | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |
---|
| 1847 | to access in attempting to complete the request. |
---|
| 1848 | </t> |
---|
[563] | 1849 | <x:note> |
---|
| 1850 | <t> |
---|
| 1851 | <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to |
---|
| 1852 | return 400 or 500 when DNS lookups time out. |
---|
| 1853 | </t> |
---|
| 1854 | </x:note> |
---|
[8] | 1855 | </section> |
---|
| 1856 | |
---|
| 1857 | <section title="505 HTTP Version Not Supported" anchor="status.505"> |
---|
| 1858 | <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/> |
---|
| 1859 | <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/> |
---|
| 1860 | <t> |
---|
[172] | 1861 | The server does not support, or refuses to support, the protocol |
---|
[8] | 1862 | version that was used in the request message. The server is |
---|
| 1863 | indicating that it is unable or unwilling to complete the request |
---|
[29] | 1864 | using the same major version as the client, as described in &http-version;, |
---|
[8] | 1865 | other than with this error message. The response &SHOULD; contain |
---|
| 1866 | an entity describing why that version is not supported and what other |
---|
| 1867 | protocols are supported by that server. |
---|
| 1868 | </t> |
---|
| 1869 | |
---|
| 1870 | </section> |
---|
| 1871 | </section> |
---|
| 1872 | </section> |
---|
| 1873 | |
---|
| 1874 | |
---|
| 1875 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
| 1876 | <t> |
---|
[117] | 1877 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
| 1878 | related to request and response semantics. |
---|
[8] | 1879 | </t> |
---|
[117] | 1880 | <t> |
---|
| 1881 | For entity-header fields, both sender and recipient refer to either the |
---|
| 1882 | client or the server, depending on who sends and who receives the entity. |
---|
| 1883 | </t> |
---|
[8] | 1884 | |
---|
| 1885 | <section title="Allow" anchor="header.allow"> |
---|
| 1886 | <iref primary="true" item="Allow header" x:for-anchor=""/> |
---|
| 1887 | <iref primary="true" item="Headers" subitem="Allow" x:for-anchor=""/> |
---|
[229] | 1888 | <x:anchor-alias value="Allow"/> |
---|
[356] | 1889 | <x:anchor-alias value="Allow-v"/> |
---|
[8] | 1890 | <t> |
---|
[697] | 1891 | The "Allow" response-header field lists the set of methods advertised as |
---|
| 1892 | supported by the resource identified by the request-target. The purpose of |
---|
| 1893 | this field is strictly to inform the recipient of valid methods |
---|
[698] | 1894 | associated with the resource. |
---|
[8] | 1895 | </t> |
---|
[356] | 1896 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/> |
---|
[366] | 1897 | <x:ref>Allow</x:ref> = "Allow" ":" <x:ref>OWS</x:ref> <x:ref>Allow-v</x:ref> |
---|
[356] | 1898 | <x:ref>Allow-v</x:ref> = #<x:ref>Method</x:ref> |
---|
[8] | 1899 | </artwork></figure> |
---|
| 1900 | <t> |
---|
| 1901 | Example of use: |
---|
| 1902 | </t> |
---|
| 1903 | <figure><artwork type="example"> |
---|
[356] | 1904 | Allow: GET, HEAD, PUT |
---|
[8] | 1905 | </artwork></figure> |
---|
| 1906 | <t> |
---|
[240] | 1907 | The actual set of allowed methods is defined |
---|
[8] | 1908 | by the origin server at the time of each request. |
---|
| 1909 | </t> |
---|
| 1910 | <t> |
---|
| 1911 | A proxy &MUST-NOT; modify the Allow header field even if it does not |
---|
| 1912 | understand all the methods specified, since the user agent might |
---|
| 1913 | have other means of communicating with the origin server. |
---|
| 1914 | </t> |
---|
| 1915 | </section> |
---|
| 1916 | |
---|
| 1917 | <section title="Expect" anchor="header.expect"> |
---|
| 1918 | <iref primary="true" item="Expect header" x:for-anchor=""/> |
---|
| 1919 | <iref primary="true" item="Headers" subitem="Expect" x:for-anchor=""/> |
---|
[229] | 1920 | <x:anchor-alias value="Expect"/> |
---|
[356] | 1921 | <x:anchor-alias value="Expect-v"/> |
---|
[229] | 1922 | <x:anchor-alias value="expectation"/> |
---|
| 1923 | <x:anchor-alias value="expectation-extension"/> |
---|
| 1924 | <x:anchor-alias value="expect-params"/> |
---|
[8] | 1925 | <t> |
---|
[697] | 1926 | The "Expect" request-header field is used to indicate that particular |
---|
[8] | 1927 | server behaviors are required by the client. |
---|
| 1928 | </t> |
---|
[356] | 1929 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="Expect-v"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expectation-extension"/><iref primary="true" item="Grammar" subitem="expect-params"/> |
---|
[366] | 1930 | <x:ref>Expect</x:ref> = "Expect" ":" <x:ref>OWS</x:ref> <x:ref>Expect-v</x:ref> |
---|
[356] | 1931 | <x:ref>Expect-v</x:ref> = 1#<x:ref>expectation</x:ref> |
---|
[135] | 1932 | |
---|
[356] | 1933 | <x:ref>expectation</x:ref> = "100-continue" / <x:ref>expectation-extension</x:ref> |
---|
| 1934 | <x:ref>expectation-extension</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) |
---|
[229] | 1935 | *<x:ref>expect-params</x:ref> ] |
---|
[356] | 1936 | <x:ref>expect-params</x:ref> = ";" <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ] |
---|
[8] | 1937 | </artwork></figure> |
---|
| 1938 | <t> |
---|
| 1939 | A server that does not understand or is unable to comply with any of |
---|
| 1940 | the expectation values in the Expect field of a request &MUST; respond |
---|
| 1941 | with appropriate error status. The server &MUST; respond with a 417 |
---|
| 1942 | (Expectation Failed) status if any of the expectations cannot be met |
---|
| 1943 | or, if there are other problems with the request, some other 4xx |
---|
| 1944 | status. |
---|
| 1945 | </t> |
---|
| 1946 | <t> |
---|
| 1947 | This header field is defined with extensible syntax to allow for |
---|
| 1948 | future extensions. If a server receives a request containing an |
---|
| 1949 | Expect field that includes an expectation-extension that it does not |
---|
| 1950 | support, it &MUST; respond with a 417 (Expectation Failed) status. |
---|
| 1951 | </t> |
---|
| 1952 | <t> |
---|
| 1953 | Comparison of expectation values is case-insensitive for unquoted |
---|
| 1954 | tokens (including the 100-continue token), and is case-sensitive for |
---|
| 1955 | quoted-string expectation-extensions. |
---|
| 1956 | </t> |
---|
| 1957 | <t> |
---|
| 1958 | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy &MUST; |
---|
| 1959 | return a 417 (Expectation Failed) status if it receives a request |
---|
| 1960 | with an expectation that it cannot meet. However, the Expect |
---|
| 1961 | request-header itself is end-to-end; it &MUST; be forwarded if the |
---|
| 1962 | request is forwarded. |
---|
| 1963 | </t> |
---|
| 1964 | <t> |
---|
| 1965 | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
---|
| 1966 | Expect header. |
---|
| 1967 | </t> |
---|
| 1968 | <t> |
---|
[137] | 1969 | See &use100; for the use of the 100 (Continue) status. |
---|
[8] | 1970 | </t> |
---|
| 1971 | </section> |
---|
| 1972 | |
---|
| 1973 | <section title="From" anchor="header.from"> |
---|
| 1974 | <iref primary="true" item="From header" x:for-anchor=""/> |
---|
| 1975 | <iref primary="true" item="Headers" subitem="From" x:for-anchor=""/> |
---|
[229] | 1976 | <x:anchor-alias value="From"/> |
---|
[356] | 1977 | <x:anchor-alias value="From-v"/> |
---|
[229] | 1978 | <x:anchor-alias value="mailbox"/> |
---|
[8] | 1979 | <t> |
---|
[697] | 1980 | The "From" request-header field, if given, &SHOULD; contain an Internet |
---|
[8] | 1981 | e-mail address for the human user who controls the requesting user |
---|
| 1982 | agent. The address &SHOULD; be machine-usable, as defined by "mailbox" |
---|
[327] | 1983 | in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>: |
---|
[8] | 1984 | </t> |
---|
[356] | 1985 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/><iref primary="true" item="Grammar" subitem="From-v"/> |
---|
[366] | 1986 | <x:ref>From</x:ref> = "From" ":" <x:ref>OWS</x:ref> <x:ref>From-v</x:ref> |
---|
[356] | 1987 | <x:ref>From-v</x:ref> = <x:ref>mailbox</x:ref> |
---|
[206] | 1988 | |
---|
[327] | 1989 | <x:ref>mailbox</x:ref> = <mailbox, defined in <xref x:sec="3.4" x:fmt="," target="RFC5322"/>> |
---|
[8] | 1990 | </artwork></figure> |
---|
| 1991 | <t> |
---|
| 1992 | An example is: |
---|
| 1993 | </t> |
---|
| 1994 | <figure><artwork type="example"> |
---|
[356] | 1995 | From: webmaster@example.org |
---|
[8] | 1996 | </artwork></figure> |
---|
| 1997 | <t> |
---|
| 1998 | This header field &MAY; be used for logging purposes and as a means for |
---|
| 1999 | identifying the source of invalid or unwanted requests. It &SHOULD-NOT; |
---|
| 2000 | be used as an insecure form of access protection. The interpretation |
---|
| 2001 | of this field is that the request is being performed on behalf of the |
---|
| 2002 | person given, who accepts responsibility for the method performed. In |
---|
| 2003 | particular, robot agents &SHOULD; include this header so that the |
---|
| 2004 | person responsible for running the robot can be contacted if problems |
---|
| 2005 | occur on the receiving end. |
---|
| 2006 | </t> |
---|
| 2007 | <t> |
---|
| 2008 | The Internet e-mail address in this field &MAY; be separate from the |
---|
| 2009 | Internet host which issued the request. For example, when a request |
---|
| 2010 | is passed through a proxy the original issuer's address &SHOULD; be |
---|
| 2011 | used. |
---|
| 2012 | </t> |
---|
| 2013 | <t> |
---|
| 2014 | The client &SHOULD-NOT; send the From header field without the user's |
---|
| 2015 | approval, as it might conflict with the user's privacy interests or |
---|
| 2016 | their site's security policy. It is strongly recommended that the |
---|
| 2017 | user be able to disable, enable, and modify the value of this field |
---|
| 2018 | at any time prior to a request. |
---|
| 2019 | </t> |
---|
| 2020 | </section> |
---|
| 2021 | |
---|
| 2022 | <section title="Location" anchor="header.location"> |
---|
| 2023 | <iref primary="true" item="Location header" x:for-anchor=""/> |
---|
| 2024 | <iref primary="true" item="Headers" subitem="Location" x:for-anchor=""/> |
---|
[229] | 2025 | <x:anchor-alias value="Location"/> |
---|
[356] | 2026 | <x:anchor-alias value="Location-v"/> |
---|
[8] | 2027 | <t> |
---|
[698] | 2028 | The "Location" response-header field is used to identify a newly created |
---|
| 2029 | resource, or to redirect the recipient to a different location for |
---|
| 2030 | completion of the request. |
---|
[8] | 2031 | </t> |
---|
[698] | 2032 | <t> |
---|
| 2033 | For 201 (Created) responses, the Location is the URI of the new resource |
---|
| 2034 | which was created by the request. For 3xx responses, the location &SHOULD; |
---|
| 2035 | indicate the server's preferred URI for automatic redirection to the |
---|
| 2036 | resource. |
---|
| 2037 | </t> |
---|
| 2038 | <t> |
---|
| 2039 | The field value consists of a single URI. |
---|
| 2040 | </t> |
---|
[356] | 2041 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/><iref primary="true" item="Grammar" subitem="Location-v"/> |
---|
[366] | 2042 | <x:ref>Location</x:ref> = "Location" ":" <x:ref>OWS</x:ref> <x:ref>Location-v</x:ref> |
---|
[632] | 2043 | <x:ref>Location-v</x:ref> = <x:ref>URI</x:ref> |
---|
[8] | 2044 | </artwork></figure> |
---|
| 2045 | <t> |
---|
| 2046 | An example is: |
---|
| 2047 | </t> |
---|
| 2048 | <figure><artwork type="example"> |
---|
[356] | 2049 | Location: http://www.example.org/pub/WWW/People.html |
---|
[8] | 2050 | </artwork></figure> |
---|
[659] | 2051 | <t> |
---|
| 2052 | There are circumstances in which a fragment identifier in a Location URI would not be appropriate: |
---|
| 2053 | <list style="symbols"> |
---|
| 2054 | <t>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</t> |
---|
| 2055 | <t>With 305 Use Proxy.</t> |
---|
| 2056 | </list> |
---|
| 2057 | </t> |
---|
[563] | 2058 | <x:note> |
---|
| 2059 | <t> |
---|
| 2060 | <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs |
---|
| 2061 | from Location in that the Content-Location identifies the original |
---|
| 2062 | location of the entity enclosed in the response. It is therefore |
---|
| 2063 | possible for a response to contain header fields for both Location |
---|
| 2064 | and Content-Location. |
---|
| 2065 | </t> |
---|
| 2066 | </x:note> |
---|
[8] | 2067 | </section> |
---|
| 2068 | |
---|
| 2069 | <section title="Max-Forwards" anchor="header.max-forwards"> |
---|
| 2070 | <iref primary="true" item="Max-Forwards header" x:for-anchor=""/> |
---|
| 2071 | <iref primary="true" item="Headers" subitem="Max-Forwards" x:for-anchor=""/> |
---|
[229] | 2072 | <x:anchor-alias value="Max-Forwards"/> |
---|
[356] | 2073 | <x:anchor-alias value="Max-Forwards-v"/> |
---|
[8] | 2074 | <t> |
---|
[697] | 2075 | The "Max-Forwards" request-header field provides a mechanism with the |
---|
[698] | 2076 | TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) |
---|
| 2077 | methods to limit the number of times that the request is forwarded by |
---|
| 2078 | proxies or gateways. This can be useful when the client is attempting to |
---|
| 2079 | trace a request which appears to be failing or looping in mid-chain. |
---|
[8] | 2080 | </t> |
---|
[356] | 2081 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/><iref primary="true" item="Grammar" subitem="Max-Forwards-v"/> |
---|
[366] | 2082 | <x:ref>Max-Forwards</x:ref> = "Max-Forwards" ":" <x:ref>OWS</x:ref> <x:ref>Max-Forwards-v</x:ref> |
---|
[356] | 2083 | <x:ref>Max-Forwards-v</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
[8] | 2084 | </artwork></figure> |
---|
| 2085 | <t> |
---|
| 2086 | The Max-Forwards value is a decimal integer indicating the remaining |
---|
| 2087 | number of times this request message may be forwarded. |
---|
| 2088 | </t> |
---|
| 2089 | <t> |
---|
| 2090 | Each proxy or gateway recipient of a TRACE or OPTIONS request |
---|
| 2091 | containing a Max-Forwards header field &MUST; check and update its |
---|
| 2092 | value prior to forwarding the request. If the received value is zero |
---|
| 2093 | (0), the recipient &MUST-NOT; forward the request; instead, it &MUST; |
---|
| 2094 | respond as the final recipient. If the received Max-Forwards value is |
---|
| 2095 | greater than zero, then the forwarded message &MUST; contain an updated |
---|
| 2096 | Max-Forwards field with a value decremented by one (1). |
---|
| 2097 | </t> |
---|
| 2098 | <t> |
---|
| 2099 | The Max-Forwards header field &MAY; be ignored for all other methods |
---|
| 2100 | defined by this specification and for any extension methods for which |
---|
| 2101 | it is not explicitly referred to as part of that method definition. |
---|
| 2102 | </t> |
---|
| 2103 | </section> |
---|
| 2104 | |
---|
| 2105 | <section title="Referer" anchor="header.referer"> |
---|
| 2106 | <iref primary="true" item="Referer header" x:for-anchor=""/> |
---|
| 2107 | <iref primary="true" item="Headers" subitem="Referer" x:for-anchor=""/> |
---|
[229] | 2108 | <x:anchor-alias value="Referer"/> |
---|
[356] | 2109 | <x:anchor-alias value="Referer-v"/> |
---|
[8] | 2110 | <t> |
---|
[698] | 2111 | The "Referer" [sic] request-header field allows the client to specify the |
---|
| 2112 | URI of the resource from which the request-target was obtained (the |
---|
| 2113 | "referrer", although the header field is misspelled.). |
---|
[8] | 2114 | </t> |
---|
[593] | 2115 | <t> |
---|
| 2116 | The Referer header allows servers to generate lists of back-links to |
---|
| 2117 | resources for interest, logging, optimized caching, etc. It also allows |
---|
| 2118 | obsolete or mistyped links to be traced for maintenance. Some servers use |
---|
| 2119 | Referer as a means of controlling where they allow links from (so-called |
---|
| 2120 | "deep linking"), but it should be noted that legitimate requests are not |
---|
| 2121 | required to contain a Referer header field. |
---|
| 2122 | </t> |
---|
| 2123 | <t> |
---|
| 2124 | If the request-target was obtained from a source that does not have its own |
---|
| 2125 | URI (e.g., input from the user keyboard), the Referer field MUST either be |
---|
| 2126 | sent with the value "about:blank", or not be sent at all. Note that this |
---|
| 2127 | requirement does not apply to sources with non-HTTP URIs (e.g., FTP). |
---|
| 2128 | </t> |
---|
[356] | 2129 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/><iref primary="true" item="Grammar" subitem="Referer-v"/> |
---|
[366] | 2130 | <x:ref>Referer</x:ref> = "Referer" ":" <x:ref>OWS</x:ref> <x:ref>Referer-v</x:ref> |
---|
[391] | 2131 | <x:ref>Referer-v</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> |
---|
[8] | 2132 | </artwork></figure> |
---|
| 2133 | <t> |
---|
| 2134 | Example: |
---|
| 2135 | </t> |
---|
| 2136 | <figure><artwork type="example"> |
---|
[356] | 2137 | Referer: http://www.example.org/hypertext/Overview.html |
---|
[8] | 2138 | </artwork></figure> |
---|
| 2139 | <t> |
---|
| 2140 | If the field value is a relative URI, it &SHOULD; be interpreted |
---|
[391] | 2141 | relative to the request-target. The URI &MUST-NOT; include a fragment. See |
---|
[8] | 2142 | <xref target="encoding.sensitive.information.in.uris"/> for security considerations. |
---|
| 2143 | </t> |
---|
| 2144 | </section> |
---|
| 2145 | |
---|
| 2146 | <section title="Retry-After" anchor="header.retry-after"> |
---|
| 2147 | <iref primary="true" item="Retry-After header" x:for-anchor=""/> |
---|
| 2148 | <iref primary="true" item="Headers" subitem="Retry-After" x:for-anchor=""/> |
---|
[229] | 2149 | <x:anchor-alias value="Retry-After"/> |
---|
[356] | 2150 | <x:anchor-alias value="Retry-After-v"/> |
---|
[8] | 2151 | <t> |
---|
[356] | 2152 | The response-header "Retry-After" field can be used with a 503 (Service |
---|
[8] | 2153 | Unavailable) response to indicate how long the service is expected to |
---|
| 2154 | be unavailable to the requesting client. This field &MAY; also be used |
---|
| 2155 | with any 3xx (Redirection) response to indicate the minimum time the |
---|
[698] | 2156 | user-agent is asked wait before issuing the redirected request. |
---|
| 2157 | </t> |
---|
| 2158 | <t> |
---|
| 2159 | The value of this field can be either an HTTP-date or an integer number |
---|
[8] | 2160 | of seconds (in decimal) after the time of the response. |
---|
| 2161 | </t> |
---|
[356] | 2162 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/><iref primary="true" item="Grammar" subitem="Retry-After-v"/> |
---|
[366] | 2163 | <x:ref>Retry-After</x:ref> = "Retry-After" ":" <x:ref>OWS</x:ref> <x:ref>Retry-After-v</x:ref> |
---|
[356] | 2164 | <x:ref>Retry-After-v</x:ref> = <x:ref>HTTP-date</x:ref> / <x:ref>delta-seconds</x:ref> |
---|
[8] | 2165 | </artwork></figure> |
---|
[229] | 2166 | <t anchor="rule.delta-seconds"> |
---|
| 2167 | <x:anchor-alias value="delta-seconds"/> |
---|
[212] | 2168 | Time spans are non-negative decimal integers, representing time in |
---|
| 2169 | seconds. |
---|
| 2170 | </t> |
---|
| 2171 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> |
---|
[229] | 2172 | <x:ref>delta-seconds</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
[212] | 2173 | </artwork></figure> |
---|
| 2174 | <t> |
---|
[8] | 2175 | Two examples of its use are |
---|
| 2176 | </t> |
---|
| 2177 | <figure><artwork type="example"> |
---|
[356] | 2178 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
---|
| 2179 | Retry-After: 120 |
---|
[8] | 2180 | </artwork></figure> |
---|
| 2181 | <t> |
---|
| 2182 | In the latter example, the delay is 2 minutes. |
---|
| 2183 | </t> |
---|
| 2184 | </section> |
---|
| 2185 | |
---|
| 2186 | <section title="Server" anchor="header.server"> |
---|
| 2187 | <iref primary="true" item="Server header" x:for-anchor=""/> |
---|
| 2188 | <iref primary="true" item="Headers" subitem="Server" x:for-anchor=""/> |
---|
[229] | 2189 | <x:anchor-alias value="Server"/> |
---|
[356] | 2190 | <x:anchor-alias value="Server-v"/> |
---|
[8] | 2191 | <t> |
---|
[697] | 2192 | The "Server" response-header field contains information about the |
---|
[698] | 2193 | software used by the origin server to handle the request. |
---|
[8] | 2194 | </t> |
---|
[698] | 2195 | <t> |
---|
| 2196 | The field can contain multiple product tokens (&product-tokens;) and |
---|
| 2197 | comments (&header-fields;) identifying the server and any significant |
---|
| 2198 | subproducts. The product tokens are listed in order of their significance |
---|
| 2199 | for identifying the application. |
---|
| 2200 | </t> |
---|
[356] | 2201 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/><iref primary="true" item="Grammar" subitem="Server-v"/> |
---|
[366] | 2202 | <x:ref>Server</x:ref> = "Server" ":" <x:ref>OWS</x:ref> <x:ref>Server-v</x:ref> |
---|
[370] | 2203 | <x:ref>Server-v</x:ref> = <x:ref>product</x:ref> |
---|
| 2204 | *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) ) |
---|
[8] | 2205 | </artwork></figure> |
---|
| 2206 | <t> |
---|
| 2207 | Example: |
---|
| 2208 | </t> |
---|
| 2209 | <figure><artwork type="example"> |
---|
[356] | 2210 | Server: CERN/3.0 libwww/2.17 |
---|
[8] | 2211 | </artwork></figure> |
---|
| 2212 | <t> |
---|
| 2213 | If the response is being forwarded through a proxy, the proxy |
---|
| 2214 | application &MUST-NOT; modify the Server response-header. Instead, it |
---|
[72] | 2215 | &MUST; include a Via field (as described in &header-via;). |
---|
[8] | 2216 | </t> |
---|
[563] | 2217 | <x:note> |
---|
| 2218 | <t> |
---|
| 2219 | <x:h>Note:</x:h> Revealing the specific software version of the server might |
---|
| 2220 | allow the server machine to become more vulnerable to attacks |
---|
| 2221 | against software that is known to contain security holes. Server |
---|
| 2222 | implementors are encouraged to make this field a configurable |
---|
| 2223 | option. |
---|
| 2224 | </t> |
---|
| 2225 | </x:note> |
---|
[8] | 2226 | </section> |
---|
| 2227 | |
---|
| 2228 | <section title="User-Agent" anchor="header.user-agent"> |
---|
| 2229 | <iref primary="true" item="User-Agent header" x:for-anchor=""/> |
---|
| 2230 | <iref primary="true" item="Headers" subitem="User-Agent" x:for-anchor=""/> |
---|
[229] | 2231 | <x:anchor-alias value="User-Agent"/> |
---|
[356] | 2232 | <x:anchor-alias value="User-Agent-v"/> |
---|
[8] | 2233 | <t> |
---|
[697] | 2234 | The "User-Agent" request-header field contains information about the |
---|
[8] | 2235 | user agent originating the request. This is for statistical purposes, |
---|
| 2236 | the tracing of protocol violations, and automated recognition of user |
---|
| 2237 | agents for the sake of tailoring responses to avoid particular user |
---|
[698] | 2238 | agent limitations. |
---|
[8] | 2239 | </t> |
---|
[698] | 2240 | <t> |
---|
| 2241 | User agents &SHOULD; include this field with requests. The field can contain |
---|
| 2242 | multiple product tokens (&product-tokens;) and comments (&header-fields;) |
---|
| 2243 | identifying the agent and any subproducts which form a significant part of |
---|
| 2244 | the user agent. By convention, the product tokens are listed in order of |
---|
| 2245 | their significance for identifying the application. |
---|
| 2246 | </t> |
---|
[356] | 2247 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/><iref primary="true" item="Grammar" subitem="User-Agent-v"/> |
---|
[366] | 2248 | <x:ref>User-Agent</x:ref> = "User-Agent" ":" <x:ref>OWS</x:ref> <x:ref>User-Agent-v</x:ref> |
---|
[370] | 2249 | <x:ref>User-Agent-v</x:ref> = <x:ref>product</x:ref> |
---|
| 2250 | *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) ) |
---|
[8] | 2251 | </artwork></figure> |
---|
| 2252 | <t> |
---|
| 2253 | Example: |
---|
| 2254 | </t> |
---|
| 2255 | <figure><artwork type="example"> |
---|
[356] | 2256 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
[8] | 2257 | </artwork></figure> |
---|
| 2258 | </section> |
---|
| 2259 | |
---|
| 2260 | </section> |
---|
| 2261 | |
---|
[29] | 2262 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
[270] | 2263 | |
---|
| 2264 | <section title="Method Registry" anchor="method.registration"> |
---|
| 2265 | <t> |
---|
| 2266 | The registration procedure for HTTP Methods is defined by |
---|
| 2267 | <xref target="method.registry"/> of this document. |
---|
| 2268 | </t> |
---|
[288] | 2269 | <t> |
---|
| 2270 | The HTTP Method Registry located at <eref target="http://www.iana.org/assignments/http-methods"/> |
---|
| 2271 | should be populated with the registrations below: |
---|
| 2272 | </t> |
---|
[682] | 2273 | <?BEGININC p2-semantics.iana-methods ?> |
---|
[270] | 2274 | <!--AUTOGENERATED FROM extract-method-defs.xslt, do not edit manually--> |
---|
[288] | 2275 | <texttable align="left" suppress-title="true" anchor="iana.method.registration.table"> |
---|
[270] | 2276 | <ttcol>Method</ttcol> |
---|
[286] | 2277 | <ttcol>Safe</ttcol> |
---|
[270] | 2278 | <ttcol>Reference</ttcol> |
---|
| 2279 | <c>CONNECT</c> |
---|
[286] | 2280 | <c>no</c> |
---|
[270] | 2281 | <c> |
---|
| 2282 | <xref target="CONNECT"/> |
---|
| 2283 | </c> |
---|
| 2284 | <c>DELETE</c> |
---|
[286] | 2285 | <c>no</c> |
---|
[270] | 2286 | <c> |
---|
| 2287 | <xref target="DELETE"/> |
---|
| 2288 | </c> |
---|
| 2289 | <c>GET</c> |
---|
[286] | 2290 | <c>yes</c> |
---|
[270] | 2291 | <c> |
---|
| 2292 | <xref target="GET"/> |
---|
| 2293 | </c> |
---|
| 2294 | <c>HEAD</c> |
---|
[286] | 2295 | <c>yes</c> |
---|
[270] | 2296 | <c> |
---|
| 2297 | <xref target="HEAD"/> |
---|
| 2298 | </c> |
---|
| 2299 | <c>OPTIONS</c> |
---|
[286] | 2300 | <c>yes</c> |
---|
[270] | 2301 | <c> |
---|
| 2302 | <xref target="OPTIONS"/> |
---|
| 2303 | </c> |
---|
| 2304 | <c>POST</c> |
---|
[286] | 2305 | <c>no</c> |
---|
[270] | 2306 | <c> |
---|
| 2307 | <xref target="POST"/> |
---|
| 2308 | </c> |
---|
| 2309 | <c>PUT</c> |
---|
[286] | 2310 | <c>no</c> |
---|
[270] | 2311 | <c> |
---|
| 2312 | <xref target="PUT"/> |
---|
| 2313 | </c> |
---|
| 2314 | <c>TRACE</c> |
---|
[286] | 2315 | <c>yes</c> |
---|
[270] | 2316 | <c> |
---|
| 2317 | <xref target="TRACE"/> |
---|
| 2318 | </c> |
---|
| 2319 | </texttable> |
---|
| 2320 | <!--(END)--> |
---|
[682] | 2321 | <?ENDINC p2-semantics.iana-methods ?> |
---|
[270] | 2322 | </section> |
---|
| 2323 | |
---|
[255] | 2324 | <section title="Status Code Registry" anchor="status.code.registration"> |
---|
[262] | 2325 | <t> |
---|
[288] | 2326 | The registration procedure for HTTP Status Codes -- previously defined |
---|
| 2327 | in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> -- is now defined |
---|
| 2328 | by <xref target="status.code.registry"/> of this document. |
---|
[262] | 2329 | </t> |
---|
[288] | 2330 | <t> |
---|
| 2331 | The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> |
---|
| 2332 | should be updated with the registrations below: |
---|
| 2333 | </t> |
---|
[682] | 2334 | <?BEGININC p2-semantics.iana-status-codes ?> |
---|
[255] | 2335 | <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> |
---|
[288] | 2336 | <texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table"> |
---|
[255] | 2337 | <ttcol>Value</ttcol> |
---|
| 2338 | <ttcol>Description</ttcol> |
---|
| 2339 | <ttcol>Reference</ttcol> |
---|
| 2340 | <c>100</c> |
---|
| 2341 | <c>Continue</c> |
---|
| 2342 | <c> |
---|
| 2343 | <xref target="status.100"/> |
---|
| 2344 | </c> |
---|
| 2345 | <c>101</c> |
---|
| 2346 | <c>Switching Protocols</c> |
---|
| 2347 | <c> |
---|
| 2348 | <xref target="status.101"/> |
---|
| 2349 | </c> |
---|
| 2350 | <c>200</c> |
---|
| 2351 | <c>OK</c> |
---|
| 2352 | <c> |
---|
| 2353 | <xref target="status.200"/> |
---|
| 2354 | </c> |
---|
| 2355 | <c>201</c> |
---|
| 2356 | <c>Created</c> |
---|
| 2357 | <c> |
---|
| 2358 | <xref target="status.201"/> |
---|
| 2359 | </c> |
---|
| 2360 | <c>202</c> |
---|
| 2361 | <c>Accepted</c> |
---|
| 2362 | <c> |
---|
| 2363 | <xref target="status.202"/> |
---|
| 2364 | </c> |
---|
| 2365 | <c>203</c> |
---|
| 2366 | <c>Non-Authoritative Information</c> |
---|
| 2367 | <c> |
---|
| 2368 | <xref target="status.203"/> |
---|
| 2369 | </c> |
---|
| 2370 | <c>204</c> |
---|
| 2371 | <c>No Content</c> |
---|
| 2372 | <c> |
---|
| 2373 | <xref target="status.204"/> |
---|
| 2374 | </c> |
---|
| 2375 | <c>205</c> |
---|
| 2376 | <c>Reset Content</c> |
---|
| 2377 | <c> |
---|
| 2378 | <xref target="status.205"/> |
---|
| 2379 | </c> |
---|
| 2380 | <c>300</c> |
---|
| 2381 | <c>Multiple Choices</c> |
---|
| 2382 | <c> |
---|
| 2383 | <xref target="status.300"/> |
---|
| 2384 | </c> |
---|
| 2385 | <c>301</c> |
---|
| 2386 | <c>Moved Permanently</c> |
---|
| 2387 | <c> |
---|
| 2388 | <xref target="status.301"/> |
---|
| 2389 | </c> |
---|
| 2390 | <c>302</c> |
---|
| 2391 | <c>Found</c> |
---|
| 2392 | <c> |
---|
| 2393 | <xref target="status.302"/> |
---|
| 2394 | </c> |
---|
| 2395 | <c>303</c> |
---|
| 2396 | <c>See Other</c> |
---|
| 2397 | <c> |
---|
| 2398 | <xref target="status.303"/> |
---|
| 2399 | </c> |
---|
| 2400 | <c>305</c> |
---|
| 2401 | <c>Use Proxy</c> |
---|
| 2402 | <c> |
---|
| 2403 | <xref target="status.305"/> |
---|
| 2404 | </c> |
---|
| 2405 | <c>306</c> |
---|
| 2406 | <c>(Unused)</c> |
---|
| 2407 | <c> |
---|
| 2408 | <xref target="status.306"/> |
---|
| 2409 | </c> |
---|
| 2410 | <c>307</c> |
---|
| 2411 | <c>Temporary Redirect</c> |
---|
| 2412 | <c> |
---|
| 2413 | <xref target="status.307"/> |
---|
| 2414 | </c> |
---|
| 2415 | <c>400</c> |
---|
| 2416 | <c>Bad Request</c> |
---|
| 2417 | <c> |
---|
| 2418 | <xref target="status.400"/> |
---|
| 2419 | </c> |
---|
| 2420 | <c>402</c> |
---|
| 2421 | <c>Payment Required</c> |
---|
| 2422 | <c> |
---|
| 2423 | <xref target="status.402"/> |
---|
| 2424 | </c> |
---|
| 2425 | <c>403</c> |
---|
| 2426 | <c>Forbidden</c> |
---|
| 2427 | <c> |
---|
| 2428 | <xref target="status.403"/> |
---|
| 2429 | </c> |
---|
| 2430 | <c>404</c> |
---|
| 2431 | <c>Not Found</c> |
---|
| 2432 | <c> |
---|
| 2433 | <xref target="status.404"/> |
---|
| 2434 | </c> |
---|
| 2435 | <c>405</c> |
---|
| 2436 | <c>Method Not Allowed</c> |
---|
| 2437 | <c> |
---|
| 2438 | <xref target="status.405"/> |
---|
| 2439 | </c> |
---|
| 2440 | <c>406</c> |
---|
| 2441 | <c>Not Acceptable</c> |
---|
| 2442 | <c> |
---|
| 2443 | <xref target="status.406"/> |
---|
| 2444 | </c> |
---|
| 2445 | <c>407</c> |
---|
| 2446 | <c>Proxy Authentication Required</c> |
---|
| 2447 | <c> |
---|
| 2448 | <xref target="status.407"/> |
---|
| 2449 | </c> |
---|
| 2450 | <c>408</c> |
---|
| 2451 | <c>Request Timeout</c> |
---|
| 2452 | <c> |
---|
| 2453 | <xref target="status.408"/> |
---|
| 2454 | </c> |
---|
| 2455 | <c>409</c> |
---|
| 2456 | <c>Conflict</c> |
---|
| 2457 | <c> |
---|
| 2458 | <xref target="status.409"/> |
---|
| 2459 | </c> |
---|
| 2460 | <c>410</c> |
---|
| 2461 | <c>Gone</c> |
---|
| 2462 | <c> |
---|
| 2463 | <xref target="status.410"/> |
---|
| 2464 | </c> |
---|
| 2465 | <c>411</c> |
---|
| 2466 | <c>Length Required</c> |
---|
| 2467 | <c> |
---|
| 2468 | <xref target="status.411"/> |
---|
| 2469 | </c> |
---|
| 2470 | <c>413</c> |
---|
| 2471 | <c>Request Entity Too Large</c> |
---|
| 2472 | <c> |
---|
| 2473 | <xref target="status.413"/> |
---|
| 2474 | </c> |
---|
| 2475 | <c>414</c> |
---|
[465] | 2476 | <c>URI Too Long</c> |
---|
[255] | 2477 | <c> |
---|
| 2478 | <xref target="status.414"/> |
---|
| 2479 | </c> |
---|
| 2480 | <c>415</c> |
---|
| 2481 | <c>Unsupported Media Type</c> |
---|
| 2482 | <c> |
---|
| 2483 | <xref target="status.415"/> |
---|
| 2484 | </c> |
---|
| 2485 | <c>417</c> |
---|
| 2486 | <c>Expectation Failed</c> |
---|
| 2487 | <c> |
---|
| 2488 | <xref target="status.417"/> |
---|
| 2489 | </c> |
---|
| 2490 | <c>500</c> |
---|
| 2491 | <c>Internal Server Error</c> |
---|
| 2492 | <c> |
---|
| 2493 | <xref target="status.500"/> |
---|
| 2494 | </c> |
---|
| 2495 | <c>501</c> |
---|
| 2496 | <c>Not Implemented</c> |
---|
| 2497 | <c> |
---|
| 2498 | <xref target="status.501"/> |
---|
| 2499 | </c> |
---|
| 2500 | <c>502</c> |
---|
| 2501 | <c>Bad Gateway</c> |
---|
| 2502 | <c> |
---|
| 2503 | <xref target="status.502"/> |
---|
| 2504 | </c> |
---|
| 2505 | <c>503</c> |
---|
| 2506 | <c>Service Unavailable</c> |
---|
| 2507 | <c> |
---|
| 2508 | <xref target="status.503"/> |
---|
| 2509 | </c> |
---|
| 2510 | <c>504</c> |
---|
| 2511 | <c>Gateway Timeout</c> |
---|
| 2512 | <c> |
---|
| 2513 | <xref target="status.504"/> |
---|
| 2514 | </c> |
---|
| 2515 | <c>505</c> |
---|
| 2516 | <c>HTTP Version Not Supported</c> |
---|
| 2517 | <c> |
---|
| 2518 | <xref target="status.505"/> |
---|
| 2519 | </c> |
---|
| 2520 | </texttable> |
---|
| 2521 | <!--(END)--> |
---|
[682] | 2522 | <?ENDINC p2-semantics.iana-status-codes ?> |
---|
[8] | 2523 | </section> |
---|
[253] | 2524 | <section title="Message Header Registration" anchor="message.header.registration"> |
---|
[290] | 2525 | <t> |
---|
| 2526 | The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated |
---|
| 2527 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
| 2528 | </t> |
---|
[680] | 2529 | <?BEGININC p2-semantics.iana-headers ?> |
---|
[253] | 2530 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
[290] | 2531 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
[253] | 2532 | <ttcol>Header Field Name</ttcol> |
---|
| 2533 | <ttcol>Protocol</ttcol> |
---|
| 2534 | <ttcol>Status</ttcol> |
---|
| 2535 | <ttcol>Reference</ttcol> |
---|
[680] | 2536 | |
---|
[253] | 2537 | <c>Allow</c> |
---|
| 2538 | <c>http</c> |
---|
| 2539 | <c>standard</c> |
---|
| 2540 | <c> |
---|
| 2541 | <xref target="header.allow"/> |
---|
| 2542 | </c> |
---|
| 2543 | <c>Expect</c> |
---|
| 2544 | <c>http</c> |
---|
| 2545 | <c>standard</c> |
---|
| 2546 | <c> |
---|
| 2547 | <xref target="header.expect"/> |
---|
| 2548 | </c> |
---|
| 2549 | <c>From</c> |
---|
| 2550 | <c>http</c> |
---|
| 2551 | <c>standard</c> |
---|
| 2552 | <c> |
---|
| 2553 | <xref target="header.from"/> |
---|
| 2554 | </c> |
---|
| 2555 | <c>Location</c> |
---|
| 2556 | <c>http</c> |
---|
| 2557 | <c>standard</c> |
---|
| 2558 | <c> |
---|
| 2559 | <xref target="header.location"/> |
---|
| 2560 | </c> |
---|
| 2561 | <c>Max-Forwards</c> |
---|
| 2562 | <c>http</c> |
---|
| 2563 | <c>standard</c> |
---|
| 2564 | <c> |
---|
| 2565 | <xref target="header.max-forwards"/> |
---|
| 2566 | </c> |
---|
| 2567 | <c>Referer</c> |
---|
| 2568 | <c>http</c> |
---|
| 2569 | <c>standard</c> |
---|
| 2570 | <c> |
---|
| 2571 | <xref target="header.referer"/> |
---|
| 2572 | </c> |
---|
| 2573 | <c>Retry-After</c> |
---|
| 2574 | <c>http</c> |
---|
| 2575 | <c>standard</c> |
---|
| 2576 | <c> |
---|
| 2577 | <xref target="header.retry-after"/> |
---|
| 2578 | </c> |
---|
| 2579 | <c>Server</c> |
---|
| 2580 | <c>http</c> |
---|
| 2581 | <c>standard</c> |
---|
| 2582 | <c> |
---|
| 2583 | <xref target="header.server"/> |
---|
| 2584 | </c> |
---|
| 2585 | <c>User-Agent</c> |
---|
| 2586 | <c>http</c> |
---|
| 2587 | <c>standard</c> |
---|
| 2588 | <c> |
---|
| 2589 | <xref target="header.user-agent"/> |
---|
| 2590 | </c> |
---|
| 2591 | </texttable> |
---|
[290] | 2592 | <!--(END)--> |
---|
[680] | 2593 | <?ENDINC p2-semantics.iana-headers ?> |
---|
[253] | 2594 | <t> |
---|
[290] | 2595 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
[253] | 2596 | </t> |
---|
| 2597 | </section> |
---|
| 2598 | </section> |
---|
| 2599 | |
---|
[8] | 2600 | <section title="Security Considerations" anchor="security.considerations"> |
---|
| 2601 | <t> |
---|
| 2602 | This section is meant to inform application developers, information |
---|
| 2603 | providers, and users of the security limitations in HTTP/1.1 as |
---|
| 2604 | described by this document. The discussion does not include |
---|
| 2605 | definitive solutions to the problems revealed, though it does make |
---|
| 2606 | some suggestions for reducing security risks. |
---|
| 2607 | </t> |
---|
| 2608 | |
---|
| 2609 | <section title="Transfer of Sensitive Information" anchor="security.sensitive"> |
---|
| 2610 | <t> |
---|
| 2611 | Like any generic data transfer protocol, HTTP cannot regulate the |
---|
| 2612 | content of the data that is transferred, nor is there any a priori |
---|
| 2613 | method of determining the sensitivity of any particular piece of |
---|
| 2614 | information within the context of any given request. Therefore, |
---|
| 2615 | applications &SHOULD; supply as much control over this information as |
---|
| 2616 | possible to the provider of that information. Four header fields are |
---|
| 2617 | worth special mention in this context: Server, Via, Referer and From. |
---|
| 2618 | </t> |
---|
| 2619 | <t> |
---|
| 2620 | Revealing the specific software version of the server might allow the |
---|
| 2621 | server machine to become more vulnerable to attacks against software |
---|
| 2622 | that is known to contain security holes. Implementors &SHOULD; make the |
---|
| 2623 | Server header field a configurable option. |
---|
| 2624 | </t> |
---|
| 2625 | <t> |
---|
| 2626 | Proxies which serve as a portal through a network firewall &SHOULD; |
---|
| 2627 | take special precautions regarding the transfer of header information |
---|
| 2628 | that identifies the hosts behind the firewall. In particular, they |
---|
| 2629 | &SHOULD; remove, or replace with sanitized versions, any Via fields |
---|
| 2630 | generated behind the firewall. |
---|
| 2631 | </t> |
---|
| 2632 | <t> |
---|
| 2633 | The Referer header allows reading patterns to be studied and reverse |
---|
| 2634 | links drawn. Although it can be very useful, its power can be abused |
---|
| 2635 | if user details are not separated from the information contained in |
---|
| 2636 | the Referer. Even when the personal information has been removed, the |
---|
| 2637 | Referer header might indicate a private document's URI whose |
---|
| 2638 | publication would be inappropriate. |
---|
| 2639 | </t> |
---|
| 2640 | <t> |
---|
| 2641 | The information sent in the From field might conflict with the user's |
---|
| 2642 | privacy interests or their site's security policy, and hence it |
---|
| 2643 | &SHOULD-NOT; be transmitted without the user being able to disable, |
---|
| 2644 | enable, and modify the contents of the field. The user &MUST; be able |
---|
| 2645 | to set the contents of this field within a user preference or |
---|
| 2646 | application defaults configuration. |
---|
| 2647 | </t> |
---|
| 2648 | <t> |
---|
| 2649 | We suggest, though do not require, that a convenient toggle interface |
---|
| 2650 | be provided for the user to enable or disable the sending of From and |
---|
| 2651 | Referer information. |
---|
| 2652 | </t> |
---|
| 2653 | <t> |
---|
| 2654 | The User-Agent (<xref target="header.user-agent"/>) or Server (<xref target="header.server"/>) header |
---|
| 2655 | fields can sometimes be used to determine that a specific client or |
---|
| 2656 | server have a particular security hole which might be exploited. |
---|
| 2657 | Unfortunately, this same information is often used for other valuable |
---|
| 2658 | purposes for which HTTP currently has no better mechanism. |
---|
| 2659 | </t> |
---|
[654] | 2660 | <t> |
---|
[666] | 2661 | Some methods, like TRACE (<xref target="TRACE"/>) may expose |
---|
| 2662 | information sent in request headers in the response entity. |
---|
| 2663 | Clients &SHOULD; be careful with sensitive information, like Cookies, |
---|
| 2664 | Authorization credentials and other headers that might be used to |
---|
| 2665 | collect data from the client. |
---|
[654] | 2666 | </t> |
---|
[8] | 2667 | </section> |
---|
| 2668 | |
---|
[184] | 2669 | <section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris"> |
---|
[8] | 2670 | <t> |
---|
| 2671 | Because the source of a link might be private information or might |
---|
| 2672 | reveal an otherwise private information source, it is strongly |
---|
| 2673 | recommended that the user be able to select whether or not the |
---|
| 2674 | Referer field is sent. For example, a browser client could have a |
---|
| 2675 | toggle switch for browsing openly/anonymously, which would |
---|
| 2676 | respectively enable/disable the sending of Referer and From |
---|
| 2677 | information. |
---|
| 2678 | </t> |
---|
| 2679 | <t> |
---|
[172] | 2680 | Clients &SHOULD-NOT; include a Referer header field in a (non-secure) |
---|
[8] | 2681 | HTTP request if the referring page was transferred with a secure |
---|
| 2682 | protocol. |
---|
| 2683 | </t> |
---|
| 2684 | <t> |
---|
[172] | 2685 | Authors of services should not use |
---|
| 2686 | GET-based forms for the submission of sensitive data because that |
---|
[391] | 2687 | data will be encoded in the Request-target. Many existing |
---|
| 2688 | servers, proxies, and user agents log or display the Request-target in |
---|
[172] | 2689 | places where it might be visible to third parties. Such services can |
---|
| 2690 | use POST-based form submission instead. |
---|
[8] | 2691 | </t> |
---|
| 2692 | </section> |
---|
| 2693 | |
---|
| 2694 | <section title="Location Headers and Spoofing" anchor="location.spoofing"> |
---|
| 2695 | <t> |
---|
| 2696 | If a single server supports multiple organizations that do not trust |
---|
| 2697 | one another, then it &MUST; check the values of Location and Content-Location |
---|
| 2698 | headers in responses that are generated under control of |
---|
| 2699 | said organizations to make sure that they do not attempt to |
---|
| 2700 | invalidate resources over which they have no authority. |
---|
| 2701 | </t> |
---|
| 2702 | </section> |
---|
| 2703 | |
---|
| 2704 | </section> |
---|
| 2705 | |
---|
| 2706 | <section title="Acknowledgments" anchor="ack"> |
---|
| 2707 | </section> |
---|
| 2708 | </middle> |
---|
| 2709 | <back> |
---|
| 2710 | |
---|
[119] | 2711 | <references title="Normative References"> |
---|
| 2712 | |
---|
[31] | 2713 | <reference anchor="Part1"> |
---|
[119] | 2714 | <front> |
---|
| 2715 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
| 2716 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2717 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2718 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2719 | </author> |
---|
| 2720 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2721 | <organization>One Laptop per Child</organization> |
---|
| 2722 | <address><email>jg@laptop.org</email></address> |
---|
| 2723 | </author> |
---|
| 2724 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2725 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2726 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2727 | </author> |
---|
| 2728 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2729 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2730 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2731 | </author> |
---|
| 2732 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2733 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2734 | <address><email>LMM@acm.org</email></address> |
---|
| 2735 | </author> |
---|
| 2736 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2737 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2738 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2739 | </author> |
---|
| 2740 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2741 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2742 | <address><email>timbl@w3.org</email></address> |
---|
| 2743 | </author> |
---|
| 2744 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2745 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2746 | <address><email>ylafon@w3.org</email></address> |
---|
| 2747 | </author> |
---|
| 2748 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2749 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2750 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2751 | </author> |
---|
| 2752 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2753 | </front> |
---|
| 2754 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> |
---|
| 2755 | <x:source href="p1-messaging.xml" basename="p1-messaging"/> |
---|
[31] | 2756 | </reference> |
---|
| 2757 | |
---|
| 2758 | <reference anchor="Part3"> |
---|
[119] | 2759 | <front> |
---|
| 2760 | <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
| 2761 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2762 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2763 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2764 | </author> |
---|
| 2765 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2766 | <organization>One Laptop per Child</organization> |
---|
| 2767 | <address><email>jg@laptop.org</email></address> |
---|
| 2768 | </author> |
---|
| 2769 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2770 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2771 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2772 | </author> |
---|
| 2773 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2774 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2775 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2776 | </author> |
---|
| 2777 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2778 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2779 | <address><email>LMM@acm.org</email></address> |
---|
| 2780 | </author> |
---|
| 2781 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2782 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2783 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2784 | </author> |
---|
| 2785 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2786 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2787 | <address><email>timbl@w3.org</email></address> |
---|
| 2788 | </author> |
---|
| 2789 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2790 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2791 | <address><email>ylafon@w3.org</email></address> |
---|
| 2792 | </author> |
---|
| 2793 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2794 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2795 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2796 | </author> |
---|
| 2797 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2798 | </front> |
---|
| 2799 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/> |
---|
| 2800 | <x:source href="p3-payload.xml" basename="p3-payload"/> |
---|
[31] | 2801 | </reference> |
---|
| 2802 | |
---|
| 2803 | <reference anchor="Part4"> |
---|
[119] | 2804 | <front> |
---|
| 2805 | <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> |
---|
| 2806 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2807 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2808 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2809 | </author> |
---|
| 2810 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2811 | <organization>One Laptop per Child</organization> |
---|
| 2812 | <address><email>jg@laptop.org</email></address> |
---|
| 2813 | </author> |
---|
| 2814 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2815 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2816 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2817 | </author> |
---|
| 2818 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2819 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2820 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2821 | </author> |
---|
| 2822 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2823 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2824 | <address><email>LMM@acm.org</email></address> |
---|
| 2825 | </author> |
---|
| 2826 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2827 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2828 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2829 | </author> |
---|
| 2830 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2831 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2832 | <address><email>timbl@w3.org</email></address> |
---|
| 2833 | </author> |
---|
| 2834 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2835 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2836 | <address><email>ylafon@w3.org</email></address> |
---|
| 2837 | </author> |
---|
| 2838 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2839 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2840 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2841 | </author> |
---|
| 2842 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2843 | </front> |
---|
| 2844 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/> |
---|
| 2845 | <x:source href="p4-conditional.xml" basename="p4-conditional"/> |
---|
[31] | 2846 | </reference> |
---|
| 2847 | |
---|
| 2848 | <reference anchor="Part5"> |
---|
[119] | 2849 | <front> |
---|
| 2850 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
| 2851 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2852 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2853 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2854 | </author> |
---|
| 2855 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2856 | <organization>One Laptop per Child</organization> |
---|
| 2857 | <address><email>jg@laptop.org</email></address> |
---|
| 2858 | </author> |
---|
| 2859 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2860 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2861 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2862 | </author> |
---|
| 2863 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2864 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2865 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2866 | </author> |
---|
| 2867 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2868 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2869 | <address><email>LMM@acm.org</email></address> |
---|
| 2870 | </author> |
---|
| 2871 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2872 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2873 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2874 | </author> |
---|
| 2875 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2876 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2877 | <address><email>timbl@w3.org</email></address> |
---|
| 2878 | </author> |
---|
| 2879 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2880 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2881 | <address><email>ylafon@w3.org</email></address> |
---|
| 2882 | </author> |
---|
| 2883 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2884 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2885 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2886 | </author> |
---|
| 2887 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2888 | </front> |
---|
| 2889 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/> |
---|
| 2890 | <x:source href="p5-range.xml" basename="p5-range"/> |
---|
[31] | 2891 | </reference> |
---|
| 2892 | |
---|
| 2893 | <reference anchor="Part6"> |
---|
[119] | 2894 | <front> |
---|
| 2895 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
| 2896 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2897 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2898 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2899 | </author> |
---|
| 2900 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2901 | <organization>One Laptop per Child</organization> |
---|
| 2902 | <address><email>jg@laptop.org</email></address> |
---|
| 2903 | </author> |
---|
| 2904 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2905 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2906 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2907 | </author> |
---|
| 2908 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2909 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2910 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2911 | </author> |
---|
| 2912 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2913 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2914 | <address><email>LMM@acm.org</email></address> |
---|
| 2915 | </author> |
---|
| 2916 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2917 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2918 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2919 | </author> |
---|
| 2920 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2921 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2922 | <address><email>timbl@w3.org</email></address> |
---|
| 2923 | </author> |
---|
| 2924 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2925 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2926 | <address><email>ylafon@w3.org</email></address> |
---|
| 2927 | </author> |
---|
[601] | 2928 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
| 2929 | <organization /> |
---|
| 2930 | <address><email>mnot@mnot.net</email></address> |
---|
| 2931 | </author> |
---|
[119] | 2932 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2933 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2934 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2935 | </author> |
---|
| 2936 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2937 | </front> |
---|
| 2938 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
| 2939 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
[31] | 2940 | </reference> |
---|
| 2941 | |
---|
| 2942 | <reference anchor="Part7"> |
---|
[119] | 2943 | <front> |
---|
| 2944 | <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title> |
---|
| 2945 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
| 2946 | <organization abbrev="Day Software">Day Software</organization> |
---|
| 2947 | <address><email>fielding@gbiv.com</email></address> |
---|
| 2948 | </author> |
---|
| 2949 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 2950 | <organization>One Laptop per Child</organization> |
---|
| 2951 | <address><email>jg@laptop.org</email></address> |
---|
| 2952 | </author> |
---|
| 2953 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 2954 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
| 2955 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 2956 | </author> |
---|
| 2957 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
| 2958 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2959 | <address><email>henrikn@microsoft.com</email></address> |
---|
| 2960 | </author> |
---|
| 2961 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
| 2962 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
| 2963 | <address><email>LMM@acm.org</email></address> |
---|
| 2964 | </author> |
---|
| 2965 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
| 2966 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
| 2967 | <address><email>paulle@microsoft.com</email></address> |
---|
| 2968 | </author> |
---|
| 2969 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 2970 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
| 2971 | <address><email>timbl@w3.org</email></address> |
---|
| 2972 | </author> |
---|
| 2973 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
| 2974 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
| 2975 | <address><email>ylafon@w3.org</email></address> |
---|
| 2976 | </author> |
---|
| 2977 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
| 2978 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
| 2979 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
| 2980 | </author> |
---|
| 2981 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
| 2982 | </front> |
---|
| 2983 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/> |
---|
| 2984 | <x:source href="p7-auth.xml" basename="p7-auth"/> |
---|
[31] | 2985 | </reference> |
---|
| 2986 | |
---|
[119] | 2987 | <reference anchor="RFC2119"> |
---|
| 2988 | <front> |
---|
| 2989 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
| 2990 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
| 2991 | <organization>Harvard University</organization> |
---|
| 2992 | <address><email>sob@harvard.edu</email></address> |
---|
| 2993 | </author> |
---|
| 2994 | <date month="March" year="1997"/> |
---|
| 2995 | </front> |
---|
| 2996 | <seriesInfo name="BCP" value="14"/> |
---|
| 2997 | <seriesInfo name="RFC" value="2119"/> |
---|
| 2998 | </reference> |
---|
| 2999 | |
---|
[425] | 3000 | <reference anchor="RFC5234"> |
---|
| 3001 | <front> |
---|
| 3002 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
| 3003 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
| 3004 | <organization>Brandenburg InternetWorking</organization> |
---|
| 3005 | <address> |
---|
| 3006 | <postal> |
---|
| 3007 | <street>675 Spruce Dr.</street> |
---|
| 3008 | <city>Sunnyvale</city> |
---|
| 3009 | <region>CA</region> |
---|
| 3010 | <code>94086</code> |
---|
| 3011 | <country>US</country></postal> |
---|
| 3012 | <phone>+1.408.246.8253</phone> |
---|
| 3013 | <email>dcrocker@bbiw.net</email></address> |
---|
| 3014 | </author> |
---|
| 3015 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
| 3016 | <organization>THUS plc.</organization> |
---|
| 3017 | <address> |
---|
| 3018 | <postal> |
---|
| 3019 | <street>1/2 Berkeley Square</street> |
---|
| 3020 | <street>99 Berkely Street</street> |
---|
| 3021 | <city>Glasgow</city> |
---|
| 3022 | <code>G3 7HR</code> |
---|
| 3023 | <country>UK</country></postal> |
---|
| 3024 | <email>paul.overell@thus.net</email></address> |
---|
| 3025 | </author> |
---|
| 3026 | <date month="January" year="2008"/> |
---|
| 3027 | </front> |
---|
| 3028 | <seriesInfo name="STD" value="68"/> |
---|
| 3029 | <seriesInfo name="RFC" value="5234"/> |
---|
| 3030 | </reference> |
---|
| 3031 | |
---|
[119] | 3032 | </references> |
---|
| 3033 | |
---|
| 3034 | <references title="Informative References"> |
---|
| 3035 | |
---|
[129] | 3036 | <reference anchor="RFC1945"> |
---|
| 3037 | <front> |
---|
| 3038 | <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> |
---|
| 3039 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3040 | <organization>MIT, Laboratory for Computer Science</organization> |
---|
| 3041 | <address><email>timbl@w3.org</email></address> |
---|
| 3042 | </author> |
---|
| 3043 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3044 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
| 3045 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3046 | </author> |
---|
| 3047 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
| 3048 | <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> |
---|
| 3049 | <address><email>frystyk@w3.org</email></address> |
---|
| 3050 | </author> |
---|
| 3051 | <date month="May" year="1996"/> |
---|
| 3052 | </front> |
---|
| 3053 | <seriesInfo name="RFC" value="1945"/> |
---|
| 3054 | </reference> |
---|
| 3055 | |
---|
[119] | 3056 | <reference anchor="RFC2068"> |
---|
| 3057 | <front> |
---|
| 3058 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
| 3059 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
| 3060 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
| 3061 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3062 | </author> |
---|
| 3063 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
| 3064 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3065 | <address><email>jg@w3.org</email></address> |
---|
| 3066 | </author> |
---|
| 3067 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
| 3068 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
| 3069 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 3070 | </author> |
---|
| 3071 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
| 3072 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3073 | <address><email>frystyk@w3.org</email></address> |
---|
| 3074 | </author> |
---|
| 3075 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
| 3076 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3077 | <address><email>timbl@w3.org</email></address> |
---|
| 3078 | </author> |
---|
| 3079 | <date month="January" year="1997"/> |
---|
| 3080 | </front> |
---|
| 3081 | <seriesInfo name="RFC" value="2068"/> |
---|
| 3082 | </reference> |
---|
| 3083 | |
---|
[36] | 3084 | <reference anchor="RFC2616"> |
---|
[119] | 3085 | <front> |
---|
| 3086 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
| 3087 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
| 3088 | <organization>University of California, Irvine</organization> |
---|
| 3089 | <address><email>fielding@ics.uci.edu</email></address> |
---|
| 3090 | </author> |
---|
| 3091 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
| 3092 | <organization>W3C</organization> |
---|
| 3093 | <address><email>jg@w3.org</email></address> |
---|
| 3094 | </author> |
---|
| 3095 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
| 3096 | <organization>Compaq Computer Corporation</organization> |
---|
| 3097 | <address><email>mogul@wrl.dec.com</email></address> |
---|
| 3098 | </author> |
---|
| 3099 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
| 3100 | <organization>MIT Laboratory for Computer Science</organization> |
---|
| 3101 | <address><email>frystyk@w3.org</email></address> |
---|
| 3102 | </author> |
---|
| 3103 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
| 3104 | <organization>Xerox Corporation</organization> |
---|
| 3105 | <address><email>masinter@parc.xerox.com</email></address> |
---|
| 3106 | </author> |
---|
| 3107 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
| 3108 | <organization>Microsoft Corporation</organization> |
---|
| 3109 | <address><email>paulle@microsoft.com</email></address> |
---|
| 3110 | </author> |
---|
| 3111 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
| 3112 | <organization>W3C</organization> |
---|
| 3113 | <address><email>timbl@w3.org</email></address> |
---|
| 3114 | </author> |
---|
| 3115 | <date month="June" year="1999"/> |
---|
| 3116 | </front> |
---|
| 3117 | <seriesInfo name="RFC" value="2616"/> |
---|
[36] | 3118 | </reference> |
---|
| 3119 | |
---|
[255] | 3120 | <reference anchor='RFC2817'> |
---|
| 3121 | <front> |
---|
| 3122 | <title>Upgrading to TLS Within HTTP/1.1</title> |
---|
| 3123 | <author initials='R.' surname='Khare' fullname='R. Khare'> |
---|
| 3124 | <organization>4K Associates / UC Irvine</organization> |
---|
| 3125 | <address><email>rohit@4K-associates.com</email></address> |
---|
| 3126 | </author> |
---|
| 3127 | <author initials='S.' surname='Lawrence' fullname='S. Lawrence'> |
---|
| 3128 | <organization>Agranat Systems, Inc.</organization> |
---|
| 3129 | <address><email>lawrence@agranat.com</email></address> |
---|
| 3130 | </author> |
---|
| 3131 | <date year='2000' month='May' /> |
---|
| 3132 | </front> |
---|
| 3133 | <seriesInfo name='RFC' value='2817' /> |
---|
| 3134 | </reference> |
---|
| 3135 | |
---|
[253] | 3136 | <reference anchor='RFC3864'> |
---|
| 3137 | <front> |
---|
| 3138 | <title>Registration Procedures for Message Header Fields</title> |
---|
| 3139 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
| 3140 | <organization>Nine by Nine</organization> |
---|
| 3141 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
| 3142 | </author> |
---|
| 3143 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
| 3144 | <organization>BEA Systems</organization> |
---|
| 3145 | <address><email>mnot@pobox.com</email></address> |
---|
| 3146 | </author> |
---|
| 3147 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
| 3148 | <organization>HP Labs</organization> |
---|
| 3149 | <address><email>JeffMogul@acm.org</email></address> |
---|
| 3150 | </author> |
---|
| 3151 | <date year='2004' month='September' /> |
---|
| 3152 | </front> |
---|
| 3153 | <seriesInfo name='BCP' value='90' /> |
---|
| 3154 | <seriesInfo name='RFC' value='3864' /> |
---|
| 3155 | </reference> |
---|
| 3156 | |
---|
[262] | 3157 | <reference anchor='RFC5226'> |
---|
| 3158 | <front> |
---|
| 3159 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
| 3160 | <author initials='T.' surname='Narten' fullname='T. Narten'> |
---|
| 3161 | <organization>IBM</organization> |
---|
| 3162 | <address><email>narten@us.ibm.com</email></address> |
---|
| 3163 | </author> |
---|
| 3164 | <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'> |
---|
| 3165 | <organization>Google</organization> |
---|
| 3166 | <address><email>Harald@Alvestrand.no</email></address> |
---|
| 3167 | </author> |
---|
| 3168 | <date year='2008' month='May' /> |
---|
| 3169 | </front> |
---|
| 3170 | <seriesInfo name='BCP' value='26' /> |
---|
| 3171 | <seriesInfo name='RFC' value='5226' /> |
---|
| 3172 | </reference> |
---|
| 3173 | |
---|
[327] | 3174 | <reference anchor="RFC5322"> |
---|
| 3175 | <front> |
---|
| 3176 | <title>Internet Message Format</title> |
---|
| 3177 | <author initials="P." surname="Resnick" fullname="P. Resnick"> |
---|
| 3178 | <organization>Qualcomm Incorporated</organization> |
---|
| 3179 | </author> |
---|
| 3180 | <date year="2008" month="October"/> |
---|
| 3181 | </front> |
---|
| 3182 | <seriesInfo name="RFC" value="5322"/> |
---|
| 3183 | </reference> |
---|
| 3184 | |
---|
[119] | 3185 | </references> |
---|
| 3186 | |
---|
[99] | 3187 | <section title="Compatibility with Previous Versions" anchor="compatibility"> |
---|
[8] | 3188 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
| 3189 | <t> |
---|
| 3190 | Clarified which error code should be used for inbound server failures |
---|
| 3191 | (e.g. DNS failures). (<xref target="status.504"/>). |
---|
| 3192 | </t> |
---|
| 3193 | <t> |
---|
[140] | 3194 | 201 (Created) had a race that required an Etag be sent when a resource is |
---|
[8] | 3195 | first created. (<xref target="status.201"/>). |
---|
| 3196 | </t> |
---|
| 3197 | <t> |
---|
[614] | 3198 | 303 (See Also) and 307 (Temporary Redirect) added to address user agent |
---|
| 3199 | failure to implement status code 302 properly. |
---|
| 3200 | (Section <xref target="status.303" format="counter"/> and <xref target="status.307" format="counter"/>) |
---|
| 3201 | </t> |
---|
| 3202 | <t> |
---|
[8] | 3203 | Rewrite of message transmission requirements to make it much harder |
---|
| 3204 | for implementors to get it wrong, as the consequences of errors here |
---|
| 3205 | can have significant impact on the Internet, and to deal with the |
---|
| 3206 | following problems: |
---|
| 3207 | <list style="numbers"> |
---|
| 3208 | <t>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where |
---|
| 3209 | this was incorrectly placing a requirement on the behavior of |
---|
| 3210 | an implementation of a future version of HTTP/1.x</t> |
---|
| 3211 | |
---|
| 3212 | <t>Made it clear that user-agents should retry requests, not |
---|
| 3213 | "clients" in general.</t> |
---|
| 3214 | |
---|
| 3215 | <t>Converted requirements for clients to ignore unexpected 100 |
---|
| 3216 | (Continue) responses, and for proxies to forward 100 responses, |
---|
| 3217 | into a general requirement for 1xx responses.</t> |
---|
| 3218 | |
---|
| 3219 | <t>Modified some TCP-specific language, to make it clearer that |
---|
| 3220 | non-TCP transports are possible for HTTP.</t> |
---|
| 3221 | |
---|
| 3222 | <t>Require that the origin server &MUST-NOT; wait for the request |
---|
| 3223 | body before it sends a required 100 (Continue) response.</t> |
---|
| 3224 | |
---|
| 3225 | <t>Allow, rather than require, a server to omit 100 (Continue) if |
---|
| 3226 | it has already seen some of the request body.</t> |
---|
| 3227 | |
---|
| 3228 | <t>Allow servers to defend against denial-of-service attacks and |
---|
| 3229 | broken clients.</t> |
---|
| 3230 | </list> |
---|
| 3231 | </t> |
---|
| 3232 | <t> |
---|
[29] | 3233 | This change adds the Expect header and 417 status code. |
---|
[8] | 3234 | </t> |
---|
| 3235 | <t> |
---|
| 3236 | Clean up confusion between 403 and 404 responses. (Section <xref target="status.403" format="counter"/>, |
---|
| 3237 | <xref target="status.404" format="counter"/>, and <xref target="status.410" format="counter"/>) |
---|
| 3238 | </t> |
---|
| 3239 | <t> |
---|
| 3240 | The PATCH<iref item="PATCH method" primary="true"/><iref item="Methods" subitem="PATCH" primary="true"/>, LINK<iref item="LINK method" primary="true"/><iref item="Methods" subitem="LINK" primary="true"/>, UNLINK<iref item="UNLINK method" primary="true"/><iref item="Methods" subitem="UNLINK" primary="true"/> methods were defined but not commonly |
---|
[266] | 3241 | implemented in previous versions of this specification. See <xref target="RFC2068" x:fmt="of" x:sec="19.6.1"/>. |
---|
[8] | 3242 | </t> |
---|
| 3243 | </section> |
---|
[99] | 3244 | |
---|
| 3245 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
[108] | 3246 | <t> |
---|
[262] | 3247 | This document takes over the Status Code Registry, previously defined |
---|
| 3248 | in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. |
---|
| 3249 | (<xref target="status.code.registry"/>) |
---|
| 3250 | </t> |
---|
| 3251 | <t> |
---|
[108] | 3252 | Clarify definition of POST. |
---|
| 3253 | (<xref target="POST"/>) |
---|
| 3254 | </t> |
---|
[109] | 3255 | <t> |
---|
| 3256 | Failed to consider that there are |
---|
| 3257 | many other request methods that are safe to automatically redirect, |
---|
| 3258 | and further that the user agent is able to make that determination |
---|
| 3259 | based on the request method semantics. |
---|
| 3260 | (Sections <xref format="counter" target="status.301"/>, |
---|
| 3261 | <xref format="counter" target="status.302"/> and |
---|
[233] | 3262 | <xref format="counter" target="status.307"/>) |
---|
[109] | 3263 | </t> |
---|
[112] | 3264 | <t> |
---|
[235] | 3265 | Deprecate 305 Use Proxy status code, because user agents did not implement it. |
---|
| 3266 | It used to indicate that the requested resource must be accessed through the |
---|
| 3267 | proxy given by the Location field. The Location field gave the URI of the |
---|
| 3268 | proxy. The recipient was expected to repeat this single request via the proxy. |
---|
| 3269 | (<xref target="status.305"/>) |
---|
| 3270 | </t> |
---|
| 3271 | <t> |
---|
[232] | 3272 | Reclassify Allow header as response header, removing the option to |
---|
| 3273 | specify it in a PUT request. |
---|
[240] | 3274 | Relax the server requirement on the contents of the Allow header and |
---|
| 3275 | remove requirement on clients to always trust the header value. |
---|
[232] | 3276 | (<xref target="header.allow"/>) |
---|
| 3277 | </t> |
---|
| 3278 | <t> |
---|
[114] | 3279 | Correct syntax of Location header to allow fragment, |
---|
| 3280 | as referred symbol wasn't what was expected, and add some |
---|
| 3281 | clarifications as to when it would not be appropriate. |
---|
| 3282 | (<xref target="header.location"/>) |
---|
| 3283 | </t> |
---|
| 3284 | <t> |
---|
[593] | 3285 | Allow Referer value of "about:blank" as alternative to not specifying it. |
---|
| 3286 | (<xref target="header.referer"/>) |
---|
| 3287 | </t> |
---|
| 3288 | <t> |
---|
[112] | 3289 | In the description of the Server header, the Via field |
---|
| 3290 | was described as a SHOULD. The requirement was and is stated |
---|
| 3291 | correctly in the description of the Via header in &header-via;. |
---|
| 3292 | (<xref target="header.server"/>) |
---|
| 3293 | </t> |
---|
[99] | 3294 | </section> |
---|
| 3295 | |
---|
| 3296 | </section> |
---|
| 3297 | |
---|
[680] | 3298 | <?BEGININC p2-semantics.abnf-appendix ?> |
---|
[427] | 3299 | <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> |
---|
| 3300 | <figure> |
---|
| 3301 | <artwork type="abnf" name="p2-semantics.parsed-abnf"> |
---|
| 3302 | <x:ref>Accept</x:ref> = <Accept, defined in [Part3], Section 5.1> |
---|
| 3303 | <x:ref>Accept-Charset</x:ref> = <Accept-Charset, defined in [Part3], Section 5.2> |
---|
| 3304 | <x:ref>Accept-Encoding</x:ref> = <Accept-Encoding, defined in [Part3], Section 5.3> |
---|
| 3305 | <x:ref>Accept-Language</x:ref> = <Accept-Language, defined in [Part3], Section 5.4> |
---|
| 3306 | <x:ref>Accept-Ranges</x:ref> = <Accept-Ranges, defined in [Part5], Section 5.1> |
---|
[538] | 3307 | <x:ref>Age</x:ref> = <Age, defined in [Part6], Section 3.1> |
---|
[427] | 3308 | <x:ref>Allow</x:ref> = "Allow:" OWS Allow-v |
---|
| 3309 | <x:ref>Allow-v</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
---|
| 3310 | <x:ref>Authorization</x:ref> = <Authorization, defined in [Part7], Section 3.1> |
---|
| 3311 | |
---|
| 3312 | <x:ref>ETag</x:ref> = <ETag, defined in [Part4], Section 6.1> |
---|
| 3313 | <x:ref>Expect</x:ref> = "Expect:" OWS Expect-v |
---|
| 3314 | <x:ref>Expect-v</x:ref> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
---|
| 3315 | |
---|
| 3316 | <x:ref>From</x:ref> = "From:" OWS From-v |
---|
| 3317 | <x:ref>From-v</x:ref> = mailbox |
---|
| 3318 | |
---|
[678] | 3319 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part1], Section 6.1> |
---|
[648] | 3320 | <x:ref>Host</x:ref> = <Host, defined in [Part1], Section 2.6> |
---|
[427] | 3321 | |
---|
| 3322 | <x:ref>If-Match</x:ref> = <If-Match, defined in [Part4], Section 6.2> |
---|
[454] | 3323 | If-Modified-Since = |
---|
| 3324 | <If-Modified-Since, defined in [Part4], Section 6.3> |
---|
[427] | 3325 | <x:ref>If-None-Match</x:ref> = <If-None-Match, defined in [Part4], Section 6.4> |
---|
| 3326 | <x:ref>If-Range</x:ref> = <If-Range, defined in [Part5], Section 5.3> |
---|
[454] | 3327 | If-Unmodified-Since = |
---|
| 3328 | <If-Unmodified-Since, defined in [Part4], Section 6.5> |
---|
[428] | 3329 | |
---|
[427] | 3330 | <x:ref>Location</x:ref> = "Location:" OWS Location-v |
---|
[632] | 3331 | <x:ref>Location-v</x:ref> = URI |
---|
[427] | 3332 | |
---|
| 3333 | <x:ref>Max-Forwards</x:ref> = "Max-Forwards:" OWS Max-Forwards-v |
---|
| 3334 | <x:ref>Max-Forwards-v</x:ref> = 1*DIGIT |
---|
[581] | 3335 | <x:ref>Method</x:ref> = %x4F.50.54.49.4F.4E.53 ; OPTIONS |
---|
| 3336 | / %x47.45.54 ; GET |
---|
| 3337 | / %x48.45.41.44 ; HEAD |
---|
| 3338 | / %x50.4F.53.54 ; POST |
---|
| 3339 | / %x50.55.54 ; PUT |
---|
| 3340 | / %x44.45.4C.45.54.45 ; DELETE |
---|
| 3341 | / %x54.52.41.43.45 ; TRACE |
---|
| 3342 | / %x43.4F.4E.4E.45.43.54 ; CONNECT |
---|
| 3343 | / extension-method |
---|
[428] | 3344 | |
---|
[427] | 3345 | <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 1.2.2> |
---|
| 3346 | |
---|
[454] | 3347 | Proxy-Authenticate = |
---|
| 3348 | <Proxy-Authenticate, defined in [Part7], Section 3.2> |
---|
| 3349 | Proxy-Authorization = |
---|
| 3350 | <Proxy-Authorization, defined in [Part7], Section 3.3> |
---|
[428] | 3351 | |
---|
[427] | 3352 | <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 1.2.2> |
---|
| 3353 | <x:ref>Range</x:ref> = <Range, defined in [Part5], Section 5.4> |
---|
| 3354 | <x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text ) |
---|
| 3355 | <x:ref>Referer</x:ref> = "Referer:" OWS Referer-v |
---|
| 3356 | <x:ref>Referer-v</x:ref> = absolute-URI / partial-URI |
---|
| 3357 | <x:ref>Retry-After</x:ref> = "Retry-After:" OWS Retry-After-v |
---|
| 3358 | <x:ref>Retry-After-v</x:ref> = HTTP-date / delta-seconds |
---|
| 3359 | |
---|
| 3360 | <x:ref>Server</x:ref> = "Server:" OWS Server-v |
---|
| 3361 | <x:ref>Server-v</x:ref> = product *( RWS ( product / comment ) ) |
---|
| 3362 | <x:ref>Status-Code</x:ref> = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |
---|
[425] | 3363 | "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |
---|
| 3364 | "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |
---|
| 3365 | "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |
---|
| 3366 | "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |
---|
| 3367 | "505" / extension-code |
---|
[428] | 3368 | |
---|
[678] | 3369 | <x:ref>TE</x:ref> = <TE, defined in [Part1], Section 9.8> |
---|
[427] | 3370 | |
---|
[648] | 3371 | <x:ref>URI</x:ref> = <URI, defined in [Part1], Section 2.6> |
---|
[427] | 3372 | <x:ref>User-Agent</x:ref> = "User-Agent:" OWS User-Agent-v |
---|
| 3373 | <x:ref>User-Agent-v</x:ref> = product *( RWS ( product / comment ) ) |
---|
| 3374 | |
---|
[538] | 3375 | <x:ref>Vary</x:ref> = <Vary, defined in [Part6], Section 3.5> |
---|
[427] | 3376 | |
---|
[454] | 3377 | WWW-Authenticate = |
---|
| 3378 | <WWW-Authenticate, defined in [Part7], Section 3.4> |
---|
[428] | 3379 | |
---|
[648] | 3380 | <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [Part1], Section 2.6> |
---|
[427] | 3381 | |
---|
[688] | 3382 | <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2> |
---|
[427] | 3383 | |
---|
| 3384 | <x:ref>delta-seconds</x:ref> = 1*DIGIT |
---|
| 3385 | |
---|
| 3386 | <x:ref>expect-params</x:ref> = ";" token [ "=" ( token / quoted-string ) ] |
---|
| 3387 | <x:ref>expectation</x:ref> = "100-continue" / expectation-extension |
---|
| 3388 | <x:ref>expectation-extension</x:ref> = token [ "=" ( token / quoted-string ) |
---|
[425] | 3389 | *expect-params ] |
---|
[427] | 3390 | <x:ref>extension-code</x:ref> = 3DIGIT |
---|
| 3391 | <x:ref>extension-method</x:ref> = token |
---|
| 3392 | |
---|
| 3393 | <x:ref>mailbox</x:ref> = <mailbox, defined in [RFC5322], Section 3.4> |
---|
| 3394 | |
---|
| 3395 | <x:ref>obs-text</x:ref> = <obs-text, defined in [Part1], Section 1.2.2> |
---|
| 3396 | |
---|
[648] | 3397 | <x:ref>partial-URI</x:ref> = <partial-URI, defined in [Part1], Section 2.6> |
---|
[678] | 3398 | <x:ref>product</x:ref> = <product, defined in [Part1], Section 6.3> |
---|
[427] | 3399 | |
---|
| 3400 | <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
| 3401 | |
---|
| 3402 | <x:ref>request-header</x:ref> = Accept / Accept-Charset / Accept-Encoding / |
---|
[425] | 3403 | Accept-Language / Authorization / Expect / From / Host / If-Match / |
---|
| 3404 | If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / |
---|
| 3405 | Max-Forwards / Proxy-Authorization / Range / Referer / TE / |
---|
| 3406 | User-Agent |
---|
[427] | 3407 | <x:ref>response-header</x:ref> = Accept-Ranges / Age / Allow / ETag / Location / |
---|
[425] | 3408 | Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate |
---|
[428] | 3409 | |
---|
[427] | 3410 | <x:ref>token</x:ref> = <token, defined in [Part1], Section 1.2.2> |
---|
[454] | 3411 | </artwork> |
---|
| 3412 | </figure> |
---|
[532] | 3413 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> |
---|
| 3414 | ; Reason-Phrase defined but not used |
---|
[425] | 3415 | ; Status-Code defined but not used |
---|
| 3416 | ; request-header defined but not used |
---|
| 3417 | ; response-header defined but not used |
---|
[454] | 3418 | </artwork></figure></section> |
---|
[680] | 3419 | <?ENDINC p2-semantics.abnf-appendix ?> |
---|
[427] | 3420 | |
---|
[252] | 3421 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
[115] | 3422 | |
---|
| 3423 | <section title="Since RFC2616"> |
---|
| 3424 | <t> |
---|
| 3425 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
| 3426 | </t> |
---|
| 3427 | </section> |
---|
| 3428 | |
---|
| 3429 | <section title="Since draft-ietf-httpbis-p2-semantics-00"> |
---|
| 3430 | <t> |
---|
[116] | 3431 | Closed issues: |
---|
| 3432 | <list style="symbols"> |
---|
| 3433 | <t> |
---|
[324] | 3434 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/5"/>: |
---|
[116] | 3435 | "Via is a MUST" |
---|
| 3436 | (<eref target="http://purl.org/NET/http-errata#via-must"/>) |
---|
| 3437 | </t> |
---|
| 3438 | <t> |
---|
[324] | 3439 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/6"/>: |
---|
[116] | 3440 | "Fragments allowed in Location" |
---|
| 3441 | (<eref target="http://purl.org/NET/http-errata#location-fragments"/>) |
---|
| 3442 | </t> |
---|
| 3443 | <t> |
---|
[324] | 3444 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/10"/>: |
---|
[116] | 3445 | "Safe Methods vs Redirection" |
---|
| 3446 | (<eref target="http://purl.org/NET/http-errata#saferedirect"/>) |
---|
| 3447 | </t> |
---|
| 3448 | <t> |
---|
[324] | 3449 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/17"/>: |
---|
[116] | 3450 | "Revise description of the POST method" |
---|
| 3451 | (<eref target="http://purl.org/NET/http-errata#post"/>) |
---|
| 3452 | </t> |
---|
| 3453 | <t> |
---|
[324] | 3454 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
[152] | 3455 | "Normative and Informative references" |
---|
| 3456 | </t> |
---|
| 3457 | <t> |
---|
[324] | 3458 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>: |
---|
[116] | 3459 | "RFC2606 Compliance" |
---|
| 3460 | </t> |
---|
[129] | 3461 | <t> |
---|
[324] | 3462 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>: |
---|
[129] | 3463 | "Informative references" |
---|
| 3464 | </t> |
---|
[130] | 3465 | <t> |
---|
[324] | 3466 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/84"/>: |
---|
[130] | 3467 | "Redundant cross-references" |
---|
| 3468 | </t> |
---|
[116] | 3469 | </list> |
---|
[115] | 3470 | </t> |
---|
[116] | 3471 | <t> |
---|
| 3472 | Other changes: |
---|
| 3473 | <list style="symbols"> |
---|
| 3474 | <t> |
---|
| 3475 | Move definitions of 304 and 412 condition codes to <xref target="Part4"/> |
---|
| 3476 | </t> |
---|
| 3477 | </list> |
---|
| 3478 | </t> |
---|
[115] | 3479 | </section> |
---|
| 3480 | |
---|
[170] | 3481 | <section title="Since draft-ietf-httpbis-p2-semantics-01"> |
---|
| 3482 | <t> |
---|
[180] | 3483 | Closed issues: |
---|
| 3484 | <list style="symbols"> |
---|
| 3485 | <t> |
---|
[324] | 3486 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/21"/>: |
---|
[180] | 3487 | "PUT side effects" |
---|
| 3488 | </t> |
---|
[201] | 3489 | <t> |
---|
[324] | 3490 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/91"/>: |
---|
[201] | 3491 | "Duplicate Host header requirements" |
---|
| 3492 | </t> |
---|
[180] | 3493 | </list> |
---|
[170] | 3494 | </t> |
---|
[190] | 3495 | <t> |
---|
[324] | 3496 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
[190] | 3497 | <list style="symbols"> |
---|
| 3498 | <t> |
---|
| 3499 | Move "Product Tokens" section (back) into Part 1, as "token" is used |
---|
| 3500 | in the definition of the Upgrade header. |
---|
| 3501 | </t> |
---|
[205] | 3502 | <t> |
---|
| 3503 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
| 3504 | </t> |
---|
[210] | 3505 | <t> |
---|
[212] | 3506 | Copy definition of delta-seconds from Part6 instead of referencing it. |
---|
[210] | 3507 | </t> |
---|
[190] | 3508 | </list> |
---|
| 3509 | </t> |
---|
[115] | 3510 | </section> |
---|
| 3511 | |
---|
[252] | 3512 | <section title="Since draft-ietf-httpbis-p2-semantics-02" anchor="changes.since.02"> |
---|
[228] | 3513 | <t> |
---|
[232] | 3514 | Closed issues: |
---|
| 3515 | <list style="symbols"> |
---|
| 3516 | <t> |
---|
[324] | 3517 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/24"/>: |
---|
[240] | 3518 | "Requiring Allow in 405 responses" |
---|
| 3519 | </t> |
---|
| 3520 | <t> |
---|
[324] | 3521 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/59"/>: |
---|
[262] | 3522 | "Status Code Registry" |
---|
| 3523 | </t> |
---|
| 3524 | <t> |
---|
[324] | 3525 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/61"/>: |
---|
[237] | 3526 | "Redirection vs. Location" |
---|
| 3527 | </t> |
---|
| 3528 | <t> |
---|
[324] | 3529 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/70"/>: |
---|
[242] | 3530 | "Cacheability of 303 response" |
---|
| 3531 | </t> |
---|
| 3532 | <t> |
---|
[324] | 3533 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/76"/>: |
---|
[236] | 3534 | "305 Use Proxy" |
---|
| 3535 | </t> |
---|
| 3536 | <t> |
---|
[324] | 3537 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>: |
---|
[232] | 3538 | "Classification for Allow header" |
---|
| 3539 | </t> |
---|
[241] | 3540 | <t> |
---|
[324] | 3541 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/112"/>: |
---|
[241] | 3542 | "PUT - 'store under' vs 'store at'" |
---|
| 3543 | </t> |
---|
[232] | 3544 | </list> |
---|
[228] | 3545 | </t> |
---|
[253] | 3546 | <t> |
---|
[324] | 3547 | Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
[253] | 3548 | <list style="symbols"> |
---|
| 3549 | <t> |
---|
| 3550 | Reference RFC 3984, and update header registrations for headers defined |
---|
| 3551 | in this document. |
---|
| 3552 | </t> |
---|
| 3553 | </list> |
---|
| 3554 | </t> |
---|
[256] | 3555 | <t> |
---|
[324] | 3556 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
[260] | 3557 | <list style="symbols"> |
---|
| 3558 | <t> |
---|
| 3559 | Replace string literals when the string really is case-sensitive (method). |
---|
| 3560 | </t> |
---|
| 3561 | </list> |
---|
| 3562 | </t> |
---|
[170] | 3563 | </section> |
---|
| 3564 | |
---|
[267] | 3565 | <section title="Since draft-ietf-httpbis-p2-semantics-03" anchor="changes.since.03"> |
---|
| 3566 | <t> |
---|
[274] | 3567 | Closed issues: |
---|
| 3568 | <list style="symbols"> |
---|
| 3569 | <t> |
---|
[324] | 3570 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>: |
---|
[280] | 3571 | "OPTIONS request bodies" |
---|
| 3572 | </t> |
---|
| 3573 | <t> |
---|
[324] | 3574 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/119"/>: |
---|
[274] | 3575 | "Description of CONNECT should refer to RFC2817" |
---|
| 3576 | </t> |
---|
[300] | 3577 | <t> |
---|
[324] | 3578 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/125"/>: |
---|
[300] | 3579 | "Location Content-Location reference request/response mixup" |
---|
| 3580 | </t> |
---|
[274] | 3581 | </list> |
---|
| 3582 | </t> |
---|
| 3583 | <t> |
---|
[324] | 3584 | Ongoing work on Method Registry (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/72"/>): |
---|
[270] | 3585 | <list style="symbols"> |
---|
| 3586 | <t> |
---|
| 3587 | Added initial proposal for registration process, plus initial |
---|
| 3588 | content (non-HTTP/1.1 methods to be added by a separate specification). |
---|
| 3589 | </t> |
---|
| 3590 | </list> |
---|
[267] | 3591 | </t> |
---|
[228] | 3592 | </section> |
---|
| 3593 | |
---|
[323] | 3594 | <section title="Since draft-ietf-httpbis-p2-semantics-04" anchor="changes.since.04"> |
---|
| 3595 | <t> |
---|
[327] | 3596 | Closed issues: |
---|
| 3597 | <list style="symbols"> |
---|
| 3598 | <t> |
---|
[333] | 3599 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/103"/>: |
---|
| 3600 | "Content-*" |
---|
| 3601 | </t> |
---|
| 3602 | <t> |
---|
[327] | 3603 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: |
---|
| 3604 | "RFC 2822 is updated by RFC 5322" |
---|
| 3605 | </t> |
---|
| 3606 | </list> |
---|
[323] | 3607 | </t> |
---|
[334] | 3608 | <t> |
---|
| 3609 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
| 3610 | <list style="symbols"> |
---|
| 3611 | <t> |
---|
| 3612 | Use "/" instead of "|" for alternatives. |
---|
| 3613 | </t> |
---|
[356] | 3614 | <t> |
---|
| 3615 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
[357] | 3616 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
[356] | 3617 | </t> |
---|
| 3618 | <t> |
---|
[357] | 3619 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
| 3620 | header value format definitions. |
---|
[356] | 3621 | </t> |
---|
[334] | 3622 | </list> |
---|
| 3623 | </t> |
---|
[267] | 3624 | </section> |
---|
| 3625 | |
---|
[382] | 3626 | <section title="Since draft-ietf-httpbis-p2-semantics-05" anchor="changes.since.05"> |
---|
| 3627 | <t> |
---|
[398] | 3628 | Closed issues: |
---|
| 3629 | <list style="symbols"> |
---|
| 3630 | <t> |
---|
| 3631 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>: |
---|
| 3632 | "Reason-Phrase BNF" |
---|
| 3633 | </t> |
---|
| 3634 | </list> |
---|
[382] | 3635 | </t> |
---|
[421] | 3636 | <t> |
---|
[543] | 3637 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
[421] | 3638 | <list style="symbols"> |
---|
| 3639 | <t> |
---|
[424] | 3640 | Add appendix containing collected and expanded ABNF, reorganize ABNF introduction. |
---|
[421] | 3641 | </t> |
---|
| 3642 | </list> |
---|
| 3643 | </t> |
---|
[323] | 3644 | </section> |
---|
| 3645 | |
---|
[547] | 3646 | <section title="Since draft-ietf-httpbis-p2-semantics-06" anchor="changes.since.06"> |
---|
| 3647 | <t> |
---|
[579] | 3648 | Closed issues: |
---|
| 3649 | <list style="symbols"> |
---|
| 3650 | <t> |
---|
[593] | 3651 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/144"/>: |
---|
| 3652 | "Clarify when Referer is sent" |
---|
| 3653 | </t> |
---|
| 3654 | <t> |
---|
[579] | 3655 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/164"/>: |
---|
| 3656 | "status codes vs methods" |
---|
| 3657 | </t> |
---|
[591] | 3658 | <t> |
---|
| 3659 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/170"/>: |
---|
| 3660 | "Do not require "updates" relation for specs that register status codes or method names" |
---|
| 3661 | </t> |
---|
[579] | 3662 | </list> |
---|
[547] | 3663 | </t> |
---|
[382] | 3664 | </section> |
---|
| 3665 | |
---|
[604] | 3666 | <section title="Since draft-ietf-httpbis-p2-semantics-07" anchor="changes.since.07"> |
---|
| 3667 | <t> |
---|
[614] | 3668 | Closed issues: |
---|
| 3669 | <list style="symbols"> |
---|
| 3670 | <t> |
---|
[658] | 3671 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/27"/>: |
---|
| 3672 | "Idempotency" |
---|
| 3673 | </t> |
---|
| 3674 | <t> |
---|
| 3675 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/33"/>: |
---|
| 3676 | "TRACE security considerations" |
---|
| 3677 | </t> |
---|
| 3678 | <t> |
---|
[695] | 3679 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>: |
---|
| 3680 | "Clarify rules for determining what entities a response carries" |
---|
| 3681 | </t> |
---|
| 3682 | <t> |
---|
[614] | 3683 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/140"/>: |
---|
| 3684 | "update note citing RFC 1945 and 2068" |
---|
| 3685 | </t> |
---|
[629] | 3686 | <t> |
---|
| 3687 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/182"/>: |
---|
| 3688 | "update note about redirect limit" |
---|
| 3689 | </t> |
---|
[632] | 3690 | <t> |
---|
| 3691 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/191"/>: |
---|
| 3692 | "Location header ABNF should use 'URI'" |
---|
| 3693 | </t> |
---|
[665] | 3694 | <t> |
---|
| 3695 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/192"/>: |
---|
| 3696 | "fragments in Location vs status 303" |
---|
| 3697 | </t> |
---|
[700] | 3698 | <t> |
---|
| 3699 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>: |
---|
| 3700 | "move IANA registrations for optional status codes" |
---|
| 3701 | </t> |
---|
[614] | 3702 | </list> |
---|
[604] | 3703 | </t> |
---|
[547] | 3704 | </section> |
---|
| 3705 | |
---|
[604] | 3706 | </section> |
---|
| 3707 | |
---|
[8] | 3708 | </back> |
---|
| 3709 | </rfc> |
---|