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