1 | <?xml version="1.0" encoding="utf-8"?> |
---|
2 | <!DOCTYPE rfc [ |
---|
3 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
4 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
5 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
6 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
7 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
8 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
9 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
10 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
11 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
12 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
13 | <!ENTITY ID-VERSION "latest"> |
---|
14 | <!ENTITY messaging "[Part 1]"> |
---|
15 | <!ENTITY payload "[Part 3]"> |
---|
16 | <!ENTITY conditional "[Part 4]"> |
---|
17 | <!ENTITY range "[Part 5]"> |
---|
18 | <!ENTITY caching "[Part 6]"> |
---|
19 | <!ENTITY auth "[Part 7]"> |
---|
20 | <!ENTITY content-negotiation "[Part 3]"> |
---|
21 | <!ENTITY diff2045entity "[Part 3]"> |
---|
22 | <!ENTITY uri "[Part 1]"> |
---|
23 | <!ENTITY http-url "[Part 1]"> |
---|
24 | <!ENTITY http-version "[Part 1]"> |
---|
25 | <!ENTITY use100 "[Part 1]"> |
---|
26 | <!ENTITY qvalue "[Part 3]"> |
---|
27 | <!ENTITY header-accept "[Part 3]"> |
---|
28 | <!ENTITY header-accept-charset "[Part 3]"> |
---|
29 | <!ENTITY header-accept-encoding "[Part 3]"> |
---|
30 | <!ENTITY header-accept-language "[Part 3]"> |
---|
31 | <!ENTITY header-accept-ranges "[Part 3]"> |
---|
32 | <!ENTITY header-age "[Part 6]"> |
---|
33 | <!ENTITY header-authorization "[Part 7]"> |
---|
34 | <!ENTITY header-cache-control "[Part 6]"> |
---|
35 | <!ENTITY header-content-location "[Part 3]"> |
---|
36 | <!ENTITY header-content-range "[Part 5]"> |
---|
37 | <!ENTITY header-etag "[Part 4]"> |
---|
38 | <!ENTITY header-expires "[Part 6]"> |
---|
39 | <!ENTITY header-host "[Part 1]"> |
---|
40 | <!ENTITY header-if-match "[Part 4]"> |
---|
41 | <!ENTITY header-if-modified-since "[Part 4]"> |
---|
42 | <!ENTITY header-if-none-match "[Part 4]"> |
---|
43 | <!ENTITY header-if-range "[Part 5]"> |
---|
44 | <!ENTITY header-if-unmodified-since "[Part 4]"> |
---|
45 | <!ENTITY header-pragma "[Part 6]"> |
---|
46 | <!ENTITY header-proxy-authenticate "[Part 7]"> |
---|
47 | <!ENTITY header-proxy-authorization "[Part 7]"> |
---|
48 | <!ENTITY header-range "[Part 5]"> |
---|
49 | <!ENTITY header-upgrade "[Part 1]"> |
---|
50 | <!ENTITY header-te "[Part 1]"> |
---|
51 | <!ENTITY header-vary "[Part 6]"> |
---|
52 | <!ENTITY header-via "[Part 1]"> |
---|
53 | <!ENTITY header-warning "[Part 6]"> |
---|
54 | <!ENTITY header-www-authenticate "[Part 7]"> |
---|
55 | <!ENTITY message-body "[Part 1]"> |
---|
56 | ]> |
---|
57 | <?rfc toc="yes" ?> |
---|
58 | <?rfc symrefs="yes" ?> |
---|
59 | <?rfc sortrefs="yes" ?> |
---|
60 | <?rfc compact="yes"?> |
---|
61 | <?rfc subcompact="no" ?> |
---|
62 | <?rfc linkmailto="no" ?> |
---|
63 | <?rfc editing="no" ?> |
---|
64 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
65 | <?rfc-ext include-references-in-index="yes" ?> |
---|
66 | <rfc obsoletes="2068, 2616, 2617" category="std" |
---|
67 | ipr="full3978" docName="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" |
---|
68 | xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit"> |
---|
69 | <front> |
---|
70 | |
---|
71 | <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> |
---|
72 | |
---|
73 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
74 | <organization abbrev="Day Software">Day Software</organization> |
---|
75 | <address> |
---|
76 | <postal> |
---|
77 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
78 | <city>Newport Beach</city> |
---|
79 | <region>CA</region> |
---|
80 | <code>92660</code> |
---|
81 | <country>USA</country> |
---|
82 | </postal> |
---|
83 | <phone>+1-949-706-5300</phone> |
---|
84 | <facsimile>+1-949-706-5305</facsimile> |
---|
85 | <email>fielding@gbiv.com</email> |
---|
86 | <uri>http://roy.gbiv.com/</uri> |
---|
87 | </address> |
---|
88 | </author> |
---|
89 | |
---|
90 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
91 | <organization>One Laptop per Child</organization> |
---|
92 | <address> |
---|
93 | <postal> |
---|
94 | <street>21 Oak Knoll Road</street> |
---|
95 | <city>Carlisle</city> |
---|
96 | <region>MA</region> |
---|
97 | <code>01741</code> |
---|
98 | <country>USA</country> |
---|
99 | </postal> |
---|
100 | <email>jg@laptop.org</email> |
---|
101 | <uri>http://www.laptop.org/</uri> |
---|
102 | </address> |
---|
103 | </author> |
---|
104 | |
---|
105 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
106 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
107 | <address> |
---|
108 | <postal> |
---|
109 | <street>HP Labs, Large Scale Systems Group</street> |
---|
110 | <street>1501 Page Mill Road, MS 1177</street> |
---|
111 | <city>Palo Alto</city> |
---|
112 | <region>CA</region> |
---|
113 | <code>94304</code> |
---|
114 | <country>USA</country> |
---|
115 | </postal> |
---|
116 | <email>JeffMogul@acm.org</email> |
---|
117 | </address> |
---|
118 | </author> |
---|
119 | |
---|
120 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
121 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
122 | <address> |
---|
123 | <postal> |
---|
124 | <street>1 Microsoft Way</street> |
---|
125 | <city>Redmond</city> |
---|
126 | <region>WA</region> |
---|
127 | <code>98052</code> |
---|
128 | <country>USA</country> |
---|
129 | </postal> |
---|
130 | <email>henrikn@microsoft.com</email> |
---|
131 | </address> |
---|
132 | </author> |
---|
133 | |
---|
134 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
135 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
136 | <address> |
---|
137 | <postal> |
---|
138 | <street>345 Park Ave</street> |
---|
139 | <city>San Jose</city> |
---|
140 | <region>CA</region> |
---|
141 | <code>95110</code> |
---|
142 | <country>USA</country> |
---|
143 | </postal> |
---|
144 | <email>LMM@acm.org</email> |
---|
145 | <uri>http://larry.masinter.net/</uri> |
---|
146 | </address> |
---|
147 | </author> |
---|
148 | |
---|
149 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
150 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
151 | <address> |
---|
152 | <postal> |
---|
153 | <street>1 Microsoft Way</street> |
---|
154 | <city>Redmond</city> |
---|
155 | <region>WA</region> |
---|
156 | <code>98052</code> |
---|
157 | </postal> |
---|
158 | <email>paulle@microsoft.com</email> |
---|
159 | </address> |
---|
160 | </author> |
---|
161 | |
---|
162 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
163 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
164 | <address> |
---|
165 | <postal> |
---|
166 | <street>MIT Laboratory for Computer Science</street> |
---|
167 | <street>545 Technology Square</street> |
---|
168 | <city>Cambridge</city> |
---|
169 | <region>MA</region> |
---|
170 | <code>02139</code> |
---|
171 | <country>USA</country> |
---|
172 | </postal> |
---|
173 | <facsimile>+1 (617) 258 8682</facsimile> |
---|
174 | <email>timbl@w3.org</email> |
---|
175 | </address> |
---|
176 | </author> |
---|
177 | |
---|
178 | <date month="December" year="2007"/> |
---|
179 | |
---|
180 | <abstract> |
---|
181 | <t> |
---|
182 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
183 | protocol for distributed, collaborative, hypermedia information |
---|
184 | systems. HTTP has been in use by the World Wide Web global information |
---|
185 | initiative since 1990. This document is Part 2 of the eight-part specification |
---|
186 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
187 | updates RFC 2616 and RFC 2617. Part 2 defines the semantics of HTTP messages |
---|
188 | as expressed by request methods, request-header fields, response status codes, |
---|
189 | and response-header fields. |
---|
190 | </t> |
---|
191 | </abstract> |
---|
192 | </front> |
---|
193 | <middle> |
---|
194 | <section title="Introduction" anchor="introduction"> |
---|
195 | <t> |
---|
196 | This document will define aspects of HTTP related to request and response |
---|
197 | semantics. Right now it only includes the extracted relevant sections of |
---|
198 | RFC 2616 with only minor edits. |
---|
199 | </t> |
---|
200 | <t> |
---|
201 | The HTTP protocol is a request/response protocol. A client sends a |
---|
202 | request to the server in the form of a request method, URI, and |
---|
203 | protocol version, followed by a MIME-like message containing request |
---|
204 | modifiers, client information, and possible body content over a |
---|
205 | connection with a server. The server responds with a status line, |
---|
206 | including the message's protocol version and a success or error code, |
---|
207 | followed by a MIME-like message containing server information, entity |
---|
208 | metainformation, and possible entity-body content. The relationship |
---|
209 | between HTTP and MIME is described in &diff2045entity;. |
---|
210 | </t> |
---|
211 | </section> |
---|
212 | |
---|
213 | <section title="Product Tokens" anchor="product.tokens"> |
---|
214 | <t> |
---|
215 | Product tokens are used to allow communicating applications to |
---|
216 | identify themselves by software name and version. Most fields using |
---|
217 | product tokens also allow sub-products which form a significant part |
---|
218 | of the application to be listed, separated by white space. By |
---|
219 | convention, the products are listed in order of their significance |
---|
220 | for identifying the application. |
---|
221 | </t> |
---|
222 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> |
---|
223 | product = token ["/" product-version] |
---|
224 | product-version = token |
---|
225 | </artwork></figure> |
---|
226 | <t> |
---|
227 | Examples: |
---|
228 | </t> |
---|
229 | <figure><artwork type="example"> |
---|
230 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
231 | Server: Apache/0.8.4 |
---|
232 | </artwork></figure> |
---|
233 | <t> |
---|
234 | Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be |
---|
235 | used for advertising or other non-essential information. Although any |
---|
236 | token character &MAY; appear in a product-version, this token &SHOULD; |
---|
237 | only be used for a version identifier (i.e., successive versions of |
---|
238 | the same product &SHOULD; only differ in the product-version portion of |
---|
239 | the product value). |
---|
240 | </t> |
---|
241 | </section> |
---|
242 | |
---|
243 | <section title="Method" anchor="method"> |
---|
244 | <t> |
---|
245 | The Method token indicates the method to be performed on the |
---|
246 | resource identified by the Request-URI. The method is case-sensitive. |
---|
247 | </t> |
---|
248 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> |
---|
249 | Method = "OPTIONS" ; <xref target="OPTIONS"/> |
---|
250 | | "GET" ; <xref target="GET"/> |
---|
251 | | "HEAD" ; <xref target="HEAD"/> |
---|
252 | | "POST" ; <xref target="POST"/> |
---|
253 | | "PUT" ; <xref target="PUT"/> |
---|
254 | | "DELETE" ; <xref target="DELETE"/> |
---|
255 | | "TRACE" ; <xref target="TRACE"/> |
---|
256 | | "CONNECT" ; <xref target="CONNECT"/> |
---|
257 | | extension-method |
---|
258 | extension-method = token |
---|
259 | </artwork></figure> |
---|
260 | <t> |
---|
261 | The list of methods allowed by a resource can be specified in an |
---|
262 | Allow header field (<xref target="header.allow"/>). The return code of the response |
---|
263 | always notifies the client whether a method is currently allowed on a |
---|
264 | resource, since the set of allowed methods can change dynamically. An |
---|
265 | origin server &SHOULD; return the status code 405 (Method Not Allowed) |
---|
266 | if the method is known by the origin server but not allowed for the |
---|
267 | requested resource, and 501 (Not Implemented) if the method is |
---|
268 | unrecognized or not implemented by the origin server. The methods GET |
---|
269 | and HEAD &MUST; be supported by all general-purpose servers. All other |
---|
270 | methods are &OPTIONAL;; however, if the above methods are implemented, |
---|
271 | they &MUST; be implemented with the same semantics as those specified |
---|
272 | in <xref target="method.definitions"/>. |
---|
273 | </t> |
---|
274 | </section> |
---|
275 | |
---|
276 | <section title="Request Header Fields" anchor="request.header.fields"> |
---|
277 | <t> |
---|
278 | The request-header fields allow the client to pass additional |
---|
279 | information about the request, and about the client itself, to the |
---|
280 | server. These fields act as request modifiers, with semantics |
---|
281 | equivalent to the parameters on a programming language method |
---|
282 | invocation. |
---|
283 | </t> |
---|
284 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-header"/> |
---|
285 | request-header = Accept ; &header-accept; |
---|
286 | | Accept-Charset ; &header-accept-charset; |
---|
287 | | Accept-Encoding ; &header-accept-encoding; |
---|
288 | | Accept-Language ; &header-accept-language; |
---|
289 | | Authorization ; &header-authorization; |
---|
290 | | Expect ; <xref target="header.expect"/> |
---|
291 | | From ; <xref target="header.from"/> |
---|
292 | | Host ; &header-host; |
---|
293 | | If-Match ; &header-if-match; |
---|
294 | | If-Modified-Since ; &header-if-modified-since; |
---|
295 | | If-None-Match ; &header-if-none-match; |
---|
296 | | If-Range ; &header-if-range; |
---|
297 | | If-Unmodified-Since ; &header-if-unmodified-since; |
---|
298 | | Max-Forwards ; <xref target="header.max-forwards"/> |
---|
299 | | Proxy-Authorization ; &header-proxy-authorization; |
---|
300 | | Range ; &header-range; |
---|
301 | | Referer ; <xref target="header.referer"/> |
---|
302 | | TE ; &header-te; |
---|
303 | | User-Agent ; <xref target="header.user-agent"/> |
---|
304 | </artwork></figure> |
---|
305 | <t> |
---|
306 | Request-header field names can be extended reliably only in |
---|
307 | combination with a change in the protocol version. However, new or |
---|
308 | experimental header fields &MAY; be given the semantics of request-header |
---|
309 | fields if all parties in the communication recognize them to |
---|
310 | be request-header fields. Unrecognized header fields are treated as |
---|
311 | entity-header fields. |
---|
312 | </t> |
---|
313 | </section> |
---|
314 | |
---|
315 | <section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase"> |
---|
316 | <t> |
---|
317 | The Status-Code element is a 3-digit integer result code of the |
---|
318 | attempt to understand and satisfy the request. These codes are fully |
---|
319 | defined in <xref target="status.codes"/>. The Reason-Phrase is intended to give a short |
---|
320 | textual description of the Status-Code. The Status-Code is intended |
---|
321 | for use by automata and the Reason-Phrase is intended for the human |
---|
322 | user. The client is not required to examine or display the Reason-Phrase. |
---|
323 | </t> |
---|
324 | <t> |
---|
325 | The individual values of the numeric status codes defined for |
---|
326 | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |
---|
327 | presented below. The reason phrases listed here are only |
---|
328 | recommendations -- they &MAY; be replaced by local equivalents without |
---|
329 | affecting the protocol. |
---|
330 | </t> |
---|
331 | <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"/> |
---|
332 | Status-Code = |
---|
333 | "100" ; <xref target="status.100"/>: Continue |
---|
334 | | "101" ; <xref target="status.101"/>: Switching Protocols |
---|
335 | | "200" ; <xref target="status.200"/>: OK |
---|
336 | | "201" ; <xref target="status.201"/>: Created |
---|
337 | | "202" ; <xref target="status.202"/>: Accepted |
---|
338 | | "203" ; <xref target="status.203"/>: Non-Authoritative Information |
---|
339 | | "204" ; <xref target="status.204"/>: No Content |
---|
340 | | "205" ; <xref target="status.205"/>: Reset Content |
---|
341 | | "206" ; <xref target="status.206"/>: Partial Content |
---|
342 | | "300" ; <xref target="status.300"/>: Multiple Choices |
---|
343 | | "301" ; <xref target="status.301"/>: Moved Permanently |
---|
344 | | "302" ; <xref target="status.302"/>: Found |
---|
345 | | "303" ; <xref target="status.303"/>: See Other |
---|
346 | | "304" ; <xref target="status.304"/>: Not Modified |
---|
347 | | "305" ; <xref target="status.305"/>: Use Proxy |
---|
348 | | "307" ; <xref target="status.307"/>: Temporary Redirect |
---|
349 | | "400" ; <xref target="status.400"/>: Bad Request |
---|
350 | | "401" ; <xref target="status.401"/>: Unauthorized |
---|
351 | | "402" ; <xref target="status.402"/>: Payment Required |
---|
352 | | "403" ; <xref target="status.403"/>: Forbidden |
---|
353 | | "404" ; <xref target="status.404"/>: Not Found |
---|
354 | | "405" ; <xref target="status.405"/>: Method Not Allowed |
---|
355 | | "406" ; <xref target="status.406"/>: Not Acceptable |
---|
356 | | "407" ; <xref target="status.407"/>: Proxy Authentication Required |
---|
357 | | "408" ; <xref target="status.408"/>: Request Time-out |
---|
358 | | "409" ; <xref target="status.409"/>: Conflict |
---|
359 | | "410" ; <xref target="status.410"/>: Gone |
---|
360 | | "411" ; <xref target="status.411"/>: Length Required |
---|
361 | | "412" ; <xref target="status.412"/>: Precondition Failed |
---|
362 | | "413" ; <xref target="status.413"/>: Request Entity Too Large |
---|
363 | | "414" ; <xref target="status.414"/>: Request-URI Too Large |
---|
364 | | "415" ; <xref target="status.415"/>: Unsupported Media Type |
---|
365 | | "416" ; <xref target="status.416"/>: Requested range not satisfiable |
---|
366 | | "417" ; <xref target="status.417"/>: Expectation Failed |
---|
367 | | "500" ; <xref target="status.500"/>: Internal Server Error |
---|
368 | | "501" ; <xref target="status.501"/>: Not Implemented |
---|
369 | | "502" ; <xref target="status.502"/>: Bad Gateway |
---|
370 | | "503" ; <xref target="status.503"/>: Service Unavailable |
---|
371 | | "504" ; <xref target="status.504"/>: Gateway Time-out |
---|
372 | | "505" ; <xref target="status.505"/>: HTTP Version not supported |
---|
373 | | extension-code |
---|
374 | |
---|
375 | extension-code = 3DIGIT |
---|
376 | Reason-Phrase = *<TEXT, excluding CR, LF> |
---|
377 | </artwork></figure> |
---|
378 | <t> |
---|
379 | HTTP status codes are extensible. HTTP applications are not required |
---|
380 | to understand the meaning of all registered status codes, though such |
---|
381 | understanding is obviously desirable. However, applications &MUST; |
---|
382 | understand the class of any status code, as indicated by the first |
---|
383 | digit, and treat any unrecognized response as being equivalent to the |
---|
384 | x00 status code of that class, with the exception that an |
---|
385 | unrecognized response &MUST-NOT; be cached. For example, if an |
---|
386 | unrecognized status code of 431 is received by the client, it can |
---|
387 | safely assume that there was something wrong with its request and |
---|
388 | treat the response as if it had received a 400 status code. In such |
---|
389 | cases, user agents &SHOULD; present to the user the entity returned |
---|
390 | with the response, since that entity is likely to include human-readable |
---|
391 | information which will explain the unusual status. |
---|
392 | </t> |
---|
393 | </section> |
---|
394 | |
---|
395 | <section title="Response Header Fields" anchor="response.header.fields"> |
---|
396 | <t> |
---|
397 | The response-header fields allow the server to pass additional |
---|
398 | information about the response which cannot be placed in the Status-Line. |
---|
399 | These header fields give information about the server and about |
---|
400 | further access to the resource identified by the Request-URI. |
---|
401 | </t> |
---|
402 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> |
---|
403 | response-header = Accept-Ranges ; &header-accept-ranges; |
---|
404 | | Age ; &header-age; |
---|
405 | | ETag ; &header-etag; |
---|
406 | | Location ; <xref target="header.location"/> |
---|
407 | | Proxy-Authenticate ; &header-proxy-authenticate; |
---|
408 | | Retry-After ; <xref target="header.retry-after"/> |
---|
409 | | Server ; <xref target="header.server"/> |
---|
410 | | Vary ; &header-vary; |
---|
411 | | WWW-Authenticate ; &header-www-authenticate; |
---|
412 | </artwork></figure> |
---|
413 | <t> |
---|
414 | Response-header field names can be extended reliably only in |
---|
415 | combination with a change in the protocol version. However, new or |
---|
416 | experimental header fields &MAY; be given the semantics of response-header |
---|
417 | fields if all parties in the communication recognize them to |
---|
418 | be response-header fields. Unrecognized header fields are treated as |
---|
419 | entity-header fields. |
---|
420 | </t> |
---|
421 | </section> |
---|
422 | |
---|
423 | <section title="Entity" anchor="entity"> |
---|
424 | <t> |
---|
425 | Request and Response messages &MAY; transfer an entity if not otherwise |
---|
426 | restricted by the request method or response status code. An entity |
---|
427 | consists of entity-header fields and an entity-body, although some |
---|
428 | responses will only include the entity-headers. HTTP entity-body and |
---|
429 | entity-header fields are defined in &payload;. |
---|
430 | </t> |
---|
431 | <t> |
---|
432 | An entity-body is only present in a message when a message-body is |
---|
433 | present, as described in &message-body;. The entity-body is obtained |
---|
434 | from the message-body by decoding any Transfer-Encoding that might |
---|
435 | have been applied to ensure safe and proper transfer of the message. |
---|
436 | </t> |
---|
437 | </section> |
---|
438 | |
---|
439 | |
---|
440 | <section title="Method Definitions" anchor="method.definitions"> |
---|
441 | <t> |
---|
442 | The set of common methods for HTTP/1.1 is defined below. Although |
---|
443 | this set can be expanded, additional methods cannot be assumed to |
---|
444 | share the same semantics for separately extended clients and servers. |
---|
445 | |
---|
446 | The Host request-header field (&header-host;) &MUST; accompany all |
---|
447 | HTTP/1.1 requests. |
---|
448 | </t> |
---|
449 | |
---|
450 | <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent"> |
---|
451 | |
---|
452 | <section title="Safe Methods" anchor="safe.methods"> |
---|
453 | <t> |
---|
454 | Implementors should be aware that the software represents the user in |
---|
455 | their interactions over the Internet, and should be careful to allow |
---|
456 | the user to be aware of any actions they might take which may have an |
---|
457 | unexpected significance to themselves or others. |
---|
458 | </t> |
---|
459 | <t> |
---|
460 | In particular, the convention has been established that the GET and |
---|
461 | HEAD methods &SHOULD-NOT; have the significance of taking an action |
---|
462 | other than retrieval. These methods ought to be considered "safe". |
---|
463 | This allows user agents to represent other methods, such as POST, PUT |
---|
464 | and DELETE, in a special way, so that the user is made aware of the |
---|
465 | fact that a possibly unsafe action is being requested. |
---|
466 | </t> |
---|
467 | <t> |
---|
468 | Naturally, it is not possible to ensure that the server does not |
---|
469 | generate side-effects as a result of performing a GET request; in |
---|
470 | fact, some dynamic resources consider that a feature. The important |
---|
471 | distinction here is that the user did not request the side-effects, |
---|
472 | so therefore cannot be held accountable for them. |
---|
473 | </t> |
---|
474 | </section> |
---|
475 | |
---|
476 | <section title="Idempotent Methods" anchor="idempotent.methods"> |
---|
477 | <t> |
---|
478 | Methods can also have the property of "idempotence" in that (aside |
---|
479 | from error or expiration issues) the side-effects of N > 0 identical |
---|
480 | requests is the same as for a single request. The methods GET, HEAD, |
---|
481 | PUT and DELETE share this property. Also, the methods OPTIONS and |
---|
482 | TRACE &SHOULD-NOT; have side effects, and so are inherently idempotent. |
---|
483 | </t> |
---|
484 | <t> |
---|
485 | However, it is possible that a sequence of several requests is non-idempotent, |
---|
486 | even if all of the methods executed in that sequence are |
---|
487 | idempotent. (A sequence is idempotent if a single execution of the |
---|
488 | entire sequence always yields a result that is not changed by a |
---|
489 | reexecution of all, or part, of that sequence.) For example, a |
---|
490 | sequence is non-idempotent if its result depends on a value that is |
---|
491 | later modified in the same sequence. |
---|
492 | </t> |
---|
493 | <t> |
---|
494 | A sequence that never has side effects is idempotent, by definition |
---|
495 | (provided that no concurrent operations are being executed on the |
---|
496 | same set of resources). |
---|
497 | </t> |
---|
498 | </section> |
---|
499 | </section> |
---|
500 | |
---|
501 | <section title="OPTIONS" anchor="OPTIONS"> |
---|
502 | <iref primary="true" item="OPTIONS method" x:for-anchor=""/> |
---|
503 | <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> |
---|
504 | <t> |
---|
505 | The OPTIONS method represents a request for information about the |
---|
506 | communication options available on the request/response chain |
---|
507 | identified by the Request-URI. This method allows the client to |
---|
508 | determine the options and/or requirements associated with a resource, |
---|
509 | or the capabilities of a server, without implying a resource action |
---|
510 | or initiating a resource retrieval. |
---|
511 | </t> |
---|
512 | <t> |
---|
513 | Responses to this method are not cacheable. |
---|
514 | </t> |
---|
515 | <t> |
---|
516 | If the OPTIONS request includes an entity-body (as indicated by the |
---|
517 | presence of Content-Length or Transfer-Encoding), then the media type |
---|
518 | &MUST; be indicated by a Content-Type field. Although this |
---|
519 | specification does not define any use for such a body, future |
---|
520 | extensions to HTTP might use the OPTIONS body to make more detailed |
---|
521 | queries on the server. A server that does not support such an |
---|
522 | extension &MAY; discard the request body. |
---|
523 | </t> |
---|
524 | <t> |
---|
525 | If the Request-URI is an asterisk ("*"), the OPTIONS request is |
---|
526 | intended to apply to the server in general rather than to a specific |
---|
527 | resource. Since a server's communication options typically depend on |
---|
528 | the resource, the "*" request is only useful as a "ping" or "no-op" |
---|
529 | type of method; it does nothing beyond allowing the client to test |
---|
530 | the capabilities of the server. For example, this can be used to test |
---|
531 | a proxy for HTTP/1.1 compliance (or lack thereof). |
---|
532 | </t> |
---|
533 | <t> |
---|
534 | If the Request-URI is not an asterisk, the OPTIONS request applies |
---|
535 | only to the options that are available when communicating with that |
---|
536 | resource. |
---|
537 | </t> |
---|
538 | <t> |
---|
539 | A 200 response &SHOULD; include any header fields that indicate |
---|
540 | optional features implemented by the server and applicable to that |
---|
541 | resource (e.g., Allow), possibly including extensions not defined by |
---|
542 | this specification. The response body, if any, &SHOULD; also include |
---|
543 | information about the communication options. The format for such a |
---|
544 | body is not defined by this specification, but might be defined by |
---|
545 | future extensions to HTTP. Content negotiation &MAY; be used to select |
---|
546 | the appropriate response format. If no response body is included, the |
---|
547 | response &MUST; include a Content-Length field with a field-value of |
---|
548 | "0". |
---|
549 | </t> |
---|
550 | <t> |
---|
551 | The Max-Forwards request-header field &MAY; be used to target a |
---|
552 | specific proxy in the request chain. When a proxy receives an OPTIONS |
---|
553 | request on an absoluteURI for which request forwarding is permitted, |
---|
554 | the proxy &MUST; check for a Max-Forwards field. If the Max-Forwards |
---|
555 | field-value is zero ("0"), the proxy &MUST-NOT; forward the message; |
---|
556 | instead, the proxy &SHOULD; respond with its own communication options. |
---|
557 | If the Max-Forwards field-value is an integer greater than zero, the |
---|
558 | proxy &MUST; decrement the field-value when it forwards the request. If |
---|
559 | no Max-Forwards field is present in the request, then the forwarded |
---|
560 | request &MUST-NOT; include a Max-Forwards field. |
---|
561 | </t> |
---|
562 | </section> |
---|
563 | |
---|
564 | <section title="GET" anchor="GET"> |
---|
565 | <iref primary="true" item="GET method" x:for-anchor=""/> |
---|
566 | <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> |
---|
567 | <t> |
---|
568 | The GET method means retrieve whatever information (in the form of an |
---|
569 | entity) is identified by the Request-URI. If the Request-URI refers |
---|
570 | to a data-producing process, it is the produced data which shall be |
---|
571 | returned as the entity in the response and not the source text of the |
---|
572 | process, unless that text happens to be the output of the process. |
---|
573 | </t> |
---|
574 | <t> |
---|
575 | The semantics of the GET method change to a "conditional GET" if the |
---|
576 | request message includes an If-Modified-Since, If-Unmodified-Since, |
---|
577 | If-Match, If-None-Match, or If-Range header field. A conditional GET |
---|
578 | method requests that the entity be transferred only under the |
---|
579 | circumstances described by the conditional header field(s). The |
---|
580 | conditional GET method is intended to reduce unnecessary network |
---|
581 | usage by allowing cached entities to be refreshed without requiring |
---|
582 | multiple requests or transferring data already held by the client. |
---|
583 | </t> |
---|
584 | <t> |
---|
585 | The semantics of the GET method change to a "partial GET" if the |
---|
586 | request message includes a Range header field. A partial GET requests |
---|
587 | that only part of the entity be transferred, as described in &header-range;. |
---|
588 | The partial GET method is intended to reduce unnecessary |
---|
589 | network usage by allowing partially-retrieved entities to be |
---|
590 | completed without transferring data already held by the client. |
---|
591 | </t> |
---|
592 | <t> |
---|
593 | The response to a GET request is cacheable if and only if it meets |
---|
594 | the requirements for HTTP caching described in &caching;. |
---|
595 | </t> |
---|
596 | <t> |
---|
597 | See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms. |
---|
598 | </t> |
---|
599 | </section> |
---|
600 | |
---|
601 | <section title="HEAD" anchor="HEAD"> |
---|
602 | <iref primary="true" item="HEAD method" x:for-anchor=""/> |
---|
603 | <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/> |
---|
604 | <t> |
---|
605 | The HEAD method is identical to GET except that the server &MUST-NOT; |
---|
606 | return a message-body in the response. The metainformation contained |
---|
607 | in the HTTP headers in response to a HEAD request &SHOULD; be identical |
---|
608 | to the information sent in response to a GET request. This method can |
---|
609 | be used for obtaining metainformation about the entity implied by the |
---|
610 | request without transferring the entity-body itself. This method is |
---|
611 | often used for testing hypertext links for validity, accessibility, |
---|
612 | and recent modification. |
---|
613 | </t> |
---|
614 | <t> |
---|
615 | The response to a HEAD request &MAY; be cacheable in the sense that the |
---|
616 | information contained in the response &MAY; be used to update a |
---|
617 | previously cached entity from that resource. If the new field values |
---|
618 | indicate that the cached entity differs from the current entity (as |
---|
619 | would be indicated by a change in Content-Length, Content-MD5, ETag |
---|
620 | or Last-Modified), then the cache &MUST; treat the cache entry as |
---|
621 | stale. |
---|
622 | </t> |
---|
623 | </section> |
---|
624 | |
---|
625 | <section title="POST" anchor="POST"> |
---|
626 | <iref primary="true" item="POST method" x:for-anchor=""/> |
---|
627 | <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/> |
---|
628 | <t> |
---|
629 | The POST method is used to request that the origin server accept the |
---|
630 | entity enclosed in the request as a new subordinate of the resource |
---|
631 | identified by the Request-URI in the Request-Line. POST is designed |
---|
632 | to allow a uniform method to cover the following functions: |
---|
633 | <list style="symbols"> |
---|
634 | <t> |
---|
635 | Annotation of existing resources; |
---|
636 | </t> |
---|
637 | <t> |
---|
638 | Posting a message to a bulletin board, newsgroup, mailing list, |
---|
639 | or similar group of articles; |
---|
640 | </t> |
---|
641 | <t> |
---|
642 | Providing a block of data, such as the result of submitting a |
---|
643 | form, to a data-handling process; |
---|
644 | </t> |
---|
645 | <t> |
---|
646 | Extending a database through an append operation. |
---|
647 | </t> |
---|
648 | </list> |
---|
649 | </t> |
---|
650 | <t> |
---|
651 | The actual function performed by the POST method is determined by the |
---|
652 | server and is usually dependent on the Request-URI. The posted entity |
---|
653 | is subordinate to that URI in the same way that a file is subordinate |
---|
654 | to a directory containing it, a news article is subordinate to a |
---|
655 | newsgroup to which it is posted, or a record is subordinate to a |
---|
656 | database. |
---|
657 | </t> |
---|
658 | <t> |
---|
659 | The action performed by the POST method might not result in a |
---|
660 | resource that can be identified by a URI. In this case, either 200 |
---|
661 | (OK) or 204 (No Content) is the appropriate response status, |
---|
662 | depending on whether or not the response includes an entity that |
---|
663 | describes the result. |
---|
664 | </t> |
---|
665 | <t> |
---|
666 | If a resource has been created on the origin server, the response |
---|
667 | &SHOULD; be 201 (Created) and contain an entity which describes the |
---|
668 | status of the request and refers to the new resource, and a Location |
---|
669 | header (see <xref target="header.location"/>). |
---|
670 | </t> |
---|
671 | <t> |
---|
672 | Responses to this method are not cacheable, unless the response |
---|
673 | includes appropriate Cache-Control or Expires header fields. However, |
---|
674 | the 303 (See Other) response can be used to direct the user agent to |
---|
675 | retrieve a cacheable resource. |
---|
676 | </t> |
---|
677 | <t> |
---|
678 | POST requests &MUST; obey the message transmission requirements set out |
---|
679 | in [message.transmission.requirements]. |
---|
680 | </t> |
---|
681 | <t> |
---|
682 | See <xref target="encoding.sensitive.information.in.uris"/> for security considerations. |
---|
683 | </t> |
---|
684 | </section> |
---|
685 | |
---|
686 | <section title="PUT" anchor="PUT"> |
---|
687 | <iref primary="true" item="PUT method" x:for-anchor=""/> |
---|
688 | <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> |
---|
689 | <t> |
---|
690 | The PUT method requests that the enclosed entity be stored under the |
---|
691 | supplied Request-URI. If the Request-URI refers to an already |
---|
692 | existing resource, the enclosed entity &SHOULD; be considered as a |
---|
693 | modified version of the one residing on the origin server. If the |
---|
694 | Request-URI does not point to an existing resource, and that URI is |
---|
695 | capable of being defined as a new resource by the requesting user |
---|
696 | agent, the origin server can create the resource with that URI. If a |
---|
697 | new resource is created, the origin server &MUST; inform the user agent |
---|
698 | via the 201 (Created) response. If an existing resource is modified, |
---|
699 | either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent |
---|
700 | to indicate successful completion of the request. If the resource |
---|
701 | could not be created or modified with the Request-URI, an appropriate |
---|
702 | error response &SHOULD; be given that reflects the nature of the |
---|
703 | problem. The recipient of the entity &MUST-NOT; ignore any Content-* |
---|
704 | (e.g. Content-Range) headers that it does not understand or implement |
---|
705 | and &MUST; return a 501 (Not Implemented) response in such cases. |
---|
706 | </t> |
---|
707 | <t> |
---|
708 | If the request passes through a cache and the Request-URI identifies |
---|
709 | one or more currently cached entities, those entries &SHOULD; be |
---|
710 | treated as stale. Responses to this method are not cacheable. |
---|
711 | </t> |
---|
712 | <t> |
---|
713 | The fundamental difference between the POST and PUT requests is |
---|
714 | reflected in the different meaning of the Request-URI. The URI in a |
---|
715 | POST request identifies the resource that will handle the enclosed |
---|
716 | entity. That resource might be a data-accepting process, a gateway to |
---|
717 | some other protocol, or a separate entity that accepts annotations. |
---|
718 | In contrast, the URI in a PUT request identifies the entity enclosed |
---|
719 | with the request -- the user agent knows what URI is intended and the |
---|
720 | server &MUST-NOT; attempt to apply the request to some other resource. |
---|
721 | If the server desires that the request be applied to a different URI, |
---|
722 | it &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; |
---|
723 | then make its own decision regarding whether or not to redirect the |
---|
724 | request. |
---|
725 | </t> |
---|
726 | <t> |
---|
727 | A single resource &MAY; be identified by many different URIs. For |
---|
728 | example, an article might have a URI for identifying "the current |
---|
729 | version" which is separate from the URI identifying each particular |
---|
730 | version. In this case, a PUT request on a general URI might result in |
---|
731 | several other URIs being defined by the origin server. |
---|
732 | </t> |
---|
733 | <t> |
---|
734 | HTTP/1.1 does not define how a PUT method affects the state of an |
---|
735 | origin server. |
---|
736 | </t> |
---|
737 | <t> |
---|
738 | PUT requests &MUST; obey the message transmission requirements set out |
---|
739 | in [message.transmission.requirements]. |
---|
740 | </t> |
---|
741 | <t> |
---|
742 | Unless otherwise specified for a particular entity-header, the |
---|
743 | entity-headers in the PUT request &SHOULD; be applied to the resource |
---|
744 | created or modified by the PUT. |
---|
745 | </t> |
---|
746 | </section> |
---|
747 | |
---|
748 | <section title="DELETE" anchor="DELETE"> |
---|
749 | <iref primary="true" item="DELETE method" x:for-anchor=""/> |
---|
750 | <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> |
---|
751 | <t> |
---|
752 | The DELETE method requests that the origin server delete the resource |
---|
753 | identified by the Request-URI. This method &MAY; be overridden by human |
---|
754 | intervention (or other means) on the origin server. The client cannot |
---|
755 | be guaranteed that the operation has been carried out, even if the |
---|
756 | status code returned from the origin server indicates that the action |
---|
757 | has been completed successfully. However, the server &SHOULD-NOT; |
---|
758 | indicate success unless, at the time the response is given, it |
---|
759 | intends to delete the resource or move it to an inaccessible |
---|
760 | location. |
---|
761 | </t> |
---|
762 | <t> |
---|
763 | A successful response &SHOULD; be 200 (OK) if the response includes an |
---|
764 | entity describing the status, 202 (Accepted) if the action has not |
---|
765 | yet been enacted, or 204 (No Content) if the action has been enacted |
---|
766 | but the response does not include an entity. |
---|
767 | </t> |
---|
768 | <t> |
---|
769 | If the request passes through a cache and the Request-URI identifies |
---|
770 | one or more currently cached entities, those entries &SHOULD; be |
---|
771 | treated as stale. Responses to this method are not cacheable. |
---|
772 | </t> |
---|
773 | </section> |
---|
774 | |
---|
775 | <section title="TRACE" anchor="TRACE"> |
---|
776 | <iref primary="true" item="TRACE method" x:for-anchor=""/> |
---|
777 | <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/> |
---|
778 | <t> |
---|
779 | The TRACE method is used to invoke a remote, application-layer loop-back |
---|
780 | of the request message. The final recipient of the request |
---|
781 | &SHOULD; reflect the message received back to the client as the |
---|
782 | entity-body of a 200 (OK) response. The final recipient is either the |
---|
783 | origin server or the first proxy or gateway to receive a Max-Forwards |
---|
784 | value of zero (0) in the request (see <xref target="header.max-forwards"/>). A TRACE request |
---|
785 | &MUST-NOT; include an entity. |
---|
786 | </t> |
---|
787 | <t> |
---|
788 | TRACE allows the client to see what is being received at the other |
---|
789 | end of the request chain and use that data for testing or diagnostic |
---|
790 | information. The value of the Via header field (&header-via;) is of |
---|
791 | particular interest, since it acts as a trace of the request chain. |
---|
792 | Use of the Max-Forwards header field allows the client to limit the |
---|
793 | length of the request chain, which is useful for testing a chain of |
---|
794 | proxies forwarding messages in an infinite loop. |
---|
795 | </t> |
---|
796 | <t> |
---|
797 | If the request is valid, the response &SHOULD; contain the entire |
---|
798 | request message in the entity-body, with a Content-Type of |
---|
799 | "message/http". Responses to this method &MUST-NOT; be cached. |
---|
800 | </t> |
---|
801 | </section> |
---|
802 | |
---|
803 | <section title="CONNECT" anchor="CONNECT"> |
---|
804 | <iref primary="true" item="CONNECT method" x:for-anchor=""/> |
---|
805 | <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> |
---|
806 | <t> |
---|
807 | This specification reserves the method name CONNECT for use with a |
---|
808 | proxy that can dynamically switch to being a tunnel (e.g. SSL |
---|
809 | tunneling <xref target="Luo1998"/>). |
---|
810 | </t> |
---|
811 | </section> |
---|
812 | </section> |
---|
813 | |
---|
814 | |
---|
815 | <section title="Status Code Definitions" anchor="status.codes"> |
---|
816 | <t> |
---|
817 | Each Status-Code is described below, including a description of which |
---|
818 | method(s) it can follow and any metainformation required in the |
---|
819 | response. |
---|
820 | </t> |
---|
821 | |
---|
822 | <section title="Informational 1xx" anchor="status.1xx"> |
---|
823 | <t> |
---|
824 | This class of status code indicates a provisional response, |
---|
825 | consisting only of the Status-Line and optional headers, and is |
---|
826 | terminated by an empty line. There are no required headers for this |
---|
827 | class of status code. Since HTTP/1.0 did not define any 1xx status |
---|
828 | codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client |
---|
829 | except under experimental conditions. |
---|
830 | </t> |
---|
831 | <t> |
---|
832 | A client &MUST; be prepared to accept one or more 1xx status responses |
---|
833 | prior to a regular response, even if the client does not expect a 100 |
---|
834 | (Continue) status message. Unexpected 1xx status responses &MAY; be |
---|
835 | ignored by a user agent. |
---|
836 | </t> |
---|
837 | <t> |
---|
838 | Proxies &MUST; forward 1xx responses, unless the connection between the |
---|
839 | proxy and its client has been closed, or unless the proxy itself |
---|
840 | requested the generation of the 1xx response. (For example, if a |
---|
841 | proxy adds a "Expect: 100-continue" field when it forwards a request, |
---|
842 | then it need not forward the corresponding 100 (Continue) |
---|
843 | response(s).) |
---|
844 | </t> |
---|
845 | |
---|
846 | <section title="100 Continue" anchor="status.100"> |
---|
847 | <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/> |
---|
848 | <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/> |
---|
849 | <t> |
---|
850 | The client &SHOULD; continue with its request. This interim response is |
---|
851 | used to inform the client that the initial part of the request has |
---|
852 | been received and has not yet been rejected by the server. The client |
---|
853 | &SHOULD; continue by sending the remainder of the request or, if the |
---|
854 | request has already been completed, ignore this response. The server |
---|
855 | &MUST; send a final response after the request has been completed. See |
---|
856 | &use100; for detailed discussion of the use and handling of this |
---|
857 | status code. |
---|
858 | </t> |
---|
859 | </section> |
---|
860 | |
---|
861 | <section title="101 Switching Protocols" anchor="status.101"> |
---|
862 | <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/> |
---|
863 | <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/> |
---|
864 | <t> |
---|
865 | The server understands and is willing to comply with the client's |
---|
866 | request, via the Upgrade message header field (&header-upgrade;), for a |
---|
867 | change in the application protocol being used on this connection. The |
---|
868 | server will switch protocols to those defined by the response's |
---|
869 | Upgrade header field immediately after the empty line which |
---|
870 | terminates the 101 response. |
---|
871 | </t> |
---|
872 | <t> |
---|
873 | The protocol &SHOULD; be switched only when it is advantageous to do |
---|
874 | so. For example, switching to a newer version of HTTP is advantageous |
---|
875 | over older versions, and switching to a real-time, synchronous |
---|
876 | protocol might be advantageous when delivering resources that use |
---|
877 | such features. |
---|
878 | </t> |
---|
879 | </section> |
---|
880 | </section> |
---|
881 | |
---|
882 | <section title="Successful 2xx" anchor="status.2xx"> |
---|
883 | <t> |
---|
884 | This class of status code indicates that the client's request was |
---|
885 | successfully received, understood, and accepted. |
---|
886 | </t> |
---|
887 | |
---|
888 | <section title="200 OK" anchor="status.200"> |
---|
889 | <iref primary="true" item="200 OK (status code)" x:for-anchor=""/> |
---|
890 | <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/> |
---|
891 | <t> |
---|
892 | The request has succeeded. The information returned with the response |
---|
893 | is dependent on the method used in the request, for example: |
---|
894 | <list style="hanging"> |
---|
895 | <t hangText="GET"> |
---|
896 | an entity corresponding to the requested resource is sent in |
---|
897 | the response; |
---|
898 | </t> |
---|
899 | <t hangText="HEAD"> |
---|
900 | the entity-header fields corresponding to the requested |
---|
901 | resource are sent in the response without any message-body; |
---|
902 | </t> |
---|
903 | <t hangText="POST"> |
---|
904 | an entity describing or containing the result of the action; |
---|
905 | </t> |
---|
906 | <t hangText="TRACE"> |
---|
907 | an entity containing the request message as received by the |
---|
908 | end server. |
---|
909 | </t> |
---|
910 | </list> |
---|
911 | </t> |
---|
912 | </section> |
---|
913 | |
---|
914 | <section title="201 Created" anchor="status.201"> |
---|
915 | <iref primary="true" item="201 Created (status code)" x:for-anchor=""/> |
---|
916 | <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/> |
---|
917 | <t> |
---|
918 | The request has been fulfilled and resulted in a new resource being |
---|
919 | created. The newly created resource can be referenced by the URI(s) |
---|
920 | returned in the entity of the response, with the most specific URI |
---|
921 | for the resource given by a Location header field. The response |
---|
922 | &SHOULD; include an entity containing a list of resource |
---|
923 | characteristics and location(s) from which the user or user agent can |
---|
924 | choose the one most appropriate. The entity format is specified by |
---|
925 | the media type given in the Content-Type header field. The origin |
---|
926 | server &MUST; create the resource before returning the 201 status code. |
---|
927 | If the action cannot be carried out immediately, the server &SHOULD; |
---|
928 | respond with 202 (Accepted) response instead. |
---|
929 | </t> |
---|
930 | <t> |
---|
931 | A 201 response &MAY; contain an ETag response header field indicating |
---|
932 | the current value of the entity tag for the requested variant just |
---|
933 | created, see &header-etag;. |
---|
934 | </t> |
---|
935 | </section> |
---|
936 | |
---|
937 | <section title="202 Accepted" anchor="status.202"> |
---|
938 | <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/> |
---|
939 | <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/> |
---|
940 | <t> |
---|
941 | The request has been accepted for processing, but the processing has |
---|
942 | not been completed. The request might or might not eventually be |
---|
943 | acted upon, as it might be disallowed when processing actually takes |
---|
944 | place. There is no facility for re-sending a status code from an |
---|
945 | asynchronous operation such as this. |
---|
946 | </t> |
---|
947 | <t> |
---|
948 | The 202 response is intentionally non-committal. Its purpose is to |
---|
949 | allow a server to accept a request for some other process (perhaps a |
---|
950 | batch-oriented process that is only run once per day) without |
---|
951 | requiring that the user agent's connection to the server persist |
---|
952 | until the process is completed. The entity returned with this |
---|
953 | response &SHOULD; include an indication of the request's current status |
---|
954 | and either a pointer to a status monitor or some estimate of when the |
---|
955 | user can expect the request to be fulfilled. |
---|
956 | </t> |
---|
957 | </section> |
---|
958 | |
---|
959 | <section title="203 Non-Authoritative Information" anchor="status.203"> |
---|
960 | <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/> |
---|
961 | <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> |
---|
962 | <t> |
---|
963 | The returned metainformation in the entity-header is not the |
---|
964 | definitive set as available from the origin server, but is gathered |
---|
965 | from a local or a third-party copy. The set presented &MAY; be a subset |
---|
966 | or superset of the original version. For example, including local |
---|
967 | annotation information about the resource might result in a superset |
---|
968 | of the metainformation known by the origin server. Use of this |
---|
969 | response code is not required and is only appropriate when the |
---|
970 | response would otherwise be 200 (OK). |
---|
971 | </t> |
---|
972 | </section> |
---|
973 | |
---|
974 | <section title="204 No Content" anchor="status.204"> |
---|
975 | <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/> |
---|
976 | <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/> |
---|
977 | <t> |
---|
978 | The server has fulfilled the request but does not need to return an |
---|
979 | entity-body, and might want to return updated metainformation. The |
---|
980 | response &MAY; include new or updated metainformation in the form of |
---|
981 | entity-headers, which if present &SHOULD; be associated with the |
---|
982 | requested variant. |
---|
983 | </t> |
---|
984 | <t> |
---|
985 | If the client is a user agent, it &SHOULD-NOT; change its document view |
---|
986 | from that which caused the request to be sent. This response is |
---|
987 | primarily intended to allow input for actions to take place without |
---|
988 | causing a change to the user agent's active document view, although |
---|
989 | any new or updated metainformation &SHOULD; be applied to the document |
---|
990 | currently in the user agent's active view. |
---|
991 | </t> |
---|
992 | <t> |
---|
993 | The 204 response &MUST-NOT; include a message-body, and thus is always |
---|
994 | terminated by the first empty line after the header fields. |
---|
995 | </t> |
---|
996 | </section> |
---|
997 | |
---|
998 | <section title="205 Reset Content" anchor="status.205"> |
---|
999 | <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/> |
---|
1000 | <iref primary="true" item="Status Codes" subitem="205 Reset Content" x:for-anchor=""/> |
---|
1001 | <t> |
---|
1002 | The server has fulfilled the request and the user agent &SHOULD; reset |
---|
1003 | the document view which caused the request to be sent. This response |
---|
1004 | is primarily intended to allow input for actions to take place via |
---|
1005 | user input, followed by a clearing of the form in which the input is |
---|
1006 | given so that the user can easily initiate another input action. The |
---|
1007 | response &MUST-NOT; include an entity. |
---|
1008 | </t> |
---|
1009 | </section> |
---|
1010 | |
---|
1011 | <section title="206 Partial Content" anchor="status.206"> |
---|
1012 | <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/> |
---|
1013 | <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/> |
---|
1014 | <t> |
---|
1015 | The server has fulfilled the partial GET request for the resource |
---|
1016 | and the enclosed entity is a partial representation as defined in ⦥. |
---|
1017 | </t> |
---|
1018 | </section> |
---|
1019 | </section> |
---|
1020 | |
---|
1021 | <section title="Redirection 3xx" anchor="status.3xx"> |
---|
1022 | <t> |
---|
1023 | This class of status code indicates that further action needs to be |
---|
1024 | taken by the user agent in order to fulfill the request. The action |
---|
1025 | required &MAY; be carried out by the user agent without interaction |
---|
1026 | with the user if and only if the method used in the second request is |
---|
1027 | GET or HEAD. A client &SHOULD; detect infinite redirection loops, since |
---|
1028 | such loops generate network traffic for each redirection. |
---|
1029 | <list><t> |
---|
1030 | <x:h>Note:</x:h> previous versions of this specification recommended a |
---|
1031 | maximum of five redirections. Content developers should be aware |
---|
1032 | that there might be clients that implement such a fixed |
---|
1033 | limitation. |
---|
1034 | </t></list> |
---|
1035 | </t> |
---|
1036 | |
---|
1037 | <section title="300 Multiple Choices" anchor="status.300"> |
---|
1038 | <iref primary="true" item="300 Multiple Choices (status code)" x:for-anchor=""/> |
---|
1039 | <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/> |
---|
1040 | <t> |
---|
1041 | The requested resource corresponds to any one of a set of |
---|
1042 | representations, each with its own specific location, and agent-driven |
---|
1043 | negotiation information (&content-negotiation;) is being provided so that |
---|
1044 | the user (or user agent) can select a preferred representation and |
---|
1045 | redirect its request to that location. |
---|
1046 | </t> |
---|
1047 | <t> |
---|
1048 | Unless it was a HEAD request, the response &SHOULD; include an entity |
---|
1049 | containing a list of resource characteristics and location(s) from |
---|
1050 | which the user or user agent can choose the one most appropriate. The |
---|
1051 | entity format is specified by the media type given in the Content-Type |
---|
1052 | header field. Depending upon the format and the capabilities of |
---|
1053 | the user agent, selection of the most appropriate choice &MAY; be |
---|
1054 | performed automatically. However, this specification does not define |
---|
1055 | any standard for such automatic selection. |
---|
1056 | </t> |
---|
1057 | <t> |
---|
1058 | If the server has a preferred choice of representation, it &SHOULD; |
---|
1059 | include the specific URI for that representation in the Location |
---|
1060 | field; user agents &MAY; use the Location field value for automatic |
---|
1061 | redirection. This response is cacheable unless indicated otherwise. |
---|
1062 | </t> |
---|
1063 | </section> |
---|
1064 | |
---|
1065 | <section title="301 Moved Permanently" anchor="status.301"> |
---|
1066 | <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/> |
---|
1067 | <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/> |
---|
1068 | <t> |
---|
1069 | The requested resource has been assigned a new permanent URI and any |
---|
1070 | future references to this resource &SHOULD; use one of the returned |
---|
1071 | URIs. Clients with link editing capabilities ought to automatically |
---|
1072 | re-link references to the Request-URI to one or more of the new |
---|
1073 | references returned by the server, where possible. This response is |
---|
1074 | cacheable unless indicated otherwise. |
---|
1075 | </t> |
---|
1076 | <t> |
---|
1077 | The new permanent URI &SHOULD; be given by the Location field in the |
---|
1078 | response. Unless the request method was HEAD, the entity of the |
---|
1079 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
1080 | the new URI(s). |
---|
1081 | </t> |
---|
1082 | <t> |
---|
1083 | If the 301 status code is received in response to a request other |
---|
1084 | than GET or HEAD, the user agent &MUST-NOT; automatically redirect the |
---|
1085 | request unless it can be confirmed by the user, since this might |
---|
1086 | change the conditions under which the request was issued. |
---|
1087 | <list><t> |
---|
1088 | <x:h>Note:</x:h> When automatically redirecting a POST request after |
---|
1089 | receiving a 301 status code, some existing HTTP/1.0 user agents |
---|
1090 | will erroneously change it into a GET request. |
---|
1091 | </t></list> |
---|
1092 | </t> |
---|
1093 | </section> |
---|
1094 | |
---|
1095 | <section title="302 Found" anchor="status.302"> |
---|
1096 | <iref primary="true" item="302 Found (status code)" x:for-anchor=""/> |
---|
1097 | <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/> |
---|
1098 | <t> |
---|
1099 | The requested resource resides temporarily under a different URI. |
---|
1100 | Since the redirection might be altered on occasion, the client &SHOULD; |
---|
1101 | continue to use the Request-URI for future requests. This response |
---|
1102 | is only cacheable if indicated by a Cache-Control or Expires header |
---|
1103 | field. |
---|
1104 | </t> |
---|
1105 | <t> |
---|
1106 | The temporary URI &SHOULD; be given by the Location field in the |
---|
1107 | response. Unless the request method was HEAD, the entity of the |
---|
1108 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
1109 | the new URI(s). |
---|
1110 | </t> |
---|
1111 | <t> |
---|
1112 | If the 302 status code is received in response to a request other |
---|
1113 | than GET or HEAD, the user agent &MUST-NOT; automatically redirect the |
---|
1114 | request unless it can be confirmed by the user, since this might |
---|
1115 | change the conditions under which the request was issued. |
---|
1116 | <list><t> |
---|
1117 | <x:h>Note:</x:h> RFC 1945 and RFC 2068 specify that the client is not allowed |
---|
1118 | to change the method on the redirected request. However, most |
---|
1119 | existing user agent implementations treat 302 as if it were a 303 |
---|
1120 | response, performing a GET on the Location field-value regardless |
---|
1121 | of the original request method. The status codes 303 and 307 have |
---|
1122 | been added for servers that wish to make unambiguously clear which |
---|
1123 | kind of reaction is expected of the client. |
---|
1124 | </t></list> |
---|
1125 | </t> |
---|
1126 | </section> |
---|
1127 | |
---|
1128 | <section title="303 See Other" anchor="status.303"> |
---|
1129 | <iref primary="true" item="303 See Other (status code)" x:for-anchor=""/> |
---|
1130 | <iref primary="true" item="Status Codes" subitem="303 See Other" x:for-anchor=""/> |
---|
1131 | <t> |
---|
1132 | The response to the request can be found under a different URI and |
---|
1133 | &SHOULD; be retrieved using a GET method on that resource. This method |
---|
1134 | exists primarily to allow the output of a POST-activated script to |
---|
1135 | redirect the user agent to a selected resource. The new URI is not a |
---|
1136 | substitute reference for the originally requested resource. The 303 |
---|
1137 | response &MUST-NOT; be cached, but the response to the second |
---|
1138 | (redirected) request might be cacheable. |
---|
1139 | </t> |
---|
1140 | <t> |
---|
1141 | The different URI &SHOULD; be given by the Location field in the |
---|
1142 | response. Unless the request method was HEAD, the entity of the |
---|
1143 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
1144 | the new URI(s). |
---|
1145 | <list><t> |
---|
1146 | <x:h>Note:</x:h> Many pre-HTTP/1.1 user agents do not understand the 303 |
---|
1147 | status. When interoperability with such clients is a concern, the |
---|
1148 | 302 status code may be used instead, since most user agents react |
---|
1149 | to a 302 response as described here for 303. |
---|
1150 | </t></list> |
---|
1151 | </t> |
---|
1152 | </section> |
---|
1153 | |
---|
1154 | <section title="304 Not Modified" anchor="status.304"> |
---|
1155 | <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/> |
---|
1156 | <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/> |
---|
1157 | <t> |
---|
1158 | If the client has performed a conditional GET request and access is |
---|
1159 | allowed, but the document has not been modified, the server &SHOULD; |
---|
1160 | respond with this status code. The 304 response &MUST-NOT; contain a |
---|
1161 | message-body, and thus is always terminated by the first empty line |
---|
1162 | after the header fields. |
---|
1163 | </t> |
---|
1164 | <t> |
---|
1165 | The response &MUST; include the following header fields: |
---|
1166 | <list style="symbols"> |
---|
1167 | <t>Date, unless its omission is required by [clockless.origin.server.operation]</t> |
---|
1168 | </list> |
---|
1169 | </t> |
---|
1170 | <t> |
---|
1171 | If a clockless origin server obeys these rules, and proxies and |
---|
1172 | clients add their own Date to any response received without one (as |
---|
1173 | already specified by [RFC 2068], section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate |
---|
1174 | correctly. |
---|
1175 | <list style="symbols"> |
---|
1176 | <t>ETag and/or Content-Location, if the header would have been sent |
---|
1177 | in a 200 response to the same request</t> |
---|
1178 | <t>Expires, Cache-Control, and/or Vary, if the field-value might |
---|
1179 | differ from that sent in any previous response for the same |
---|
1180 | variant</t> |
---|
1181 | </list> |
---|
1182 | </t> |
---|
1183 | <t> |
---|
1184 | If the conditional GET used a strong cache validator (see &caching;), |
---|
1185 | the response &SHOULD-NOT; include other entity-headers. |
---|
1186 | Otherwise (i.e., the conditional GET used a weak validator), the |
---|
1187 | response &MUST-NOT; include other entity-headers; this prevents |
---|
1188 | inconsistencies between cached entity-bodies and updated headers. |
---|
1189 | </t> |
---|
1190 | <t> |
---|
1191 | If a 304 response indicates an entity not currently cached, then the |
---|
1192 | cache &MUST; disregard the response and repeat the request without the |
---|
1193 | conditional. |
---|
1194 | </t> |
---|
1195 | <t> |
---|
1196 | If a cache uses a received 304 response to update a cache entry, the |
---|
1197 | cache &MUST; update the entry to reflect any new field values given in |
---|
1198 | the response. |
---|
1199 | </t> |
---|
1200 | </section> |
---|
1201 | |
---|
1202 | <section title="305 Use Proxy" anchor="status.305"> |
---|
1203 | <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/> |
---|
1204 | <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/> |
---|
1205 | <t> |
---|
1206 | The requested resource &MUST; be accessed through the proxy given by |
---|
1207 | the Location field. The Location field gives the URI of the proxy. |
---|
1208 | The recipient is expected to repeat this single request via the |
---|
1209 | proxy. 305 responses &MUST; only be generated by origin servers. |
---|
1210 | <list><t> |
---|
1211 | <x:h>Note:</x:h> RFC 2068 was not clear that 305 was intended to redirect a |
---|
1212 | single request, and to be generated by origin servers only. Not |
---|
1213 | observing these limitations has significant security consequences. |
---|
1214 | </t></list> |
---|
1215 | </t> |
---|
1216 | </section> |
---|
1217 | |
---|
1218 | <section title="306 (Unused)" anchor="status.306"> |
---|
1219 | <iref primary="true" item="306 (Unused) (status code)" x:for-anchor=""/> |
---|
1220 | <iref primary="true" item="Status Codes" subitem="306 (Unused)" x:for-anchor=""/> |
---|
1221 | <t> |
---|
1222 | The 306 status code was used in a previous version of the |
---|
1223 | specification, is no longer used, and the code is reserved. |
---|
1224 | </t> |
---|
1225 | </section> |
---|
1226 | |
---|
1227 | <section title="307 Temporary Redirect" anchor="status.307"> |
---|
1228 | <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/> |
---|
1229 | <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/> |
---|
1230 | <t> |
---|
1231 | The requested resource resides temporarily under a different URI. |
---|
1232 | Since the redirection &MAY; be altered on occasion, the client &SHOULD; |
---|
1233 | continue to use the Request-URI for future requests. This response |
---|
1234 | is only cacheable if indicated by a Cache-Control or Expires header |
---|
1235 | field. |
---|
1236 | </t> |
---|
1237 | <t> |
---|
1238 | The temporary URI &SHOULD; be given by the Location field in the |
---|
1239 | response. Unless the request method was HEAD, the entity of the |
---|
1240 | response &SHOULD; contain a short hypertext note with a hyperlink to |
---|
1241 | the new URI(s) , since many pre-HTTP/1.1 user agents do not |
---|
1242 | understand the 307 status. Therefore, the note &SHOULD; contain the |
---|
1243 | information necessary for a user to repeat the original request on |
---|
1244 | the new URI. |
---|
1245 | </t> |
---|
1246 | <t> |
---|
1247 | If the 307 status code is received in response to a request other |
---|
1248 | than GET or HEAD, the user agent &MUST-NOT; automatically redirect the |
---|
1249 | request unless it can be confirmed by the user, since this might |
---|
1250 | change the conditions under which the request was issued. |
---|
1251 | </t> |
---|
1252 | </section> |
---|
1253 | </section> |
---|
1254 | |
---|
1255 | <section title="Client Error 4xx" anchor="status.4xx"> |
---|
1256 | <t> |
---|
1257 | The 4xx class of status code is intended for cases in which the |
---|
1258 | client seems to have erred. Except when responding to a HEAD request, |
---|
1259 | the server &SHOULD; include an entity containing an explanation of the |
---|
1260 | error situation, and whether it is a temporary or permanent |
---|
1261 | condition. These status codes are applicable to any request method. |
---|
1262 | User agents &SHOULD; display any included entity to the user. |
---|
1263 | </t> |
---|
1264 | <t> |
---|
1265 | If the client is sending data, a server implementation using TCP |
---|
1266 | &SHOULD; be careful to ensure that the client acknowledges receipt of |
---|
1267 | the packet(s) containing the response, before the server closes the |
---|
1268 | input connection. If the client continues sending data to the server |
---|
1269 | after the close, the server's TCP stack will send a reset packet to |
---|
1270 | the client, which may erase the client's unacknowledged input buffers |
---|
1271 | before they can be read and interpreted by the HTTP application. |
---|
1272 | </t> |
---|
1273 | |
---|
1274 | <section title="400 Bad Request" anchor="status.400"> |
---|
1275 | <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/> |
---|
1276 | <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/> |
---|
1277 | <t> |
---|
1278 | The request could not be understood by the server due to malformed |
---|
1279 | syntax. The client &SHOULD-NOT; repeat the request without |
---|
1280 | modifications. |
---|
1281 | </t> |
---|
1282 | </section> |
---|
1283 | |
---|
1284 | <section title="401 Unauthorized" anchor="status.401"> |
---|
1285 | <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/> |
---|
1286 | <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/> |
---|
1287 | <t> |
---|
1288 | The request requires user authentication. The response &MUST; include a |
---|
1289 | WWW-Authenticate header field (&header-www-authenticate;) containing a challenge |
---|
1290 | applicable to the requested resource. The client &MAY; repeat the |
---|
1291 | request with a suitable Authorization header field (&header-authorization;). If |
---|
1292 | the request already included Authorization credentials, then the 401 |
---|
1293 | response indicates that authorization has been refused for those |
---|
1294 | credentials. If the 401 response contains the same challenge as the |
---|
1295 | prior response, and the user agent has already attempted |
---|
1296 | authentication at least once, then the user &SHOULD; be presented the |
---|
1297 | entity that was given in the response, since that entity might |
---|
1298 | include relevant diagnostic information. HTTP access authentication |
---|
1299 | is explained in "HTTP Authentication: Basic and Digest Access |
---|
1300 | Authentication" <xref target="RFC2617"/>. |
---|
1301 | </t> |
---|
1302 | </section> |
---|
1303 | |
---|
1304 | <section title="402 Payment Required" anchor="status.402"> |
---|
1305 | <iref primary="true" item="402 Payment Required (status code)" x:for-anchor=""/> |
---|
1306 | <iref primary="true" item="Status Codes" subitem="402 Payment Required" x:for-anchor=""/> |
---|
1307 | <t> |
---|
1308 | This code is reserved for future use. |
---|
1309 | </t> |
---|
1310 | </section> |
---|
1311 | |
---|
1312 | <section title="403 Forbidden" anchor="status.403"> |
---|
1313 | <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/> |
---|
1314 | <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/> |
---|
1315 | <t> |
---|
1316 | The server understood the request, but is refusing to fulfill it. |
---|
1317 | Authorization will not help and the request &SHOULD-NOT; be repeated. |
---|
1318 | If the request method was not HEAD and the server wishes to make |
---|
1319 | public why the request has not been fulfilled, it &SHOULD; describe the |
---|
1320 | reason for the refusal in the entity. If the server does not wish to |
---|
1321 | make this information available to the client, the status code 404 |
---|
1322 | (Not Found) can be used instead. |
---|
1323 | </t> |
---|
1324 | </section> |
---|
1325 | |
---|
1326 | <section title="404 Not Found" anchor="status.404"> |
---|
1327 | <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/> |
---|
1328 | <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> |
---|
1329 | <t> |
---|
1330 | The server has not found anything matching the Request-URI. No |
---|
1331 | indication is given of whether the condition is temporary or |
---|
1332 | permanent. The 410 (Gone) status code &SHOULD; be used if the server |
---|
1333 | knows, through some internally configurable mechanism, that an old |
---|
1334 | resource is permanently unavailable and has no forwarding address. |
---|
1335 | This status code is commonly used when the server does not wish to |
---|
1336 | reveal exactly why the request has been refused, or when no other |
---|
1337 | response is applicable. |
---|
1338 | </t> |
---|
1339 | </section> |
---|
1340 | |
---|
1341 | <section title="405 Method Not Allowed" anchor="status.405"> |
---|
1342 | <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/> |
---|
1343 | <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> |
---|
1344 | <t> |
---|
1345 | The method specified in the Request-Line is not allowed for the |
---|
1346 | resource identified by the Request-URI. The response &MUST; include an |
---|
1347 | Allow header containing a list of valid methods for the requested |
---|
1348 | resource. |
---|
1349 | </t> |
---|
1350 | </section> |
---|
1351 | |
---|
1352 | <section title="406 Not Acceptable" anchor="status.406"> |
---|
1353 | <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/> |
---|
1354 | <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/> |
---|
1355 | <t> |
---|
1356 | The resource identified by the request is only capable of generating |
---|
1357 | response entities which have content characteristics not acceptable |
---|
1358 | according to the accept headers sent in the request. |
---|
1359 | </t> |
---|
1360 | <t> |
---|
1361 | Unless it was a HEAD request, the response &SHOULD; include an entity |
---|
1362 | containing a list of available entity characteristics and location(s) |
---|
1363 | from which the user or user agent can choose the one most |
---|
1364 | appropriate. The entity format is specified by the media type given |
---|
1365 | in the Content-Type header field. Depending upon the format and the |
---|
1366 | capabilities of the user agent, selection of the most appropriate |
---|
1367 | choice &MAY; be performed automatically. However, this specification |
---|
1368 | does not define any standard for such automatic selection. |
---|
1369 | <list><t> |
---|
1370 | <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are |
---|
1371 | not acceptable according to the accept headers sent in the |
---|
1372 | request. In some cases, this may even be preferable to sending a |
---|
1373 | 406 response. User agents are encouraged to inspect the headers of |
---|
1374 | an incoming response to determine if it is acceptable. |
---|
1375 | </t></list> |
---|
1376 | </t> |
---|
1377 | <t> |
---|
1378 | If the response could be unacceptable, a user agent &SHOULD; |
---|
1379 | temporarily stop receipt of more data and query the user for a |
---|
1380 | decision on further actions. |
---|
1381 | </t> |
---|
1382 | </section> |
---|
1383 | |
---|
1384 | <section title="407 Proxy Authentication Required" anchor="status.407"> |
---|
1385 | <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/> |
---|
1386 | <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/> |
---|
1387 | <t> |
---|
1388 | This code is similar to 401 (Unauthorized), but indicates that the |
---|
1389 | client must first authenticate itself with the proxy. The proxy &MUST; |
---|
1390 | return a Proxy-Authenticate header field (&header-proxy-authenticate;) containing a |
---|
1391 | challenge applicable to the proxy for the requested resource. The |
---|
1392 | client &MAY; repeat the request with a suitable Proxy-Authorization |
---|
1393 | header field (&header-proxy-authorization;). HTTP access authentication is explained |
---|
1394 | in "HTTP Authentication: Basic and Digest Access Authentication" |
---|
1395 | <xref target="RFC2617"/>. |
---|
1396 | </t> |
---|
1397 | </section> |
---|
1398 | |
---|
1399 | <section title="408 Request Timeout" anchor="status.408"> |
---|
1400 | <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/> |
---|
1401 | <iref primary="true" item="Status Codes" subitem="408 Request Timeout" x:for-anchor=""/> |
---|
1402 | <t> |
---|
1403 | The client did not produce a request within the time that the server |
---|
1404 | was prepared to wait. The client &MAY; repeat the request without |
---|
1405 | modifications at any later time. |
---|
1406 | </t> |
---|
1407 | </section> |
---|
1408 | |
---|
1409 | <section title="409 Conflict" anchor="status.409"> |
---|
1410 | <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/> |
---|
1411 | <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/> |
---|
1412 | <t> |
---|
1413 | The request could not be completed due to a conflict with the current |
---|
1414 | state of the resource. This code is only allowed in situations where |
---|
1415 | it is expected that the user might be able to resolve the conflict |
---|
1416 | and resubmit the request. The response body &SHOULD; include enough |
---|
1417 | information for the user to recognize the source of the conflict. |
---|
1418 | Ideally, the response entity would include enough information for the |
---|
1419 | user or user agent to fix the problem; however, that might not be |
---|
1420 | possible and is not required. |
---|
1421 | </t> |
---|
1422 | <t> |
---|
1423 | Conflicts are most likely to occur in response to a PUT request. For |
---|
1424 | example, if versioning were being used and the entity being PUT |
---|
1425 | included changes to a resource which conflict with those made by an |
---|
1426 | earlier (third-party) request, the server might use the 409 response |
---|
1427 | to indicate that it can't complete the request. In this case, the |
---|
1428 | response entity would likely contain a list of the differences |
---|
1429 | between the two versions in a format defined by the response |
---|
1430 | Content-Type. |
---|
1431 | </t> |
---|
1432 | </section> |
---|
1433 | |
---|
1434 | <section title="410 Gone" anchor="status.410"> |
---|
1435 | <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/> |
---|
1436 | <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/> |
---|
1437 | <t> |
---|
1438 | The requested resource is no longer available at the server and no |
---|
1439 | forwarding address is known. This condition is expected to be |
---|
1440 | considered permanent. Clients with link editing capabilities &SHOULD; |
---|
1441 | delete references to the Request-URI after user approval. If the |
---|
1442 | server does not know, or has no facility to determine, whether or not |
---|
1443 | the condition is permanent, the status code 404 (Not Found) &SHOULD; be |
---|
1444 | used instead. This response is cacheable unless indicated otherwise. |
---|
1445 | </t> |
---|
1446 | <t> |
---|
1447 | The 410 response is primarily intended to assist the task of web |
---|
1448 | maintenance by notifying the recipient that the resource is |
---|
1449 | intentionally unavailable and that the server owners desire that |
---|
1450 | remote links to that resource be removed. Such an event is common for |
---|
1451 | limited-time, promotional services and for resources belonging to |
---|
1452 | individuals no longer working at the server's site. It is not |
---|
1453 | necessary to mark all permanently unavailable resources as "gone" or |
---|
1454 | to keep the mark for any length of time -- that is left to the |
---|
1455 | discretion of the server owner. |
---|
1456 | </t> |
---|
1457 | </section> |
---|
1458 | |
---|
1459 | <section title="411 Length Required" anchor="status.411"> |
---|
1460 | <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/> |
---|
1461 | <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/> |
---|
1462 | <t> |
---|
1463 | The server refuses to accept the request without a defined Content-Length. |
---|
1464 | The client &MAY; repeat the request if it adds a valid |
---|
1465 | Content-Length header field containing the length of the message-body |
---|
1466 | in the request message. |
---|
1467 | </t> |
---|
1468 | </section> |
---|
1469 | |
---|
1470 | <section title="412 Precondition Failed" anchor="status.412"> |
---|
1471 | <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/> |
---|
1472 | <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/> |
---|
1473 | <t> |
---|
1474 | The precondition given in one or more of the request-header fields |
---|
1475 | evaluated to false when it was tested on the server. This response |
---|
1476 | code allows the client to place preconditions on the current resource |
---|
1477 | metainformation (header field data) and thus prevent the requested |
---|
1478 | method from being applied to a resource other than the one intended. |
---|
1479 | </t> |
---|
1480 | </section> |
---|
1481 | |
---|
1482 | <section title="413 Request Entity Too Large" anchor="status.413"> |
---|
1483 | <iref primary="true" item="413 Request Entity Too Large (status code)" x:for-anchor=""/> |
---|
1484 | <iref primary="true" item="Status Codes" subitem="413 Request Entity Too Large" x:for-anchor=""/> |
---|
1485 | <t> |
---|
1486 | The server is refusing to process a request because the request |
---|
1487 | entity is larger than the server is willing or able to process. The |
---|
1488 | server &MAY; close the connection to prevent the client from continuing |
---|
1489 | the request. |
---|
1490 | </t> |
---|
1491 | <t> |
---|
1492 | If the condition is temporary, the server &SHOULD; include a Retry-After |
---|
1493 | header field to indicate that it is temporary and after what |
---|
1494 | time the client &MAY; try again. |
---|
1495 | </t> |
---|
1496 | </section> |
---|
1497 | |
---|
1498 | <section title="414 Request-URI Too Long" anchor="status.414"> |
---|
1499 | <iref primary="true" item="414 Request-URI Too Long (status code)" x:for-anchor=""/> |
---|
1500 | <iref primary="true" item="Status Codes" subitem="414 Request-URI Too Long" x:for-anchor=""/> |
---|
1501 | <t> |
---|
1502 | The server is refusing to service the request because the Request-URI |
---|
1503 | is longer than the server is willing to interpret. This rare |
---|
1504 | condition is only likely to occur when a client has improperly |
---|
1505 | converted a POST request to a GET request with long query |
---|
1506 | information, when the client has descended into a URI "black hole" of |
---|
1507 | redirection (e.g., a redirected URI prefix that points to a suffix of |
---|
1508 | itself), or when the server is under attack by a client attempting to |
---|
1509 | exploit security holes present in some servers using fixed-length |
---|
1510 | buffers for reading or manipulating the Request-URI. |
---|
1511 | </t> |
---|
1512 | </section> |
---|
1513 | |
---|
1514 | <section title="415 Unsupported Media Type" anchor="status.415"> |
---|
1515 | <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/> |
---|
1516 | <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/> |
---|
1517 | <t> |
---|
1518 | The server is refusing to service the request because the entity of |
---|
1519 | the request is in a format not supported by the requested resource |
---|
1520 | for the requested method. |
---|
1521 | </t> |
---|
1522 | </section> |
---|
1523 | |
---|
1524 | <section title="416 Requested Range Not Satisfiable" anchor="status.416"> |
---|
1525 | <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/> |
---|
1526 | <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/> |
---|
1527 | <t> |
---|
1528 | The request included a Range request-header field (&header-range;) and none of |
---|
1529 | the range-specifier values in this field overlap the current extent |
---|
1530 | of the selected resource. |
---|
1531 | </t> |
---|
1532 | </section> |
---|
1533 | |
---|
1534 | <section title="417 Expectation Failed" anchor="status.417"> |
---|
1535 | <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/> |
---|
1536 | <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/> |
---|
1537 | <t> |
---|
1538 | The expectation given in an Expect request-header field (see <xref target="header.expect"/>) |
---|
1539 | could not be met by this server, or, if the server is a proxy, |
---|
1540 | the server has unambiguous evidence that the request could not be met |
---|
1541 | by the next-hop server. |
---|
1542 | </t> |
---|
1543 | </section> |
---|
1544 | </section> |
---|
1545 | |
---|
1546 | <section title="Server Error 5xx" anchor="status.5xx"> |
---|
1547 | <t> |
---|
1548 | Response status codes beginning with the digit "5" indicate cases in |
---|
1549 | which the server is aware that it has erred or is incapable of |
---|
1550 | performing the request. Except when responding to a HEAD request, the |
---|
1551 | server &SHOULD; include an entity containing an explanation of the |
---|
1552 | error situation, and whether it is a temporary or permanent |
---|
1553 | condition. User agents &SHOULD; display any included entity to the |
---|
1554 | user. These response codes are applicable to any request method. |
---|
1555 | </t> |
---|
1556 | |
---|
1557 | <section title="500 Internal Server Error" anchor="status.500"> |
---|
1558 | <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/> |
---|
1559 | <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/> |
---|
1560 | <t> |
---|
1561 | The server encountered an unexpected condition which prevented it |
---|
1562 | from fulfilling the request. |
---|
1563 | </t> |
---|
1564 | </section> |
---|
1565 | |
---|
1566 | <section title="501 Not Implemented" anchor="status.501"> |
---|
1567 | <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/> |
---|
1568 | <iref primary="true" item="Status Codes" subitem="501 Not Implemented" x:for-anchor=""/> |
---|
1569 | <t> |
---|
1570 | The server does not support the functionality required to fulfill the |
---|
1571 | request. This is the appropriate response when the server does not |
---|
1572 | recognize the request method and is not capable of supporting it for |
---|
1573 | any resource. |
---|
1574 | </t> |
---|
1575 | </section> |
---|
1576 | |
---|
1577 | <section title="502 Bad Gateway" anchor="status.502"> |
---|
1578 | <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/> |
---|
1579 | <iref primary="true" item="Status Codes" subitem="502 Bad Gateway" x:for-anchor=""/> |
---|
1580 | <t> |
---|
1581 | The server, while acting as a gateway or proxy, received an invalid |
---|
1582 | response from the upstream server it accessed in attempting to |
---|
1583 | fulfill the request. |
---|
1584 | </t> |
---|
1585 | </section> |
---|
1586 | |
---|
1587 | <section title="503 Service Unavailable" anchor="status.503"> |
---|
1588 | <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/> |
---|
1589 | <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/> |
---|
1590 | <t> |
---|
1591 | The server is currently unable to handle the request due to a |
---|
1592 | temporary overloading or maintenance of the server. The implication |
---|
1593 | is that this is a temporary condition which will be alleviated after |
---|
1594 | some delay. If known, the length of the delay &MAY; be indicated in a |
---|
1595 | Retry-After header. If no Retry-After is given, the client &SHOULD; |
---|
1596 | handle the response as it would for a 500 response. |
---|
1597 | <list><t> |
---|
1598 | <x:h>Note:</x:h> The existence of the 503 status code does not imply that a |
---|
1599 | server must use it when becoming overloaded. Some servers may wish |
---|
1600 | to simply refuse the connection. |
---|
1601 | </t></list> |
---|
1602 | </t> |
---|
1603 | </section> |
---|
1604 | |
---|
1605 | <section title="504 Gateway Timeout" anchor="status.504"> |
---|
1606 | <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/> |
---|
1607 | <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout" x:for-anchor=""/> |
---|
1608 | <t> |
---|
1609 | The server, while acting as a gateway or proxy, did not receive a |
---|
1610 | timely response from the upstream server specified by the URI (e.g. |
---|
1611 | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed |
---|
1612 | to access in attempting to complete the request. |
---|
1613 | <list><t> |
---|
1614 | <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to |
---|
1615 | return 400 or 500 when DNS lookups time out. |
---|
1616 | </t></list> |
---|
1617 | </t> |
---|
1618 | </section> |
---|
1619 | |
---|
1620 | <section title="505 HTTP Version Not Supported" anchor="status.505"> |
---|
1621 | <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/> |
---|
1622 | <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/> |
---|
1623 | <t> |
---|
1624 | The server does not support, or refuses to support, the HTTP protocol |
---|
1625 | version that was used in the request message. The server is |
---|
1626 | indicating that it is unable or unwilling to complete the request |
---|
1627 | using the same major version as the client, as described in &http-version;, |
---|
1628 | other than with this error message. The response &SHOULD; contain |
---|
1629 | an entity describing why that version is not supported and what other |
---|
1630 | protocols are supported by that server. |
---|
1631 | </t> |
---|
1632 | |
---|
1633 | </section> |
---|
1634 | </section> |
---|
1635 | </section> |
---|
1636 | |
---|
1637 | |
---|
1638 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
1639 | <t> |
---|
1640 | This section defines the syntax and semantics of all standard |
---|
1641 | HTTP/1.1 header fields. For entity-header fields, both sender and |
---|
1642 | recipient refer to either the client or the server, depending on who |
---|
1643 | sends and who receives the entity. |
---|
1644 | </t> |
---|
1645 | |
---|
1646 | <section title="Allow" anchor="header.allow"> |
---|
1647 | <iref primary="true" item="Allow header" x:for-anchor=""/> |
---|
1648 | <iref primary="true" item="Headers" subitem="Allow" x:for-anchor=""/> |
---|
1649 | <t> |
---|
1650 | The Allow entity-header field lists the set of methods supported |
---|
1651 | by the resource identified by the Request-URI. The purpose of this |
---|
1652 | field is strictly to inform the recipient of valid methods |
---|
1653 | associated with the resource. An Allow header field &MUST; be |
---|
1654 | present in a 405 (Method Not Allowed) response. |
---|
1655 | </t> |
---|
1656 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/> |
---|
1657 | Allow = "Allow" ":" #Method |
---|
1658 | </artwork></figure> |
---|
1659 | <t> |
---|
1660 | Example of use: |
---|
1661 | </t> |
---|
1662 | <figure><artwork type="example"> |
---|
1663 | Allow: GET, HEAD, PUT |
---|
1664 | </artwork></figure> |
---|
1665 | <t> |
---|
1666 | This field cannot prevent a client from trying other methods. |
---|
1667 | However, the indications given by the Allow header field value |
---|
1668 | &SHOULD; be followed. The actual set of allowed methods is defined |
---|
1669 | by the origin server at the time of each request. |
---|
1670 | </t> |
---|
1671 | <t> |
---|
1672 | The Allow header field &MAY; be provided with a PUT request to |
---|
1673 | recommend the methods to be supported by the new or modified |
---|
1674 | resource. The server is not required to support these methods and |
---|
1675 | &SHOULD; include an Allow header in the response giving the actual |
---|
1676 | supported methods. |
---|
1677 | </t> |
---|
1678 | <t> |
---|
1679 | A proxy &MUST-NOT; modify the Allow header field even if it does not |
---|
1680 | understand all the methods specified, since the user agent might |
---|
1681 | have other means of communicating with the origin server. |
---|
1682 | </t> |
---|
1683 | </section> |
---|
1684 | |
---|
1685 | <section title="Expect" anchor="header.expect"> |
---|
1686 | <iref primary="true" item="Expect header" x:for-anchor=""/> |
---|
1687 | <iref primary="true" item="Headers" subitem="Expect" x:for-anchor=""/> |
---|
1688 | <t> |
---|
1689 | The Expect request-header field is used to indicate that particular |
---|
1690 | server behaviors are required by the client. |
---|
1691 | </t> |
---|
1692 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expectation-extension"/><iref primary="true" item="Grammar" subitem="expect-params"/> |
---|
1693 | Expect = "Expect" ":" 1#expectation |
---|
1694 | |
---|
1695 | expectation = "100-continue" | expectation-extension |
---|
1696 | expectation-extension = token [ "=" ( token | quoted-string ) |
---|
1697 | *expect-params ] |
---|
1698 | expect-params = ";" token [ "=" ( token | quoted-string ) ] |
---|
1699 | </artwork></figure> |
---|
1700 | <t> |
---|
1701 | A server that does not understand or is unable to comply with any of |
---|
1702 | the expectation values in the Expect field of a request &MUST; respond |
---|
1703 | with appropriate error status. The server &MUST; respond with a 417 |
---|
1704 | (Expectation Failed) status if any of the expectations cannot be met |
---|
1705 | or, if there are other problems with the request, some other 4xx |
---|
1706 | status. |
---|
1707 | </t> |
---|
1708 | <t> |
---|
1709 | This header field is defined with extensible syntax to allow for |
---|
1710 | future extensions. If a server receives a request containing an |
---|
1711 | Expect field that includes an expectation-extension that it does not |
---|
1712 | support, it &MUST; respond with a 417 (Expectation Failed) status. |
---|
1713 | </t> |
---|
1714 | <t> |
---|
1715 | Comparison of expectation values is case-insensitive for unquoted |
---|
1716 | tokens (including the 100-continue token), and is case-sensitive for |
---|
1717 | quoted-string expectation-extensions. |
---|
1718 | </t> |
---|
1719 | <t> |
---|
1720 | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy &MUST; |
---|
1721 | return a 417 (Expectation Failed) status if it receives a request |
---|
1722 | with an expectation that it cannot meet. However, the Expect |
---|
1723 | request-header itself is end-to-end; it &MUST; be forwarded if the |
---|
1724 | request is forwarded. |
---|
1725 | </t> |
---|
1726 | <t> |
---|
1727 | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
---|
1728 | Expect header. |
---|
1729 | </t> |
---|
1730 | <t> |
---|
1731 | See &use100; for the use of the 100 (continue) status. |
---|
1732 | </t> |
---|
1733 | </section> |
---|
1734 | |
---|
1735 | <section title="From" anchor="header.from"> |
---|
1736 | <iref primary="true" item="From header" x:for-anchor=""/> |
---|
1737 | <iref primary="true" item="Headers" subitem="From" x:for-anchor=""/> |
---|
1738 | <t> |
---|
1739 | The From request-header field, if given, &SHOULD; contain an Internet |
---|
1740 | e-mail address for the human user who controls the requesting user |
---|
1741 | agent. The address &SHOULD; be machine-usable, as defined by "mailbox" |
---|
1742 | in RFC 822 <xref target="RFC822"/> as updated by RFC 1123 <xref target="RFC1123"/>: |
---|
1743 | </t> |
---|
1744 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/> |
---|
1745 | From = "From" ":" mailbox |
---|
1746 | </artwork></figure> |
---|
1747 | <t> |
---|
1748 | An example is: |
---|
1749 | </t> |
---|
1750 | <figure><artwork type="example"> |
---|
1751 | From: webmaster@w3.org |
---|
1752 | </artwork></figure> |
---|
1753 | <t> |
---|
1754 | This header field &MAY; be used for logging purposes and as a means for |
---|
1755 | identifying the source of invalid or unwanted requests. It &SHOULD-NOT; |
---|
1756 | be used as an insecure form of access protection. The interpretation |
---|
1757 | of this field is that the request is being performed on behalf of the |
---|
1758 | person given, who accepts responsibility for the method performed. In |
---|
1759 | particular, robot agents &SHOULD; include this header so that the |
---|
1760 | person responsible for running the robot can be contacted if problems |
---|
1761 | occur on the receiving end. |
---|
1762 | </t> |
---|
1763 | <t> |
---|
1764 | The Internet e-mail address in this field &MAY; be separate from the |
---|
1765 | Internet host which issued the request. For example, when a request |
---|
1766 | is passed through a proxy the original issuer's address &SHOULD; be |
---|
1767 | used. |
---|
1768 | </t> |
---|
1769 | <t> |
---|
1770 | The client &SHOULD-NOT; send the From header field without the user's |
---|
1771 | approval, as it might conflict with the user's privacy interests or |
---|
1772 | their site's security policy. It is strongly recommended that the |
---|
1773 | user be able to disable, enable, and modify the value of this field |
---|
1774 | at any time prior to a request. |
---|
1775 | </t> |
---|
1776 | </section> |
---|
1777 | |
---|
1778 | <section title="Location" anchor="header.location"> |
---|
1779 | <iref primary="true" item="Location header" x:for-anchor=""/> |
---|
1780 | <iref primary="true" item="Headers" subitem="Location" x:for-anchor=""/> |
---|
1781 | <t> |
---|
1782 | The Location response-header field is used to redirect the recipient |
---|
1783 | to a location other than the Request-URI for completion of the |
---|
1784 | request or identification of a new resource. For 201 (Created) |
---|
1785 | responses, the Location is that of the new resource which was created |
---|
1786 | by the request. For 3xx responses, the location &SHOULD; indicate the |
---|
1787 | server's preferred URI for automatic redirection to the resource. The |
---|
1788 | field value consists of a single absolute URI. |
---|
1789 | </t> |
---|
1790 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/> |
---|
1791 | Location = "Location" ":" absoluteURI |
---|
1792 | </artwork></figure> |
---|
1793 | <t> |
---|
1794 | An example is: |
---|
1795 | </t> |
---|
1796 | <figure><artwork type="example"> |
---|
1797 | Location: http://www.w3.org/pub/WWW/People.html |
---|
1798 | </artwork></figure> |
---|
1799 | <t> |
---|
1800 | <list><t> |
---|
1801 | <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs |
---|
1802 | from Location in that the Content-Location identifies the original |
---|
1803 | location of the entity enclosed in the request. It is therefore |
---|
1804 | possible for a response to contain header fields for both Location |
---|
1805 | and Content-Location. |
---|
1806 | </t></list> |
---|
1807 | </t> |
---|
1808 | </section> |
---|
1809 | |
---|
1810 | <section title="Max-Forwards" anchor="header.max-forwards"> |
---|
1811 | <iref primary="true" item="Max-Forwards header" x:for-anchor=""/> |
---|
1812 | <iref primary="true" item="Headers" subitem="Max-Forwards" x:for-anchor=""/> |
---|
1813 | <t> |
---|
1814 | The Max-Forwards request-header field provides a mechanism with the |
---|
1815 | TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the |
---|
1816 | number of proxies or gateways that can forward the request to the |
---|
1817 | next inbound server. This can be useful when the client is attempting |
---|
1818 | to trace a request chain which appears to be failing or looping in |
---|
1819 | mid-chain. |
---|
1820 | </t> |
---|
1821 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> |
---|
1822 | Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
---|
1823 | </artwork></figure> |
---|
1824 | <t> |
---|
1825 | The Max-Forwards value is a decimal integer indicating the remaining |
---|
1826 | number of times this request message may be forwarded. |
---|
1827 | </t> |
---|
1828 | <t> |
---|
1829 | Each proxy or gateway recipient of a TRACE or OPTIONS request |
---|
1830 | containing a Max-Forwards header field &MUST; check and update its |
---|
1831 | value prior to forwarding the request. If the received value is zero |
---|
1832 | (0), the recipient &MUST-NOT; forward the request; instead, it &MUST; |
---|
1833 | respond as the final recipient. If the received Max-Forwards value is |
---|
1834 | greater than zero, then the forwarded message &MUST; contain an updated |
---|
1835 | Max-Forwards field with a value decremented by one (1). |
---|
1836 | </t> |
---|
1837 | <t> |
---|
1838 | The Max-Forwards header field &MAY; be ignored for all other methods |
---|
1839 | defined by this specification and for any extension methods for which |
---|
1840 | it is not explicitly referred to as part of that method definition. |
---|
1841 | </t> |
---|
1842 | </section> |
---|
1843 | |
---|
1844 | <section title="Referer" anchor="header.referer"> |
---|
1845 | <iref primary="true" item="Referer header" x:for-anchor=""/> |
---|
1846 | <iref primary="true" item="Headers" subitem="Referer" x:for-anchor=""/> |
---|
1847 | <t> |
---|
1848 | The Referer[sic] request-header field allows the client to specify, |
---|
1849 | for the server's benefit, the address (URI) of the resource from |
---|
1850 | which the Request-URI was obtained (the "referrer", although the |
---|
1851 | header field is misspelled.) The Referer request-header allows a |
---|
1852 | server to generate lists of back-links to resources for interest, |
---|
1853 | logging, optimized caching, etc. It also allows obsolete or mistyped |
---|
1854 | links to be traced for maintenance. The Referer field &MUST-NOT; be |
---|
1855 | sent if the Request-URI was obtained from a source that does not have |
---|
1856 | its own URI, such as input from the user keyboard. |
---|
1857 | </t> |
---|
1858 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/> |
---|
1859 | Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
---|
1860 | </artwork></figure> |
---|
1861 | <t> |
---|
1862 | Example: |
---|
1863 | </t> |
---|
1864 | <figure><artwork type="example"> |
---|
1865 | Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
---|
1866 | </artwork></figure> |
---|
1867 | <t> |
---|
1868 | If the field value is a relative URI, it &SHOULD; be interpreted |
---|
1869 | relative to the Request-URI. The URI &MUST-NOT; include a fragment. See |
---|
1870 | <xref target="encoding.sensitive.information.in.uris"/> for security considerations. |
---|
1871 | </t> |
---|
1872 | </section> |
---|
1873 | |
---|
1874 | <section title="Retry-After" anchor="header.retry-after"> |
---|
1875 | <iref primary="true" item="Retry-After header" x:for-anchor=""/> |
---|
1876 | <iref primary="true" item="Headers" subitem="Retry-After" x:for-anchor=""/> |
---|
1877 | <t> |
---|
1878 | The Retry-After response-header field can be used with a 503 (Service |
---|
1879 | Unavailable) response to indicate how long the service is expected to |
---|
1880 | be unavailable to the requesting client. This field &MAY; also be used |
---|
1881 | with any 3xx (Redirection) response to indicate the minimum time the |
---|
1882 | user-agent is asked wait before issuing the redirected request. The |
---|
1883 | value of this field can be either an HTTP-date or an integer number |
---|
1884 | of seconds (in decimal) after the time of the response. |
---|
1885 | </t> |
---|
1886 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/> |
---|
1887 | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
---|
1888 | </artwork></figure> |
---|
1889 | <t> |
---|
1890 | Two examples of its use are |
---|
1891 | </t> |
---|
1892 | <figure><artwork type="example"> |
---|
1893 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
---|
1894 | Retry-After: 120 |
---|
1895 | </artwork></figure> |
---|
1896 | <t> |
---|
1897 | In the latter example, the delay is 2 minutes. |
---|
1898 | </t> |
---|
1899 | </section> |
---|
1900 | |
---|
1901 | <section title="Server" anchor="header.server"> |
---|
1902 | <iref primary="true" item="Server header" x:for-anchor=""/> |
---|
1903 | <iref primary="true" item="Headers" subitem="Server" x:for-anchor=""/> |
---|
1904 | <t> |
---|
1905 | The Server response-header field contains information about the |
---|
1906 | software used by the origin server to handle the request. The field |
---|
1907 | can contain multiple product tokens (<xref target="product.tokens"/>) and comments |
---|
1908 | identifying the server and any significant subproducts. The product |
---|
1909 | tokens are listed in order of their significance for identifying the |
---|
1910 | application. |
---|
1911 | </t> |
---|
1912 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/> |
---|
1913 | Server = "Server" ":" 1*( product | comment ) |
---|
1914 | </artwork></figure> |
---|
1915 | <t> |
---|
1916 | Example: |
---|
1917 | </t> |
---|
1918 | <figure><artwork type="example"> |
---|
1919 | Server: CERN/3.0 libwww/2.17 |
---|
1920 | </artwork></figure> |
---|
1921 | <t> |
---|
1922 | If the response is being forwarded through a proxy, the proxy |
---|
1923 | application &MUST-NOT; modify the Server response-header. Instead, it |
---|
1924 | &SHOULD; include a Via field (as described in &header-via;). |
---|
1925 | <list><t> |
---|
1926 | <x:h>Note:</x:h> Revealing the specific software version of the server might |
---|
1927 | allow the server machine to become more vulnerable to attacks |
---|
1928 | against software that is known to contain security holes. Server |
---|
1929 | implementors are encouraged to make this field a configurable |
---|
1930 | option. |
---|
1931 | </t></list> |
---|
1932 | </t> |
---|
1933 | </section> |
---|
1934 | |
---|
1935 | <section title="User-Agent" anchor="header.user-agent"> |
---|
1936 | <iref primary="true" item="User-Agent header" x:for-anchor=""/> |
---|
1937 | <iref primary="true" item="Headers" subitem="User-Agent" x:for-anchor=""/> |
---|
1938 | <t> |
---|
1939 | The User-Agent request-header field contains information about the |
---|
1940 | user agent originating the request. This is for statistical purposes, |
---|
1941 | the tracing of protocol violations, and automated recognition of user |
---|
1942 | agents for the sake of tailoring responses to avoid particular user |
---|
1943 | agent limitations. User agents &SHOULD; include this field with |
---|
1944 | requests. The field can contain multiple product tokens (<xref target="product.tokens"/>) |
---|
1945 | and comments identifying the agent and any subproducts which form a |
---|
1946 | significant part of the user agent. By convention, the product tokens |
---|
1947 | are listed in order of their significance for identifying the |
---|
1948 | application. |
---|
1949 | </t> |
---|
1950 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/> |
---|
1951 | User-Agent = "User-Agent" ":" 1*( product | comment ) |
---|
1952 | </artwork></figure> |
---|
1953 | <t> |
---|
1954 | Example: |
---|
1955 | </t> |
---|
1956 | <figure><artwork type="example"> |
---|
1957 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
1958 | </artwork></figure> |
---|
1959 | </section> |
---|
1960 | |
---|
1961 | </section> |
---|
1962 | |
---|
1963 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
1964 | <t> |
---|
1965 | TBD. |
---|
1966 | </t> |
---|
1967 | </section> |
---|
1968 | |
---|
1969 | <section title="Security Considerations" anchor="security.considerations"> |
---|
1970 | <t> |
---|
1971 | This section is meant to inform application developers, information |
---|
1972 | providers, and users of the security limitations in HTTP/1.1 as |
---|
1973 | described by this document. The discussion does not include |
---|
1974 | definitive solutions to the problems revealed, though it does make |
---|
1975 | some suggestions for reducing security risks. |
---|
1976 | </t> |
---|
1977 | |
---|
1978 | <section title="Transfer of Sensitive Information" anchor="security.sensitive"> |
---|
1979 | <t> |
---|
1980 | Like any generic data transfer protocol, HTTP cannot regulate the |
---|
1981 | content of the data that is transferred, nor is there any a priori |
---|
1982 | method of determining the sensitivity of any particular piece of |
---|
1983 | information within the context of any given request. Therefore, |
---|
1984 | applications &SHOULD; supply as much control over this information as |
---|
1985 | possible to the provider of that information. Four header fields are |
---|
1986 | worth special mention in this context: Server, Via, Referer and From. |
---|
1987 | </t> |
---|
1988 | <t> |
---|
1989 | Revealing the specific software version of the server might allow the |
---|
1990 | server machine to become more vulnerable to attacks against software |
---|
1991 | that is known to contain security holes. Implementors &SHOULD; make the |
---|
1992 | Server header field a configurable option. |
---|
1993 | </t> |
---|
1994 | <t> |
---|
1995 | Proxies which serve as a portal through a network firewall &SHOULD; |
---|
1996 | take special precautions regarding the transfer of header information |
---|
1997 | that identifies the hosts behind the firewall. In particular, they |
---|
1998 | &SHOULD; remove, or replace with sanitized versions, any Via fields |
---|
1999 | generated behind the firewall. |
---|
2000 | </t> |
---|
2001 | <t> |
---|
2002 | The Referer header allows reading patterns to be studied and reverse |
---|
2003 | links drawn. Although it can be very useful, its power can be abused |
---|
2004 | if user details are not separated from the information contained in |
---|
2005 | the Referer. Even when the personal information has been removed, the |
---|
2006 | Referer header might indicate a private document's URI whose |
---|
2007 | publication would be inappropriate. |
---|
2008 | </t> |
---|
2009 | <t> |
---|
2010 | The information sent in the From field might conflict with the user's |
---|
2011 | privacy interests or their site's security policy, and hence it |
---|
2012 | &SHOULD-NOT; be transmitted without the user being able to disable, |
---|
2013 | enable, and modify the contents of the field. The user &MUST; be able |
---|
2014 | to set the contents of this field within a user preference or |
---|
2015 | application defaults configuration. |
---|
2016 | </t> |
---|
2017 | <t> |
---|
2018 | We suggest, though do not require, that a convenient toggle interface |
---|
2019 | be provided for the user to enable or disable the sending of From and |
---|
2020 | Referer information. |
---|
2021 | </t> |
---|
2022 | <t> |
---|
2023 | The User-Agent (<xref target="header.user-agent"/>) or Server (<xref target="header.server"/>) header |
---|
2024 | fields can sometimes be used to determine that a specific client or |
---|
2025 | server have a particular security hole which might be exploited. |
---|
2026 | Unfortunately, this same information is often used for other valuable |
---|
2027 | purposes for which HTTP currently has no better mechanism. |
---|
2028 | </t> |
---|
2029 | </section> |
---|
2030 | |
---|
2031 | <section title="Encoding Sensitive Information in URI's" anchor="encoding.sensitive.information.in.uris"> |
---|
2032 | <t> |
---|
2033 | Because the source of a link might be private information or might |
---|
2034 | reveal an otherwise private information source, it is strongly |
---|
2035 | recommended that the user be able to select whether or not the |
---|
2036 | Referer field is sent. For example, a browser client could have a |
---|
2037 | toggle switch for browsing openly/anonymously, which would |
---|
2038 | respectively enable/disable the sending of Referer and From |
---|
2039 | information. |
---|
2040 | </t> |
---|
2041 | <t> |
---|
2042 | Clients &SHOULD-NOT; include a Referer header field in a (non-secure) |
---|
2043 | HTTP request if the referring page was transferred with a secure |
---|
2044 | protocol. |
---|
2045 | </t> |
---|
2046 | <t> |
---|
2047 | Authors of services which use the HTTP protocol &SHOULD-NOT; use GET |
---|
2048 | based forms for the submission of sensitive data, because this will |
---|
2049 | cause this data to be encoded in the Request-URI. Many existing |
---|
2050 | servers, proxies, and user agents will log the request URI in some |
---|
2051 | place where it might be visible to third parties. Servers can use |
---|
2052 | POST-based form submission instead |
---|
2053 | </t> |
---|
2054 | </section> |
---|
2055 | |
---|
2056 | <section title="Location Headers and Spoofing" anchor="location.spoofing"> |
---|
2057 | <t> |
---|
2058 | If a single server supports multiple organizations that do not trust |
---|
2059 | one another, then it &MUST; check the values of Location and Content-Location |
---|
2060 | headers in responses that are generated under control of |
---|
2061 | said organizations to make sure that they do not attempt to |
---|
2062 | invalidate resources over which they have no authority. |
---|
2063 | </t> |
---|
2064 | </section> |
---|
2065 | |
---|
2066 | </section> |
---|
2067 | |
---|
2068 | <section title="Acknowledgments" anchor="ack"> |
---|
2069 | <t> |
---|
2070 | Based on an XML translation of RFC 2616 by Julian Reschke. |
---|
2071 | </t> |
---|
2072 | </section> |
---|
2073 | </middle> |
---|
2074 | <back> |
---|
2075 | <references> |
---|
2076 | |
---|
2077 | <reference anchor="RFC1123"> |
---|
2078 | <front> |
---|
2079 | <title>Requirements for Internet Hosts - Application and Support</title> |
---|
2080 | <author initials="R." surname="Braden" fullname="Robert Braden"> |
---|
2081 | <organization>University of Southern California (USC), Information Sciences Institute</organization> |
---|
2082 | <address> |
---|
2083 | <postal> |
---|
2084 | <street>4676 Admiralty Way</street> |
---|
2085 | <city>Marina del Rey</city> |
---|
2086 | <region>CA</region> |
---|
2087 | <code>90292-6695</code> |
---|
2088 | <country>US</country></postal> |
---|
2089 | <phone>+1 213 822 1511</phone> |
---|
2090 | <email>Braden@ISI.EDU</email></address></author> |
---|
2091 | <date month="October" year="1989"/></front> |
---|
2092 | <seriesInfo name="STD" value="3"/> |
---|
2093 | <seriesInfo name="RFC" value="1123"/> |
---|
2094 | </reference> |
---|
2095 | |
---|
2096 | <reference anchor="RFC822"> |
---|
2097 | <front> |
---|
2098 | <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> |
---|
2099 | <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> |
---|
2100 | <organization>University of Delaware, Dept. of Electrical Engineering</organization> |
---|
2101 | <address> |
---|
2102 | <postal> |
---|
2103 | <street/> |
---|
2104 | <city>Newark</city> |
---|
2105 | <region>DE</region> |
---|
2106 | <code>19711</code> |
---|
2107 | <country>US</country></postal> |
---|
2108 | <email>DCrocker@UDel-Relay</email></address></author> |
---|
2109 | <date month="August" day="13" year="1982"/></front> |
---|
2110 | <seriesInfo name="STD" value="11"/> |
---|
2111 | <seriesInfo name="RFC" value="822"/> |
---|
2112 | </reference> |
---|
2113 | |
---|
2114 | <reference anchor="RFC2068"> |
---|
2115 | <front> |
---|
2116 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
2117 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
2118 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
2119 | <address> |
---|
2120 | <postal> |
---|
2121 | <street/> |
---|
2122 | <city>Irvine</city> |
---|
2123 | <region>CA</region> |
---|
2124 | <code>92717-3425</code> |
---|
2125 | <country>US</country></postal> |
---|
2126 | <facsimile>+1 714 824 4056</facsimile> |
---|
2127 | <email>fielding@ics.uci.edu</email></address></author> |
---|
2128 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
2129 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2130 | <address> |
---|
2131 | <postal> |
---|
2132 | <street>545 Technology Square</street> |
---|
2133 | <city>Cambridge</city> |
---|
2134 | <region>MA</region> |
---|
2135 | <code>02139</code> |
---|
2136 | <country>US</country></postal> |
---|
2137 | <facsimile>+1 617 258 8682</facsimile> |
---|
2138 | <email>jg@w3.org</email></address></author> |
---|
2139 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
2140 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
2141 | <address> |
---|
2142 | <postal> |
---|
2143 | <street>250 University Avenue</street> |
---|
2144 | <city>Palo Alto</city> |
---|
2145 | <region>CA</region> |
---|
2146 | <code>94301</code> |
---|
2147 | <country>US</country></postal> |
---|
2148 | <email>mogul@wrl.dec.com</email></address></author> |
---|
2149 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
2150 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2151 | <address> |
---|
2152 | <postal> |
---|
2153 | <street>545 Technology Square</street> |
---|
2154 | <city>Cambridge</city> |
---|
2155 | <region>MA</region> |
---|
2156 | <code>02139</code> |
---|
2157 | <country>US</country></postal> |
---|
2158 | <facsimile>+1 617 258 8682</facsimile> |
---|
2159 | <email>frystyk@w3.org</email></address></author> |
---|
2160 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
2161 | <organization>MIT Laboratory for Computer Science</organization> |
---|
2162 | <address> |
---|
2163 | <postal> |
---|
2164 | <street>545 Technology Square</street> |
---|
2165 | <city>Cambridge</city> |
---|
2166 | <region>MA</region> |
---|
2167 | <code>02139</code> |
---|
2168 | <country>US</country></postal> |
---|
2169 | <facsimile>+1 617 258 8682</facsimile> |
---|
2170 | <email>timbl@w3.org</email></address></author> |
---|
2171 | <date month="January" year="1997"/> |
---|
2172 | <abstract> |
---|
2173 | <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t> |
---|
2174 | <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front> |
---|
2175 | <seriesInfo name="RFC" value="2068"/> |
---|
2176 | </reference> |
---|
2177 | |
---|
2178 | <reference anchor="RFC2617"> |
---|
2179 | <front> |
---|
2180 | <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> |
---|
2181 | <author initials="J." surname="Franks" fullname="John Franks"> |
---|
2182 | <organization>Northwestern University, Department of Mathematics</organization> |
---|
2183 | <address> |
---|
2184 | <postal> |
---|
2185 | <street/> |
---|
2186 | <city>Evanston</city> |
---|
2187 | <region>IL</region> |
---|
2188 | <code>60208-2730</code> |
---|
2189 | <country>US</country></postal> |
---|
2190 | <email>john@math.nwu.edu</email></address></author> |
---|
2191 | <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> |
---|
2192 | <organization>Verisign Inc.</organization> |
---|
2193 | <address> |
---|
2194 | <postal> |
---|
2195 | <street>301 Edgewater Place</street> |
---|
2196 | <street>Suite 210</street> |
---|
2197 | <city>Wakefield</city> |
---|
2198 | <region>MA</region> |
---|
2199 | <code>01880</code> |
---|
2200 | <country>US</country></postal> |
---|
2201 | <email>pbaker@verisign.com</email></address></author> |
---|
2202 | <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> |
---|
2203 | <organization>AbiSource, Inc.</organization> |
---|
2204 | <address> |
---|
2205 | <postal> |
---|
2206 | <street>6 Dunlap Court</street> |
---|
2207 | <city>Savoy</city> |
---|
2208 | <region>IL</region> |
---|
2209 | <code>61874</code> |
---|
2210 | <country>US</country></postal> |
---|
2211 | <email>jeff@AbiSource.com</email></address></author> |
---|
2212 | <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> |
---|
2213 | <organization>Agranat Systems, Inc.</organization> |
---|
2214 | <address> |
---|
2215 | <postal> |
---|
2216 | <street>5 Clocktower Place</street> |
---|
2217 | <street>Suite 400</street> |
---|
2218 | <city>Maynard</city> |
---|
2219 | <region>MA</region> |
---|
2220 | <code>01754</code> |
---|
2221 | <country>US</country></postal> |
---|
2222 | <email>lawrence@agranat.com</email></address></author> |
---|
2223 | <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> |
---|
2224 | <organization>Microsoft Corporation</organization> |
---|
2225 | <address> |
---|
2226 | <postal> |
---|
2227 | <street>1 Microsoft Way</street> |
---|
2228 | <city>Redmond</city> |
---|
2229 | <region>WA</region> |
---|
2230 | <code>98052</code> |
---|
2231 | <country>US</country></postal> |
---|
2232 | <email>paulle@microsoft.com</email></address></author> |
---|
2233 | <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> |
---|
2234 | <organization>Netscape Communications Corporation</organization> |
---|
2235 | <address> |
---|
2236 | <postal> |
---|
2237 | <street>501 East Middlefield Road</street> |
---|
2238 | <city>Mountain View</city> |
---|
2239 | <region>CA</region> |
---|
2240 | <code>94043</code> |
---|
2241 | <country>US</country></postal></address></author> |
---|
2242 | <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> |
---|
2243 | <organization>Open Market, Inc.</organization> |
---|
2244 | <address> |
---|
2245 | <postal> |
---|
2246 | <street>215 First Street</street> |
---|
2247 | <city>Cambridge</city> |
---|
2248 | <region>MA</region> |
---|
2249 | <code>02142</code> |
---|
2250 | <country>US</country></postal> |
---|
2251 | <email>stewart@OpenMarket.com</email></address></author> |
---|
2252 | <date month="June" year="1999"/> |
---|
2253 | </front> |
---|
2254 | <seriesInfo name="RFC" value="2617"/> |
---|
2255 | </reference> |
---|
2256 | |
---|
2257 | <reference anchor="Luo1998"> |
---|
2258 | <front> |
---|
2259 | <title>Tunneling TCP based protocols through Web proxy servers</title> |
---|
2260 | <author initials="A." surname="Luotonen" fullname="A. Luotonen"> |
---|
2261 | <organization/> |
---|
2262 | </author> |
---|
2263 | <date/> |
---|
2264 | </front> |
---|
2265 | <seriesInfo name="" value="Work in Progress"/> |
---|
2266 | </reference> |
---|
2267 | |
---|
2268 | </references> |
---|
2269 | |
---|
2270 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
2271 | <t> |
---|
2272 | Clarified which error code should be used for inbound server failures |
---|
2273 | (e.g. DNS failures). (<xref target="status.504"/>). |
---|
2274 | </t> |
---|
2275 | <t> |
---|
2276 | CREATE had a race that required an Etag be sent when a resource is |
---|
2277 | first created. (<xref target="status.201"/>). |
---|
2278 | </t> |
---|
2279 | <t> |
---|
2280 | Rewrite of message transmission requirements to make it much harder |
---|
2281 | for implementors to get it wrong, as the consequences of errors here |
---|
2282 | can have significant impact on the Internet, and to deal with the |
---|
2283 | following problems: |
---|
2284 | <list style="numbers"> |
---|
2285 | <t>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where |
---|
2286 | this was incorrectly placing a requirement on the behavior of |
---|
2287 | an implementation of a future version of HTTP/1.x</t> |
---|
2288 | |
---|
2289 | <t>Made it clear that user-agents should retry requests, not |
---|
2290 | "clients" in general.</t> |
---|
2291 | |
---|
2292 | <t>Converted requirements for clients to ignore unexpected 100 |
---|
2293 | (Continue) responses, and for proxies to forward 100 responses, |
---|
2294 | into a general requirement for 1xx responses.</t> |
---|
2295 | |
---|
2296 | <t>Modified some TCP-specific language, to make it clearer that |
---|
2297 | non-TCP transports are possible for HTTP.</t> |
---|
2298 | |
---|
2299 | <t>Require that the origin server &MUST-NOT; wait for the request |
---|
2300 | body before it sends a required 100 (Continue) response.</t> |
---|
2301 | |
---|
2302 | <t>Allow, rather than require, a server to omit 100 (Continue) if |
---|
2303 | it has already seen some of the request body.</t> |
---|
2304 | |
---|
2305 | <t>Allow servers to defend against denial-of-service attacks and |
---|
2306 | broken clients.</t> |
---|
2307 | </list> |
---|
2308 | </t> |
---|
2309 | <t> |
---|
2310 | This change adds the Expect header and 417 status code. |
---|
2311 | </t> |
---|
2312 | <t> |
---|
2313 | Clean up confusion between 403 and 404 responses. (Section <xref target="status.403" format="counter"/>, |
---|
2314 | <xref target="status.404" format="counter"/>, and <xref target="status.410" format="counter"/>) |
---|
2315 | </t> |
---|
2316 | <t> |
---|
2317 | 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 |
---|
2318 | implemented in previous versions of this specification. See RFC 2068 |
---|
2319 | <xref target="RFC2068"/>. |
---|
2320 | </t> |
---|
2321 | </section> |
---|
2322 | </back> |
---|
2323 | </rfc> |
---|