1 | | <!DOCTYPE html |
2 | | PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
3 | | <html lang="en"> |
4 | | <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> |
5 | | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
6 | | <title>HTTP/1.1, part 2: Message Semantics</title><script> |
7 | | var buttonsAdded = false; |
8 | | |
9 | | function init() { |
10 | | var fb = document.createElement("div"); |
11 | | fb.className = "feedback noprint"; |
12 | | fb.setAttribute("onclick", "feedback();"); |
13 | | fb.appendChild(document.createTextNode("feedback")); |
14 | | |
15 | | var bodyl = document.getElementsByTagName("body"); |
16 | | bodyl.item(0).appendChild(fb); |
17 | | } |
18 | | |
19 | | function feedback() { |
20 | | toggleButtonsToElementsByName("h1"); |
21 | | toggleButtonsToElementsByName("h2"); |
22 | | toggleButtonsToElementsByName("h3"); |
23 | | toggleButtonsToElementsByName("h4"); |
24 | | |
25 | | buttonsAdded = !buttonsAdded; |
26 | | } |
27 | | |
28 | | function toggleButtonsToElementsByName(name) { |
29 | | var list = document.getElementsByTagName(name); |
30 | | for (var i = 0; i < list.length; i++) { |
31 | | toggleButton(list.item(i)); |
32 | | } |
33 | | } |
34 | | |
35 | | function toggleButton(node) { |
36 | | if (! buttonsAdded) { |
37 | | |
38 | | // docname |
39 | | var template = "mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"; |
40 | | |
41 | | var id = node.getAttribute("id"); |
42 | | // better id available? |
43 | | var titlelinks = node.getElementsByTagName("a"); |
44 | | for (var i = 0; i < titlelinks.length; i++) { |
45 | | var tl = titlelinks.item(i); |
46 | | if (tl.getAttribute("id")) { |
47 | | id = tl.getAttribute("id"); |
48 | | } |
49 | | } |
50 | | |
51 | | // ref |
52 | | var ref = window.location.toString(); |
53 | | var hash = ref.indexOf("#"); |
54 | | if (hash != -1) { |
55 | | ref = ref.substring(0, hash); |
56 | | } |
57 | | if (id != "") { |
58 | | ref += "#" + id; |
59 | | } |
60 | | |
61 | | // docname |
62 | | var docname = "draft-ietf-httpbis-p2-semantics-latest"; |
63 | | |
64 | | // section |
65 | | var section = node.textContent; |
66 | | section = section.replace("\u00a0", " "); |
67 | | |
68 | | // build URI from template |
69 | | var uri = template.replace("{docname}", encodeURIComponent(docname)); |
70 | | uri = uri.replace("{section}", encodeURIComponent(section)); |
71 | | uri = uri.replace("{ref}", encodeURIComponent(ref)); |
72 | | |
73 | | var button = document.createElement("a"); |
74 | | button.className = "fbbutton noprint"; |
75 | | button.setAttribute("href", uri); |
76 | | button.appendChild(document.createTextNode("send feedback")); |
77 | | node.appendChild(button); |
78 | | } |
79 | | else { |
80 | | var buttons = node.getElementsByTagName("a"); |
81 | | for (var i = 0; i < buttons.length; i++) { |
82 | | var b = buttons.item(i); |
83 | | if (b.className == "fbbutton noprint") { |
84 | | node.removeChild(b); |
85 | | } |
86 | | } |
87 | | } |
88 | | }</script><style type="text/css" title="Xml2Rfc (sans serif)"> |
89 | | a { |
90 | | text-decoration: none; |
91 | | } |
92 | | a.smpl { |
93 | | color: black; |
94 | | } |
95 | | a:hover { |
96 | | text-decoration: underline; |
97 | | } |
98 | | a:active { |
99 | | text-decoration: underline; |
100 | | } |
101 | | address { |
102 | | margin-top: 1em; |
103 | | margin-left: 2em; |
104 | | font-style: normal; |
105 | | } |
106 | | body { |
107 | | color: black; |
108 | | font-family: verdana, helvetica, arial, sans-serif; |
109 | | font-size: 10pt; |
110 | | } |
111 | | cite { |
112 | | font-style: normal; |
113 | | } |
114 | | div.note { |
115 | | margin-left: 2em; |
116 | | } |
117 | | dd { |
118 | | margin-right: 2em; |
119 | | } |
120 | | dl { |
121 | | margin-left: 2em; |
122 | | } |
123 | | |
124 | | ul.empty { |
125 | | list-style-type: none; |
126 | | } |
127 | | ul.empty li { |
128 | | margin-top: .5em; |
129 | | } |
130 | | dl p { |
131 | | margin-left: 0em; |
132 | | } |
133 | | dt { |
134 | | margin-top: .5em; |
135 | | } |
136 | | h1 { |
137 | | font-size: 14pt; |
138 | | line-height: 21pt; |
139 | | page-break-after: avoid; |
140 | | } |
141 | | h1.np { |
142 | | page-break-before: always; |
143 | | } |
144 | | h1 a { |
145 | | color: #333333; |
146 | | } |
147 | | h2 { |
148 | | font-size: 12pt; |
149 | | line-height: 15pt; |
150 | | page-break-after: avoid; |
151 | | } |
152 | | h3, h4, h5, h6 { |
153 | | font-size: 10pt; |
154 | | page-break-after: avoid; |
155 | | } |
156 | | h2 a, h3 a, h4 a, h5 a, h6 a { |
157 | | color: black; |
158 | | } |
159 | | img { |
160 | | margin-left: 3em; |
161 | | } |
162 | | li { |
163 | | margin-left: 2em; |
164 | | margin-right: 2em; |
165 | | } |
166 | | ol { |
167 | | margin-left: 2em; |
168 | | margin-right: 2em; |
169 | | } |
170 | | ol.la { |
171 | | list-style-type: lower-alpha; |
172 | | } |
173 | | ol.ua { |
174 | | list-style-type: upper-alpha; |
175 | | } |
176 | | ol p { |
177 | | margin-left: 0em; |
178 | | } |
179 | | p { |
180 | | margin-left: 2em; |
181 | | margin-right: 2em; |
182 | | } |
183 | | pre { |
184 | | margin-left: 3em; |
185 | | background-color: lightyellow; |
186 | | padding: .25em; |
187 | | } |
188 | | pre.text2 { |
189 | | border-style: dotted; |
190 | | border-width: 1px; |
191 | | background-color: #f0f0f0; |
192 | | width: 69em; |
193 | | } |
194 | | pre.inline { |
195 | | background-color: white; |
196 | | padding: 0em; |
197 | | } |
198 | | pre.text { |
199 | | border-style: dotted; |
200 | | border-width: 1px; |
201 | | background-color: #f8f8f8; |
202 | | width: 69em; |
203 | | } |
204 | | pre.drawing { |
205 | | border-style: solid; |
206 | | border-width: 1px; |
207 | | background-color: #f8f8f8; |
208 | | padding: 2em; |
209 | | } |
210 | | table { |
211 | | margin-left: 2em; |
212 | | } |
213 | | table.tt { |
214 | | vertical-align: top; |
215 | | } |
216 | | table.full { |
217 | | border-style: outset; |
218 | | border-width: 1px; |
219 | | } |
220 | | table.headers { |
221 | | border-style: outset; |
222 | | border-width: 1px; |
223 | | } |
224 | | table.tt td { |
225 | | vertical-align: top; |
226 | | } |
227 | | table.full td { |
228 | | border-style: inset; |
229 | | border-width: 1px; |
230 | | } |
231 | | table.tt th { |
232 | | vertical-align: top; |
233 | | } |
234 | | table.full th { |
235 | | border-style: inset; |
236 | | border-width: 1px; |
237 | | } |
238 | | table.headers th { |
239 | | border-style: none none inset none; |
240 | | border-width: 1px; |
241 | | } |
242 | | table.left { |
243 | | margin-right: auto; |
244 | | } |
245 | | table.right { |
246 | | margin-left: auto; |
247 | | } |
248 | | table.center { |
249 | | margin-left: auto; |
250 | | margin-right: auto; |
251 | | } |
252 | | caption { |
253 | | caption-side: bottom; |
254 | | font-weight: bold; |
255 | | font-size: 9pt; |
256 | | margin-top: .5em; |
257 | | } |
258 | | |
259 | | table.header { |
260 | | border-spacing: 1px; |
261 | | width: 95%; |
262 | | font-size: 10pt; |
263 | | color: white; |
264 | | } |
265 | | td.top { |
266 | | vertical-align: top; |
267 | | } |
268 | | td.topnowrap { |
269 | | vertical-align: top; |
270 | | white-space: nowrap; |
271 | | } |
272 | | table.header td { |
273 | | background-color: gray; |
274 | | width: 50%; |
275 | | } |
276 | | table.header a { |
277 | | color: white; |
278 | | } |
279 | | td.reference { |
280 | | vertical-align: top; |
281 | | white-space: nowrap; |
282 | | padding-right: 1em; |
283 | | } |
284 | | thead { |
285 | | display:table-header-group; |
286 | | } |
287 | | ul.toc, ul.toc ul { |
288 | | list-style: none; |
289 | | margin-left: 1.5em; |
290 | | margin-right: 0em; |
291 | | padding-left: 0em; |
292 | | } |
293 | | ul.toc li { |
294 | | line-height: 150%; |
295 | | font-weight: bold; |
296 | | font-size: 10pt; |
297 | | margin-left: 0em; |
298 | | margin-right: 0em; |
299 | | } |
300 | | ul.toc li li { |
301 | | line-height: normal; |
302 | | font-weight: normal; |
303 | | font-size: 9pt; |
304 | | margin-left: 0em; |
305 | | margin-right: 0em; |
306 | | } |
307 | | li.excluded { |
308 | | font-size: 0pt; |
309 | | } |
310 | | ul p { |
311 | | margin-left: 0em; |
312 | | } |
313 | | ul.ind, ul.ind ul { |
314 | | list-style: none; |
315 | | margin-left: 1.5em; |
316 | | margin-right: 0em; |
317 | | padding-left: 0em; |
318 | | page-break-before: avoid; |
319 | | } |
320 | | ul.ind li { |
321 | | font-weight: bold; |
322 | | line-height: 200%; |
323 | | margin-left: 0em; |
324 | | margin-right: 0em; |
325 | | } |
326 | | ul.ind li li { |
327 | | font-weight: normal; |
328 | | line-height: 150%; |
329 | | margin-left: 0em; |
330 | | margin-right: 0em; |
331 | | } |
332 | | .avoidbreak { |
333 | | page-break-inside: avoid; |
334 | | } |
335 | | .bcp14 { |
336 | | font-style: normal; |
337 | | text-transform: lowercase; |
338 | | font-variant: small-caps; |
339 | | } |
340 | | .comment { |
341 | | background-color: yellow; |
342 | | } |
343 | | .center { |
344 | | text-align: center; |
345 | | } |
346 | | .error { |
347 | | color: red; |
348 | | font-style: italic; |
349 | | font-weight: bold; |
350 | | } |
351 | | .figure { |
352 | | font-weight: bold; |
353 | | text-align: center; |
354 | | font-size: 9pt; |
355 | | } |
356 | | .filename { |
357 | | color: #333333; |
358 | | font-weight: bold; |
359 | | font-size: 12pt; |
360 | | line-height: 21pt; |
361 | | text-align: center; |
362 | | } |
363 | | .fn { |
364 | | font-weight: bold; |
365 | | } |
366 | | .hidden { |
367 | | display: none; |
368 | | } |
369 | | .left { |
370 | | text-align: left; |
371 | | } |
372 | | .right { |
373 | | text-align: right; |
374 | | } |
375 | | .title { |
376 | | color: #990000; |
377 | | font-size: 18pt; |
378 | | line-height: 18pt; |
379 | | font-weight: bold; |
380 | | text-align: center; |
381 | | margin-top: 36pt; |
382 | | } |
383 | | .vcardline { |
384 | | display: block; |
385 | | } |
386 | | .warning { |
387 | | font-size: 14pt; |
388 | | background-color: yellow; |
389 | | } |
390 | | .feedback { |
391 | | position: fixed; |
392 | | bottom: 1%; |
393 | | right: 1%; |
394 | | padding: 3px 5px; |
395 | | color: white; |
396 | | border-radius: 5px; |
397 | | background: #a00000; |
398 | | border: 1px solid silver; |
399 | | } |
400 | | .fbbutton { |
401 | | margin-left: 1em; |
402 | | color: #303030; |
403 | | font-size: small; |
404 | | font-weight: normal; |
405 | | background: #d0d000; |
406 | | padding: 1px 4px; |
407 | | border: 1px solid silver; |
408 | | border-radius: 5px; |
409 | | } |
410 | | |
411 | | @media print { |
412 | | .noprint { |
413 | | display: none; |
414 | | } |
415 | | |
416 | | a { |
417 | | color: black; |
418 | | text-decoration: none; |
419 | | } |
420 | | |
421 | | table.header { |
422 | | width: 90%; |
423 | | } |
424 | | |
425 | | td.header { |
426 | | width: 50%; |
427 | | color: black; |
428 | | background-color: white; |
429 | | vertical-align: top; |
430 | | font-size: 12pt; |
431 | | } |
432 | | |
433 | | ul.toc a::after { |
434 | | content: leader('.') target-counter(attr(href), page); |
435 | | } |
436 | | |
437 | | ul.ind li li a { |
438 | | content: target-counter(attr(href), page); |
439 | | } |
440 | | |
441 | | .print2col { |
442 | | column-count: 2; |
443 | | -moz-column-count: 2; |
444 | | column-fill: auto; |
445 | | } |
446 | | } |
447 | | |
448 | | @page { |
449 | | @top-left { |
450 | | content: "Internet-Draft"; |
451 | | } |
452 | | @top-right { |
453 | | content: "March 2012"; |
454 | | } |
455 | | @top-center { |
456 | | content: "HTTP/1.1, Part 2"; |
457 | | } |
458 | | @bottom-left { |
459 | | content: "Fielding, et al."; |
460 | | } |
461 | | @bottom-center { |
462 | | content: "Expires September 2012"; |
463 | | } |
464 | | @bottom-right { |
465 | | content: "[Page " counter(page) "]"; |
466 | | } |
467 | | } |
468 | | |
469 | | @page:first { |
470 | | @top-left { |
471 | | content: normal; |
472 | | } |
473 | | @top-right { |
474 | | content: normal; |
475 | | } |
476 | | @top-center { |
477 | | content: normal; |
478 | | } |
479 | | } |
480 | | </style><link rel="Contents" href="#rfc.toc"> |
481 | | <link rel="Author" href="#rfc.authors"> |
482 | | <link rel="Copyright" href="#rfc.copyrightnotice"> |
483 | | <link rel="Index" href="#rfc.index"> |
484 | | <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> |
485 | | <link rel="Chapter" title="2 Method" href="#rfc.section.2"> |
486 | | <link rel="Chapter" title="3 Header Fields" href="#rfc.section.3"> |
487 | | <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4"> |
488 | | <link rel="Chapter" title="5 Representation" href="#rfc.section.5"> |
489 | | <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6"> |
490 | | <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7"> |
491 | | <link rel="Chapter" title="8 Date/Time Formats" href="#rfc.section.8"> |
492 | | <link rel="Chapter" title="9 Product Tokens" href="#rfc.section.9"> |
493 | | <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10"> |
494 | | <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"> |
495 | | <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12"> |
496 | | <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13"> |
497 | | <link rel="Chapter" href="#rfc.section.14" title="14 References"> |
498 | | <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> |
499 | | <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> |
500 | | <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> |
501 | | <link href="p1-messaging.html" rel="prev"> |
502 | | <link href="p3-payload.html" rel="next"> |
503 | | <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.570, 2012-02-13 19:17:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> |
504 | | <link rel="schema.dct" href="http://purl.org/dc/terms/"> |
505 | | <meta name="dct.creator" content="Fielding, R."> |
506 | | <meta name="dct.creator" content="Gettys, J."> |
507 | | <meta name="dct.creator" content="Mogul, J."> |
508 | | <meta name="dct.creator" content="Frystyk, H."> |
509 | | <meta name="dct.creator" content="Masinter, L."> |
510 | | <meta name="dct.creator" content="Leach, P."> |
511 | | <meta name="dct.creator" content="Berners-Lee, T."> |
512 | | <meta name="dct.creator" content="Lafon, Y."> |
513 | | <meta name="dct.creator" content="Reschke, J. F."> |
514 | | <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> |
515 | | <meta name="dct.issued" scheme="ISO8601" content="2012-03"> |
516 | | <meta name="dct.replaces" content="urn:ietf:rfc:2616"> |
517 | | <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> |
518 | | <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> |
519 | | </head> |
520 | | <body onload="init();"> |
521 | | <table class="header"> |
522 | | <tbody> |
523 | | <tr> |
524 | | <td class="left">HTTPbis Working Group</td> |
525 | | <td class="right">R. Fielding, Editor</td> |
526 | | </tr> |
527 | | <tr> |
528 | | <td class="left">Internet-Draft</td> |
529 | | <td class="right">Adobe</td> |
530 | | </tr> |
531 | | <tr> |
532 | | <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) |
533 | | </td> |
534 | | <td class="right">J. Gettys</td> |
535 | | </tr> |
536 | | <tr> |
537 | | <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2817">2817</a> (if approved) |
538 | | </td> |
539 | | <td class="right">Alcatel-Lucent</td> |
540 | | </tr> |
541 | | <tr> |
542 | | <td class="left">Intended status: Standards Track</td> |
543 | | <td class="right">J. Mogul</td> |
544 | | </tr> |
545 | | <tr> |
546 | | <td class="left">Expires: September 2012</td> |
547 | | <td class="right">HP</td> |
548 | | </tr> |
549 | | <tr> |
550 | | <td class="left"></td> |
551 | | <td class="right">H. Frystyk</td> |
552 | | </tr> |
553 | | <tr> |
554 | | <td class="left"></td> |
555 | | <td class="right">Microsoft</td> |
556 | | </tr> |
557 | | <tr> |
558 | | <td class="left"></td> |
559 | | <td class="right">L. Masinter</td> |
560 | | </tr> |
561 | | <tr> |
562 | | <td class="left"></td> |
563 | | <td class="right">Adobe</td> |
564 | | </tr> |
565 | | <tr> |
566 | | <td class="left"></td> |
567 | | <td class="right">P. Leach</td> |
568 | | </tr> |
569 | | <tr> |
570 | | <td class="left"></td> |
571 | | <td class="right">Microsoft</td> |
572 | | </tr> |
573 | | <tr> |
574 | | <td class="left"></td> |
575 | | <td class="right">T. Berners-Lee</td> |
576 | | </tr> |
577 | | <tr> |
578 | | <td class="left"></td> |
579 | | <td class="right">W3C/MIT</td> |
580 | | </tr> |
581 | | <tr> |
582 | | <td class="left"></td> |
583 | | <td class="right">Y. Lafon, Editor</td> |
584 | | </tr> |
585 | | <tr> |
586 | | <td class="left"></td> |
587 | | <td class="right">W3C</td> |
588 | | </tr> |
589 | | <tr> |
590 | | <td class="left"></td> |
591 | | <td class="right">J. Reschke, Editor</td> |
592 | | </tr> |
593 | | <tr> |
594 | | <td class="left"></td> |
595 | | <td class="right">greenbytes</td> |
596 | | </tr> |
597 | | <tr> |
598 | | <td class="left"></td> |
599 | | <td class="right">March 2012</td> |
600 | | </tr> |
601 | | </tbody> |
602 | | </table> |
603 | | <p class="title">HTTP/1.1, part 2: Message Semantics<br><span class="filename">draft-ietf-httpbis-p2-semantics-latest</span></p> |
604 | | <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> |
605 | | <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information |
606 | | systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the |
607 | | seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
608 | | </p> |
609 | | <p>Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, |
610 | | and response header fields. |
611 | | </p> |
612 | | <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> |
613 | | <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived |
614 | | at <<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>>. |
615 | | </p> |
616 | | <p>The current issues list is at <<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. |
617 | | </p> |
618 | | <p>The changes in this draft are summarized in <a href="#changes.since.18" title="Since draft-ietf-httpbis-p2-semantics-18">Appendix C.20</a>. |
619 | | </p> |
620 | | <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1> |
621 | | <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p> |
622 | | <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute |
623 | | working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>. |
624 | | </p> |
625 | | <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other |
626 | | documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work |
627 | | in progress”. |
628 | | </p> |
629 | | <p>This Internet-Draft will expire in September 2012.</p> |
630 | | <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> |
631 | | <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> |
632 | | <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights |
633 | | and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License |
634 | | text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified |
635 | | BSD License. |
636 | | </p> |
637 | | <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November |
638 | | 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to |
639 | | allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) |
640 | | controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative |
641 | | works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate |
642 | | it into languages other than English. |
643 | | </p> |
644 | | <hr class="noprint"> |
645 | | <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> |
646 | | <ul class="toc"> |
647 | | <li>1. <a href="#introduction">Introduction</a><ul> |
648 | | <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> |
649 | | <li>1.2 <a href="#notation">Syntax Notation</a><ul> |
650 | | <li>1.2.1 <a href="#core.rules">Core Rules</a></li> |
651 | | <li>1.2.2 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li> |
652 | | </ul> |
653 | | </li> |
654 | | </ul> |
655 | | </li> |
656 | | <li>2. <a href="#method">Method</a><ul> |
657 | | <li>2.1 <a href="#overview.of.methods">Overview of Methods</a></li> |
658 | | <li>2.2 <a href="#method.registry">Method Registry</a><ul> |
659 | | <li>2.2.1 <a href="#considerations.for.new.methods">Considerations for New Methods</a></li> |
660 | | </ul> |
661 | | </li> |
662 | | </ul> |
663 | | </li> |
664 | | <li>3. <a href="#header.fields">Header Fields</a><ul> |
665 | | <li>3.1 <a href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></li> |
666 | | <li>3.2 <a href="#request.header.fields">Request Header Fields</a></li> |
667 | | <li>3.3 <a href="#response.header.fields">Response Header Fields</a></li> |
668 | | </ul> |
669 | | </li> |
670 | | <li>4. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a><ul> |
671 | | <li>4.1 <a href="#overview.of.status.codes">Overview of Status Codes</a></li> |
672 | | <li>4.2 <a href="#status.code.registry">Status Code Registry</a><ul> |
673 | | <li>4.2.1 <a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li> |
674 | | </ul> |
675 | | </li> |
676 | | </ul> |
677 | | </li> |
678 | | <li>5. <a href="#representation">Representation</a><ul> |
679 | | <li>5.1 <a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li> |
680 | | </ul> |
681 | | </li> |
682 | | <li>6. <a href="#method.definitions">Method Definitions</a><ul> |
683 | | <li>6.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul> |
684 | | <li>6.1.1 <a href="#safe.methods">Safe Methods</a></li> |
685 | | <li>6.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> |
686 | | </ul> |
687 | | </li> |
688 | | <li>6.2 <a href="#OPTIONS">OPTIONS</a></li> |
689 | | <li>6.3 <a href="#GET">GET</a></li> |
690 | | <li>6.4 <a href="#HEAD">HEAD</a></li> |
691 | | <li>6.5 <a href="#POST">POST</a></li> |
692 | | <li>6.6 <a href="#PUT">PUT</a></li> |
693 | | <li>6.7 <a href="#DELETE">DELETE</a></li> |
694 | | <li>6.8 <a href="#TRACE">TRACE</a></li> |
695 | | <li>6.9 <a href="#CONNECT">CONNECT</a><ul> |
696 | | <li>6.9.1 <a href="#rfc.section.6.9.1">Establishing a Tunnel with CONNECT</a></li> |
697 | | </ul> |
698 | | </li> |
699 | | </ul> |
700 | | </li> |
701 | | <li>7. <a href="#status.codes">Status Code Definitions</a><ul> |
702 | | <li>7.1 <a href="#status.1xx">Informational 1xx</a><ul> |
703 | | <li>7.1.1 <a href="#status.100">100 Continue</a></li> |
704 | | <li>7.1.2 <a href="#status.101">101 Switching Protocols</a></li> |
705 | | </ul> |
706 | | </li> |
707 | | <li>7.2 <a href="#status.2xx">Successful 2xx</a><ul> |
708 | | <li>7.2.1 <a href="#status.200">200 OK</a></li> |
709 | | <li>7.2.2 <a href="#status.201">201 Created</a></li> |
710 | | <li>7.2.3 <a href="#status.202">202 Accepted</a></li> |
711 | | <li>7.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li> |
712 | | <li>7.2.5 <a href="#status.204">204 No Content</a></li> |
713 | | <li>7.2.6 <a href="#status.205">205 Reset Content</a></li> |
714 | | </ul> |
715 | | </li> |
716 | | <li>7.3 <a href="#status.3xx">Redirection 3xx</a><ul> |
717 | | <li>7.3.1 <a href="#status.300">300 Multiple Choices</a></li> |
718 | | <li>7.3.2 <a href="#status.301">301 Moved Permanently</a></li> |
719 | | <li>7.3.3 <a href="#status.302">302 Found</a></li> |
720 | | <li>7.3.4 <a href="#status.303">303 See Other</a></li> |
721 | | <li>7.3.5 <a href="#status.305">305 Use Proxy</a></li> |
722 | | <li>7.3.6 <a href="#status.306">306 (Unused)</a></li> |
723 | | <li>7.3.7 <a href="#status.307">307 Temporary Redirect</a></li> |
724 | | </ul> |
725 | | </li> |
726 | | <li>7.4 <a href="#status.4xx">Client Error 4xx</a><ul> |
727 | | <li>7.4.1 <a href="#status.400">400 Bad Request</a></li> |
728 | | <li>7.4.2 <a href="#status.402">402 Payment Required</a></li> |
729 | | <li>7.4.3 <a href="#status.403">403 Forbidden</a></li> |
730 | | <li>7.4.4 <a href="#status.404">404 Not Found</a></li> |
731 | | <li>7.4.5 <a href="#status.405">405 Method Not Allowed</a></li> |
732 | | <li>7.4.6 <a href="#status.406">406 Not Acceptable</a></li> |
733 | | <li>7.4.7 <a href="#status.408">408 Request Timeout</a></li> |
734 | | <li>7.4.8 <a href="#status.409">409 Conflict</a></li> |
735 | | <li>7.4.9 <a href="#status.410">410 Gone</a></li> |
736 | | <li>7.4.10 <a href="#status.411">411 Length Required</a></li> |
737 | | <li>7.4.11 <a href="#status.413">413 Request Representation Too Large</a></li> |
738 | | <li>7.4.12 <a href="#status.414">414 URI Too Long</a></li> |
739 | | <li>7.4.13 <a href="#status.415">415 Unsupported Media Type</a></li> |
740 | | <li>7.4.14 <a href="#status.417">417 Expectation Failed</a></li> |
741 | | <li>7.4.15 <a href="#status.426">426 Upgrade Required</a></li> |
742 | | </ul> |
743 | | </li> |
744 | | <li>7.5 <a href="#status.5xx">Server Error 5xx</a><ul> |
745 | | <li>7.5.1 <a href="#status.500">500 Internal Server Error</a></li> |
746 | | <li>7.5.2 <a href="#status.501">501 Not Implemented</a></li> |
747 | | <li>7.5.3 <a href="#status.502">502 Bad Gateway</a></li> |
748 | | <li>7.5.4 <a href="#status.503">503 Service Unavailable</a></li> |
749 | | <li>7.5.5 <a href="#status.504">504 Gateway Timeout</a></li> |
750 | | <li>7.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li> |
751 | | </ul> |
752 | | </li> |
753 | | </ul> |
754 | | </li> |
755 | | <li>8. <a href="#http.date">Date/Time Formats</a></li> |
756 | | <li>9. <a href="#product.tokens">Product Tokens</a></li> |
757 | | <li>10. <a href="#header.field.definitions">Header Field Definitions</a><ul> |
758 | | <li>10.1 <a href="#header.allow">Allow</a></li> |
759 | | <li>10.2 <a href="#header.date">Date</a></li> |
760 | | <li>10.3 <a href="#header.expect">Expect</a></li> |
761 | | <li>10.4 <a href="#header.from">From</a></li> |
762 | | <li>10.5 <a href="#header.location">Location</a></li> |
763 | | <li>10.6 <a href="#header.max-forwards">Max-Forwards</a></li> |
764 | | <li>10.7 <a href="#header.referer">Referer</a></li> |
765 | | <li>10.8 <a href="#header.retry-after">Retry-After</a></li> |
766 | | <li>10.9 <a href="#header.server">Server</a></li> |
767 | | <li>10.10 <a href="#header.user-agent">User-Agent</a></li> |
768 | | </ul> |
769 | | </li> |
770 | | <li>11. <a href="#IANA.considerations">IANA Considerations</a><ul> |
771 | | <li>11.1 <a href="#method.registration">Method Registry</a></li> |
772 | | <li>11.2 <a href="#status.code.registration">Status Code Registry</a></li> |
773 | | <li>11.3 <a href="#header.field.registration">Header Field Registration</a></li> |
774 | | </ul> |
775 | | </li> |
776 | | <li>12. <a href="#security.considerations">Security Considerations</a><ul> |
777 | | <li>12.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> |
778 | | <li>12.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> |
779 | | <li>12.3 <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> |
780 | | <li>12.4 <a href="#rfc.section.12.4">Security Considerations for CONNECT</a></li> |
781 | | </ul> |
782 | | </li> |
783 | | <li>13. <a href="#acks">Acknowledgments</a></li> |
784 | | <li>14. <a href="#rfc.references">References</a><ul> |
785 | | <li>14.1 <a href="#rfc.references.1">Normative References</a></li> |
786 | | <li>14.2 <a href="#rfc.references.2">Informative References</a></li> |
787 | | </ul> |
788 | | </li> |
789 | | <li><a href="#rfc.authors">Authors' Addresses</a></li> |
790 | | <li>A. <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> |
791 | | <li>B. <a href="#collected.abnf">Collected ABNF</a></li> |
792 | | <li>C. <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> |
793 | | <li>C.1 <a href="#rfc.section.C.1">Since RFC 2616</a></li> |
794 | | <li>C.2 <a href="#rfc.section.C.2">Since draft-ietf-httpbis-p2-semantics-00</a></li> |
795 | | <li>C.3 <a href="#rfc.section.C.3">Since draft-ietf-httpbis-p2-semantics-01</a></li> |
796 | | <li>C.4 <a href="#changes.since.02">Since draft-ietf-httpbis-p2-semantics-02</a></li> |
797 | | <li>C.5 <a href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></li> |
798 | | <li>C.6 <a href="#changes.since.04">Since draft-ietf-httpbis-p2-semantics-04</a></li> |
799 | | <li>C.7 <a href="#changes.since.05">Since draft-ietf-httpbis-p2-semantics-05</a></li> |
800 | | <li>C.8 <a href="#changes.since.06">Since draft-ietf-httpbis-p2-semantics-06</a></li> |
801 | | <li>C.9 <a href="#changes.since.07">Since draft-ietf-httpbis-p2-semantics-07</a></li> |
802 | | <li>C.10 <a href="#changes.since.08">Since draft-ietf-httpbis-p2-semantics-08</a></li> |
803 | | <li>C.11 <a href="#changes.since.09">Since draft-ietf-httpbis-p2-semantics-09</a></li> |
804 | | <li>C.12 <a href="#changes.since.10">Since draft-ietf-httpbis-p2-semantics-10</a></li> |
805 | | <li>C.13 <a href="#changes.since.11">Since draft-ietf-httpbis-p2-semantics-11</a></li> |
806 | | <li>C.14 <a href="#changes.since.12">Since draft-ietf-httpbis-p2-semantics-12</a></li> |
807 | | <li>C.15 <a href="#changes.since.13">Since draft-ietf-httpbis-p2-semantics-13</a></li> |
808 | | <li>C.16 <a href="#changes.since.14">Since draft-ietf-httpbis-p2-semantics-14</a></li> |
809 | | <li>C.17 <a href="#changes.since.15">Since draft-ietf-httpbis-p2-semantics-15</a></li> |
810 | | <li>C.18 <a href="#changes.since.16">Since draft-ietf-httpbis-p2-semantics-16</a></li> |
811 | | <li>C.19 <a href="#changes.since.17">Since draft-ietf-httpbis-p2-semantics-17</a></li> |
812 | | <li>C.20 <a href="#changes.since.18">Since draft-ietf-httpbis-p2-semantics-18</a></li> |
813 | | </ul> |
814 | | </li> |
815 | | <li><a href="#rfc.index">Index</a></li> |
816 | | </ul> |
817 | | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
818 | | <p id="rfc.section.1.p.1">This document defines HTTP/1.1 request and response semantics. Each HTTP message, as defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, is in the form of either a request or a response. An HTTP server listens on a connection for HTTP requests and responds |
819 | | to each request, in the order received on that connection, with one or more HTTP response messages. This document defines |
820 | | the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various |
821 | | response messages that might be expected as a result of applying that method to the target resource. |
822 | | </p> |
823 | | <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller |
824 | | errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will |
825 | | be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods, |
826 | | request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess |
827 | | reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. |
828 | | </p> |
829 | | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> |
830 | | <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" |
831 | | in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. |
832 | | </p> |
833 | | <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, |
834 | | Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. |
835 | | </p> |
836 | | <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that |
837 | | SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. |
838 | | </p> |
839 | | <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. |
840 | | </p> |
841 | | <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling |
842 | | mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require |
843 | | different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the |
844 | | Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of |
845 | | error recovery could lead to dangerous consequences. |
846 | | </p> |
847 | | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> |
848 | | <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. |
849 | | </p> |
850 | | <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG |
851 | | (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR |
852 | | (any visible US-ASCII character). |
853 | | </p> |
854 | | <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> |
855 | | <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: |
856 | | </p> |
857 | | <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> |
858 | | <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> |
859 | | <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> |
860 | | <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> |
861 | | <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> |
862 | | <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> |
863 | | </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> |
864 | | <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> |
865 | | <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> |
866 | | <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> |
867 | | <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> |
868 | | <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> |
869 | | </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> |
870 | | <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. |
871 | | </p> |
872 | | <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">Method</a> = <a href="#core.rules" class="smpl">token</a> |
873 | | </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 10.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the |
874 | | set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the |
875 | | resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET |
876 | | and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 6</a>. |
877 | | </p> |
878 | | <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="overview.of.methods" href="#overview.of.methods">Overview of Methods</a></h2> |
879 | | <p id="rfc.section.2.1.p.1">The methods listed below are defined in <a href="#method.definitions" title="Method Definitions">Section 6</a>. |
880 | | </p> |
881 | | <div id="rfc.table.u.1"> |
882 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
883 | | <thead> |
884 | | <tr> |
885 | | <th>Method Name</th> |
886 | | <th>Defined in...</th> |
887 | | </tr> |
888 | | </thead> |
889 | | <tbody> |
890 | | <tr> |
891 | | <td class="left">OPTIONS</td> |
892 | | <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 6.2</a></td> |
893 | | </tr> |
894 | | <tr> |
895 | | <td class="left">GET</td> |
896 | | <td class="left"><a href="#GET" id="rfc.xref.GET.1" title="GET">Section 6.3</a></td> |
897 | | </tr> |
898 | | <tr> |
899 | | <td class="left">HEAD</td> |
900 | | <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 6.4</a></td> |
901 | | </tr> |
902 | | <tr> |
903 | | <td class="left">POST</td> |
904 | | <td class="left"><a href="#POST" id="rfc.xref.POST.1" title="POST">Section 6.5</a></td> |
905 | | </tr> |
906 | | <tr> |
907 | | <td class="left">PUT</td> |
908 | | <td class="left"><a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 6.6</a></td> |
909 | | </tr> |
910 | | <tr> |
911 | | <td class="left">DELETE</td> |
912 | | <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 6.7</a></td> |
913 | | </tr> |
914 | | <tr> |
915 | | <td class="left">TRACE</td> |
916 | | <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 6.8</a></td> |
917 | | </tr> |
918 | | <tr> |
919 | | <td class="left">CONNECT</td> |
920 | | <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 6.9</a></td> |
921 | | </tr> |
922 | | </tbody> |
923 | | </table> |
924 | | </div> |
925 | | <p id="rfc.section.2.1.p.2">Note that this list is not exhaustive — it does not include request methods defined in other specifications.</p> |
926 | | <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> |
927 | | <p id="rfc.section.2.2.p.1">The HTTP Method Registry defines the name space for the Method token in the Request line of an HTTP request.</p> |
928 | | <p id="rfc.section.2.2.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: |
929 | | </p> |
930 | | <ul> |
931 | | <li>Method Name (see <a href="#method" title="Method">Section 2</a>) |
932 | | </li> |
933 | | <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>) |
934 | | </li> |
935 | | <li>Pointer to specification text</li> |
936 | | </ul> |
937 | | <p id="rfc.section.2.2.p.3">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). |
938 | | </p> |
939 | | <p id="rfc.section.2.2.p.4">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>>. |
940 | | </p> |
941 | | <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3> |
942 | | <p id="rfc.section.2.2.1.p.1">When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, |
943 | | and currently defined methods are inadequate, it may be appropriate to register a new method. |
944 | | </p> |
945 | | <p id="rfc.section.2.2.1.p.2">HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type" |
946 | | of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific |
947 | | to a single application, so that this is clear. |
948 | | </p> |
949 | | <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message |
950 | | (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they |
951 | | can specify that only zero-length bodies (as opposed to absent bodies) are allowed. |
952 | | </p> |
953 | | <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used |
954 | | to satisfy a subsequent request. |
955 | | </p> |
956 | | <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> |
957 | | <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, |
958 | | or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. |
959 | | </p> |
960 | | <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> |
961 | | <p id="rfc.section.3.1.p.1">New header fields are registered using the procedures described in <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. |
962 | | </p> |
963 | | <p id="rfc.section.3.1.p.2">The requirements for header field names are defined in <a href="http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them |
964 | | with "X-" if they are to be registered (either immediately or in the future). |
965 | | </p> |
966 | | <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters |
967 | | can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. |
968 | | </p> |
969 | | <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed |
970 | | in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the |
971 | | quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
972 | | </p> |
973 | | <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like |
974 | | these: |
975 | | </p> |
976 | | <div id="rfc.figure.u.4"></div><pre class="text"> Example-URI-Field: "http://example.com/a.html,foo", |
977 | | "http://without-a-comma.example.com/" |
978 | | Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" |
979 | | </pre><p id="rfc.section.3.1.p.7">Note that double quote delimiters almost always are used with the quoted-string production; using a different syntax inside |
980 | | double quotes will likely cause unnecessary confusion. |
981 | | </p> |
982 | | <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing |
983 | | parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for |
984 | | it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
985 | | </p> |
986 | | <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p> |
987 | | <ul> |
988 | | <li> |
989 | | <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
990 | | </p> |
991 | | <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible |
992 | | default would be to ignore the header field, but this might not always be the right choice). |
993 | | </p> |
994 | | <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the |
995 | | header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type", |
996 | | as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI). |
997 | | </p> |
998 | | </li> |
999 | | <li> |
1000 | | <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses |
1001 | | to a particular request method. |
1002 | | </p> |
1003 | | </li> |
1004 | | <li> |
1005 | | <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
1006 | | </p> |
1007 | | </li> |
1008 | | <li> |
1009 | | <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p> |
1010 | | </li> |
1011 | | <li> |
1012 | | <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
1013 | | </p> |
1014 | | </li> |
1015 | | <li> |
1016 | | <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
1017 | | </p> |
1018 | | </li> |
1019 | | <li> |
1020 | | <p>Whether the header field should be preserved across redirects.</p> |
1021 | | </li> |
1022 | | </ul> |
1023 | | <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2> |
1024 | | <p id="rfc.section.3.2.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself, |
1025 | | to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language |
1026 | | method invocation. |
1027 | | </p> |
1028 | | <div id="rfc.table.u.2"> |
1029 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
1030 | | <thead> |
1031 | | <tr> |
1032 | | <th>Header Field Name</th> |
1033 | | <th>Defined in...</th> |
1034 | | </tr> |
1035 | | </thead> |
1036 | | <tbody> |
1037 | | <tr> |
1038 | | <td class="left">Accept</td> |
1039 | | <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
1040 | | </tr> |
1041 | | <tr> |
1042 | | <td class="left">Accept-Charset</td> |
1043 | | <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
1044 | | </tr> |
1045 | | <tr> |
1046 | | <td class="left">Accept-Encoding</td> |
1047 | | <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
1048 | | </tr> |
1049 | | <tr> |
1050 | | <td class="left">Accept-Language</td> |
1051 | | <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> |
1052 | | </tr> |
1053 | | <tr> |
1054 | | <td class="left">Authorization</td> |
1055 | | <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1056 | | </tr> |
1057 | | <tr> |
1058 | | <td class="left">Expect</td> |
1059 | | <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.3</a></td> |
1060 | | </tr> |
1061 | | <tr> |
1062 | | <td class="left">From</td> |
1063 | | <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.4</a></td> |
1064 | | </tr> |
1065 | | <tr> |
1066 | | <td class="left">Host</td> |
1067 | | <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
1068 | | </tr> |
1069 | | <tr> |
1070 | | <td class="left">If-Match</td> |
1071 | | <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1072 | | </tr> |
1073 | | <tr> |
1074 | | <td class="left">If-Modified-Since</td> |
1075 | | <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1076 | | </tr> |
1077 | | <tr> |
1078 | | <td class="left">If-None-Match</td> |
1079 | | <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1080 | | </tr> |
1081 | | <tr> |
1082 | | <td class="left">If-Range</td> |
1083 | | <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
1084 | | </tr> |
1085 | | <tr> |
1086 | | <td class="left">If-Unmodified-Since</td> |
1087 | | <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1088 | | </tr> |
1089 | | <tr> |
1090 | | <td class="left">Max-Forwards</td> |
1091 | | <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.6</a></td> |
1092 | | </tr> |
1093 | | <tr> |
1094 | | <td class="left">Proxy-Authorization</td> |
1095 | | <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1096 | | </tr> |
1097 | | <tr> |
1098 | | <td class="left">Range</td> |
1099 | | <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
1100 | | </tr> |
1101 | | <tr> |
1102 | | <td class="left">Referer</td> |
1103 | | <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.7</a></td> |
1104 | | </tr> |
1105 | | <tr> |
1106 | | <td class="left">TE</td> |
1107 | | <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> |
1108 | | </tr> |
1109 | | <tr> |
1110 | | <td class="left">User-Agent</td> |
1111 | | <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.10</a></td> |
1112 | | </tr> |
1113 | | </tbody> |
1114 | | </table> |
1115 | | </div> |
1116 | | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> |
1117 | | <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the |
1118 | | Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
1119 | | </p> |
1120 | | <div id="rfc.table.u.3"> |
1121 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
1122 | | <thead> |
1123 | | <tr> |
1124 | | <th>Header Field Name</th> |
1125 | | <th>Defined in...</th> |
1126 | | </tr> |
1127 | | </thead> |
1128 | | <tbody> |
1129 | | <tr> |
1130 | | <td class="left">Accept-Ranges</td> |
1131 | | <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
1132 | | </tr> |
1133 | | <tr> |
1134 | | <td class="left">Age</td> |
1135 | | <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 3.1</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> |
1136 | | </tr> |
1137 | | <tr> |
1138 | | <td class="left">Allow</td> |
1139 | | <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 10.1</a></td> |
1140 | | </tr> |
1141 | | <tr> |
1142 | | <td class="left">Date</td> |
1143 | | <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 10.2</a></td> |
1144 | | </tr> |
1145 | | <tr> |
1146 | | <td class="left">ETag</td> |
1147 | | <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1148 | | </tr> |
1149 | | <tr> |
1150 | | <td class="left">Location</td> |
1151 | | <td class="left"><a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.5</a></td> |
1152 | | </tr> |
1153 | | <tr> |
1154 | | <td class="left">Proxy-Authenticate</td> |
1155 | | <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1156 | | </tr> |
1157 | | <tr> |
1158 | | <td class="left">Retry-After</td> |
1159 | | <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.8</a></td> |
1160 | | </tr> |
1161 | | <tr> |
1162 | | <td class="left">Server</td> |
1163 | | <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.9</a></td> |
1164 | | </tr> |
1165 | | <tr> |
1166 | | <td class="left">Vary</td> |
1167 | | <td class="left"><a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td> |
1168 | | </tr> |
1169 | | <tr> |
1170 | | <td class="left">WWW-Authenticate</td> |
1171 | | <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1172 | | </tr> |
1173 | | </tbody> |
1174 | | </table> |
1175 | | </div> |
1176 | | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> |
1177 | | <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p> |
1178 | | <p id="rfc.section.4.p.2">The Reason-Phrase is intended to give a short textual description of the Status-Code and is intended for a human user. The |
1179 | | client does not need to examine or display the Reason-Phrase. |
1180 | | </p> |
1181 | | <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#notation" class="smpl">DIGIT</a> |
1182 | | <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#notation" class="smpl">HTAB</a> / <a href="#notation" class="smpl">SP</a> / <a href="#notation" class="smpl">VCHAR</a> / <a href="#core.rules" class="smpl">obs-text</a> ) |
1183 | | </pre><p id="rfc.section.4.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, |
1184 | | though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent |
1185 | | to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was |
1186 | | something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the representation enclosed with the response, since that representation is likely to include human-readable |
1187 | | information which will explain the unusual status. |
1188 | | </p> |
1189 | | <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> |
1190 | | <p id="rfc.section.4.1.p.1">The status codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a> of this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the |
1191 | | protocol. |
1192 | | </p> |
1193 | | <div id="rfc.table.u.4"> |
1194 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
1195 | | <thead> |
1196 | | <tr> |
1197 | | <th>Status-Code</th> |
1198 | | <th>Reason-Phrase</th> |
1199 | | <th>Defined in...</th> |
1200 | | </tr> |
1201 | | </thead> |
1202 | | <tbody> |
1203 | | <tr> |
1204 | | <td class="left">100</td> |
1205 | | <td class="left">Continue</td> |
1206 | | <td class="left"><a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a></td> |
1207 | | </tr> |
1208 | | <tr> |
1209 | | <td class="left">101</td> |
1210 | | <td class="left">Switching Protocols</td> |
1211 | | <td class="left"><a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a></td> |
1212 | | </tr> |
1213 | | <tr> |
1214 | | <td class="left">200</td> |
1215 | | <td class="left">OK</td> |
1216 | | <td class="left"><a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a></td> |
1217 | | </tr> |
1218 | | <tr> |
1219 | | <td class="left">201</td> |
1220 | | <td class="left">Created</td> |
1221 | | <td class="left"><a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 7.2.2</a></td> |
1222 | | </tr> |
1223 | | <tr> |
1224 | | <td class="left">202</td> |
1225 | | <td class="left">Accepted</td> |
1226 | | <td class="left"><a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 7.2.3</a></td> |
1227 | | </tr> |
1228 | | <tr> |
1229 | | <td class="left">203</td> |
1230 | | <td class="left">Non-Authoritative Information</td> |
1231 | | <td class="left"><a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 7.2.4</a></td> |
1232 | | </tr> |
1233 | | <tr> |
1234 | | <td class="left">204</td> |
1235 | | <td class="left">No Content</td> |
1236 | | <td class="left"><a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 7.2.5</a></td> |
1237 | | </tr> |
1238 | | <tr> |
1239 | | <td class="left">205</td> |
1240 | | <td class="left">Reset Content</td> |
1241 | | <td class="left"><a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 7.2.6</a></td> |
1242 | | </tr> |
1243 | | <tr> |
1244 | | <td class="left">206</td> |
1245 | | <td class="left">Partial Content</td> |
1246 | | <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
1247 | | </tr> |
1248 | | <tr> |
1249 | | <td class="left">300</td> |
1250 | | <td class="left">Multiple Choices</td> |
1251 | | <td class="left"><a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 7.3.1</a></td> |
1252 | | </tr> |
1253 | | <tr> |
1254 | | <td class="left">301</td> |
1255 | | <td class="left">Moved Permanently</td> |
1256 | | <td class="left"><a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 7.3.2</a></td> |
1257 | | </tr> |
1258 | | <tr> |
1259 | | <td class="left">302</td> |
1260 | | <td class="left">Found</td> |
1261 | | <td class="left"><a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 7.3.3</a></td> |
1262 | | </tr> |
1263 | | <tr> |
1264 | | <td class="left">303</td> |
1265 | | <td class="left">See Other</td> |
1266 | | <td class="left"><a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 7.3.4</a></td> |
1267 | | </tr> |
1268 | | <tr> |
1269 | | <td class="left">304</td> |
1270 | | <td class="left">Not Modified</td> |
1271 | | <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1272 | | </tr> |
1273 | | <tr> |
1274 | | <td class="left">305</td> |
1275 | | <td class="left">Use Proxy</td> |
1276 | | <td class="left"><a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 7.3.5</a></td> |
1277 | | </tr> |
1278 | | <tr> |
1279 | | <td class="left">307</td> |
1280 | | <td class="left">Temporary Redirect</td> |
1281 | | <td class="left"><a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 7.3.7</a></td> |
1282 | | </tr> |
1283 | | <tr> |
1284 | | <td class="left">400</td> |
1285 | | <td class="left">Bad Request</td> |
1286 | | <td class="left"><a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 7.4.1</a></td> |
1287 | | </tr> |
1288 | | <tr> |
1289 | | <td class="left">401</td> |
1290 | | <td class="left">Unauthorized</td> |
1291 | | <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1292 | | </tr> |
1293 | | <tr> |
1294 | | <td class="left">402</td> |
1295 | | <td class="left">Payment Required</td> |
1296 | | <td class="left"><a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 7.4.2</a></td> |
1297 | | </tr> |
1298 | | <tr> |
1299 | | <td class="left">403</td> |
1300 | | <td class="left">Forbidden</td> |
1301 | | <td class="left"><a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 7.4.3</a></td> |
1302 | | </tr> |
1303 | | <tr> |
1304 | | <td class="left">404</td> |
1305 | | <td class="left">Not Found</td> |
1306 | | <td class="left"><a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 7.4.4</a></td> |
1307 | | </tr> |
1308 | | <tr> |
1309 | | <td class="left">405</td> |
1310 | | <td class="left">Method Not Allowed</td> |
1311 | | <td class="left"><a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 7.4.5</a></td> |
1312 | | </tr> |
1313 | | <tr> |
1314 | | <td class="left">406</td> |
1315 | | <td class="left">Not Acceptable</td> |
1316 | | <td class="left"><a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 7.4.6</a></td> |
1317 | | </tr> |
1318 | | <tr> |
1319 | | <td class="left">407</td> |
1320 | | <td class="left">Proxy Authentication Required</td> |
1321 | | <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a></td> |
1322 | | </tr> |
1323 | | <tr> |
1324 | | <td class="left">408</td> |
1325 | | <td class="left">Request Time-out</td> |
1326 | | <td class="left"><a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 7.4.7</a></td> |
1327 | | </tr> |
1328 | | <tr> |
1329 | | <td class="left">409</td> |
1330 | | <td class="left">Conflict</td> |
1331 | | <td class="left"><a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 7.4.8</a></td> |
1332 | | </tr> |
1333 | | <tr> |
1334 | | <td class="left">410</td> |
1335 | | <td class="left">Gone</td> |
1336 | | <td class="left"><a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 7.4.9</a></td> |
1337 | | </tr> |
1338 | | <tr> |
1339 | | <td class="left">411</td> |
1340 | | <td class="left">Length Required</td> |
1341 | | <td class="left"><a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 7.4.10</a></td> |
1342 | | </tr> |
1343 | | <tr> |
1344 | | <td class="left">412</td> |
1345 | | <td class="left">Precondition Failed</td> |
1346 | | <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td> |
1347 | | </tr> |
1348 | | <tr> |
1349 | | <td class="left">413</td> |
1350 | | <td class="left">Request Representation Too Large</td> |
1351 | | <td class="left"><a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Representation Too Large">Section 7.4.11</a></td> |
1352 | | </tr> |
1353 | | <tr> |
1354 | | <td class="left">414</td> |
1355 | | <td class="left">URI Too Long</td> |
1356 | | <td class="left"><a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 7.4.12</a></td> |
1357 | | </tr> |
1358 | | <tr> |
1359 | | <td class="left">415</td> |
1360 | | <td class="left">Unsupported Media Type</td> |
1361 | | <td class="left"><a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 7.4.13</a></td> |
1362 | | </tr> |
1363 | | <tr> |
1364 | | <td class="left">416</td> |
1365 | | <td class="left">Requested range not satisfiable</td> |
1366 | | <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a></td> |
1367 | | </tr> |
1368 | | <tr> |
1369 | | <td class="left">417</td> |
1370 | | <td class="left">Expectation Failed</td> |
1371 | | <td class="left"><a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 7.4.14</a></td> |
1372 | | </tr> |
1373 | | <tr> |
1374 | | <td class="left">426</td> |
1375 | | <td class="left">Upgrade Required</td> |
1376 | | <td class="left"><a href="#status.426" id="rfc.xref.status.426.1" title="426 Upgrade Required">Section 7.4.15</a></td> |
1377 | | </tr> |
1378 | | <tr> |
1379 | | <td class="left">500</td> |
1380 | | <td class="left">Internal Server Error</td> |
1381 | | <td class="left"><a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 7.5.1</a></td> |
1382 | | </tr> |
1383 | | <tr> |
1384 | | <td class="left">501</td> |
1385 | | <td class="left">Not Implemented</td> |
1386 | | <td class="left"><a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 7.5.2</a></td> |
1387 | | </tr> |
1388 | | <tr> |
1389 | | <td class="left">502</td> |
1390 | | <td class="left">Bad Gateway</td> |
1391 | | <td class="left"><a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 7.5.3</a></td> |
1392 | | </tr> |
1393 | | <tr> |
1394 | | <td class="left">503</td> |
1395 | | <td class="left">Service Unavailable</td> |
1396 | | <td class="left"><a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 7.5.4</a></td> |
1397 | | </tr> |
1398 | | <tr> |
1399 | | <td class="left">504</td> |
1400 | | <td class="left">Gateway Time-out</td> |
1401 | | <td class="left"><a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 7.5.5</a></td> |
1402 | | </tr> |
1403 | | <tr> |
1404 | | <td class="left">505</td> |
1405 | | <td class="left">HTTP Version not supported</td> |
1406 | | <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 7.5.6</a></td> |
1407 | | </tr> |
1408 | | </tbody> |
1409 | | </table> |
1410 | | </div> |
1411 | | <p id="rfc.section.4.1.p.2">Note that this list is not exhaustive — it does not include extension status codes defined in other specifications.</p> |
1412 | | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> |
1413 | | <p id="rfc.section.4.2.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status-Line of an HTTP response.</p> |
1414 | | <p id="rfc.section.4.2.p.2">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). |
1415 | | </p> |
1416 | | <p id="rfc.section.4.2.p.3">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. |
1417 | | </p> |
1418 | | <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> |
1419 | | <p id="rfc.section.4.2.1.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type, |
1420 | | and currently defined status codes are inadequate, a new status code can be registered. |
1421 | | </p> |
1422 | | <p id="rfc.section.4.2.1.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type, |
1423 | | "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't |
1424 | | specific to a single application, so that this is clear. |
1425 | | </p> |
1426 | | <p id="rfc.section.4.2.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status |
1427 | | code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those |
1428 | | that are required, those that modify the semantics of the response). |
1429 | | </p> |
1430 | | <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate |
1431 | | a zero-length response body. They can require the presence of one or more particular HTTP response header(s). |
1432 | | </p> |
1433 | | <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 5.1</a>; by default, it is anonymous). |
1434 | | </p> |
1435 | | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> |
1436 | | <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists |
1437 | | of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed |
1438 | | in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. |
1439 | | </p> |
1440 | | <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied |
1441 | | to ensure safe and proper transfer of the message. |
1442 | | </p> |
1443 | | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> |
1444 | | <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> |
1445 | | <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> |
1446 | | <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following |
1447 | | rules are used (with the first applicable one being selected): |
1448 | | </p> |
1449 | | <ol> |
1450 | | <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the |
1451 | | target resource. |
1452 | | </li> |
1453 | | <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial |
1454 | | representation of the target resource. |
1455 | | </li> |
1456 | | <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload |
1457 | | is a representation of the target resource. |
1458 | | </li> |
1459 | | <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response |
1460 | | asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion |
1461 | | cannot be trusted unless it can be verified by other means (not defined by HTTP). |
1462 | | </li> |
1463 | | <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> |
1464 | | </ol> |
1465 | | <p id="rfc.section.5.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like |
1466 | | cache invalidation.]</span> |
1467 | | </p> |
1468 | | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> |
1469 | | <p id="rfc.section.6.p.1">The set of common request methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot |
1470 | | be assumed to share the same semantics for separately extended clients and servers. |
1471 | | </p> |
1472 | | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> |
1473 | | <div id="rfc.iref.s.1"></div> |
1474 | | <h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> |
1475 | | <p id="rfc.section.6.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow |
1476 | | the user to be aware of any actions they take which might have an unexpected significance to themselves or others. |
1477 | | </p> |
1478 | | <p id="rfc.section.6.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE request methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These request methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is |
1479 | | made aware of the fact that a possibly unsafe action is being requested. |
1480 | | </p> |
1481 | | <p id="rfc.section.6.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; |
1482 | | in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the |
1483 | | side-effects, so therefore cannot be held accountable for them. |
1484 | | </p> |
1485 | | <div id="rfc.iref.i.1"></div> |
1486 | | <h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> |
1487 | | <p id="rfc.section.6.1.2.p.1">Request methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect |
1488 | | of multiple identical requests is the same as for a single request. PUT, DELETE, and all safe request methods are idempotent. |
1489 | | It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state |
1490 | | due to multiple requests for the purpose of tracking those requests, versioning of results, etc. |
1491 | | </p> |
1492 | | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> |
1493 | | <div id="rfc.iref.o.1"></div> |
1494 | | <div id="rfc.iref.m.1"></div> |
1495 | | <p id="rfc.section.6.2.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified |
1496 | | by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, |
1497 | | or the capabilities of a server, without implying a resource action or initiating a resource retrieval. |
1498 | | </p> |
1499 | | <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p> |
1500 | | <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then |
1501 | | the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions |
1502 | | to HTTP might use the OPTIONS body to make more detailed queries on the server. |
1503 | | </p> |
1504 | | <p id="rfc.section.6.2.p.4">If the request-target is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than |
1505 | | to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful |
1506 | | as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. |
1507 | | For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof). |
1508 | | </p> |
1509 | | <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating |
1510 | | with that resource. |
1511 | | </p> |
1512 | | <p id="rfc.section.6.2.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., |
1513 | | Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, |
1514 | | but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". |
1515 | | </p> |
1516 | | <p id="rfc.section.6.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. |
1517 | | </p> |
1518 | | <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="GET" href="#GET">GET</a></h2> |
1519 | | <div id="rfc.iref.g.5"></div> |
1520 | | <div id="rfc.iref.m.2"></div> |
1521 | | <p id="rfc.section.6.3.p.1">The GET method requests transfer of a current representation of the target resource.</p> |
1522 | | <p id="rfc.section.6.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation |
1523 | | in the response and not the source text of the process, unless that text happens to be the output of the process. |
1524 | | </p> |
1525 | | <p id="rfc.section.6.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, |
1526 | | If-Match, If-None-Match, or If-Range header field. A conditional GET requests that the representation be transferred only |
1527 | | under the circumstances described by the conditional header field(s). The conditional GET request is intended to reduce unnecessary |
1528 | | network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring data |
1529 | | already held by the client. |
1530 | | </p> |
1531 | | <p id="rfc.section.6.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial |
1532 | | GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations |
1533 | | to be completed without transferring data already held by the client. |
1534 | | </p> |
1535 | | <p id="rfc.section.6.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations |
1536 | | to reject the request. |
1537 | | </p> |
1538 | | <p id="rfc.section.6.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
1539 | | </p> |
1540 | | <p id="rfc.section.6.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms. |
1541 | | </p> |
1542 | | <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> |
1543 | | <div id="rfc.iref.h.1"></div> |
1544 | | <div id="rfc.iref.m.3"></div> |
1545 | | <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the |
1546 | | representation implied by the request without transferring the representation body. This method is often used for testing |
1547 | | hypertext links for validity, accessibility, and recent modification. |
1548 | | </p> |
1549 | | <p id="rfc.section.6.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached |
1550 | | representation differs from the current representation (as would be indicated by a change in Content-Length, ETag or Last-Modified), |
1551 | | then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. |
1552 | | </p> |
1553 | | <p id="rfc.section.6.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations |
1554 | | to reject the request. |
1555 | | </p> |
1556 | | <div id="rfc.iref.p.1"></div> |
1557 | | <div id="rfc.iref.m.4"></div> |
1558 | | <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="POST" href="#POST">POST</a></h2> |
1559 | | <p id="rfc.section.6.5.p.1">The POST method requests that the origin server accept the representation enclosed in the request as data to be processed |
1560 | | by the target resource. POST is designed to allow a uniform method to cover the following functions: |
1561 | | </p> |
1562 | | <ul> |
1563 | | <li>Annotation of existing resources;</li> |
1564 | | <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> |
1565 | | <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> |
1566 | | <li>Extending a database through an append operation.</li> |
1567 | | </ul> |
1568 | | <p id="rfc.section.6.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request |
1569 | | URI. |
1570 | | </p> |
1571 | | <p id="rfc.section.6.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either |
1572 | | 200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a |
1573 | | representation that describes the result. |
1574 | | </p> |
1575 | | <p id="rfc.section.6.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and |
1576 | | a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.5</a>). |
1577 | | </p> |
1578 | | <p id="rfc.section.6.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. |
1579 | | </p> |
1580 | | <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent |
1581 | | to retrieve a cacheable resource. |
1582 | | </p> |
1583 | | <div id="rfc.iref.p.2"></div> |
1584 | | <div id="rfc.iref.m.5"></div> |
1585 | | <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="PUT" href="#PUT">PUT</a></h2> |
1586 | | <p id="rfc.section.6.6.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation |
1587 | | enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on |
1588 | | that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there |
1589 | | is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents |
1590 | | in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful |
1591 | | response only implies that the user agent's intent was achieved at the time of its processing by the origin server. |
1592 | | </p> |
1593 | | <p id="rfc.section.6.6.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that |
1594 | | representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) |
1595 | | or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. |
1596 | | </p> |
1597 | | <p id="rfc.section.6.6.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state). |
1598 | | </p> |
1599 | | <p id="rfc.section.6.6.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot |
1600 | | or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information |
1601 | | related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent |
1602 | | with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an |
1603 | | appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) |
1604 | | or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type |
1605 | | values. |
1606 | | </p> |
1607 | | <p id="rfc.section.6.6.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being |
1608 | | PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of: (a) reconfigure the target resource to reflect the new media type; (b) transform the PUT representation to a format |
1609 | | consistent with that of the resource before saving it as the new resource state; or, (c) reject the request with a 415 response |
1610 | | indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would |
1611 | | be a suitable target for the new representation. |
1612 | | </p> |
1613 | | <p id="rfc.section.6.6.p.6">HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent |
1614 | | of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in |
1615 | | any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how |
1616 | | such storage might change as a result of a change in resource state, nor how the origin server translates resource state into |
1617 | | representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by |
1618 | | the server. |
1619 | | </p> |
1620 | | <p id="rfc.section.6.6.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource. |
1621 | | The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such |
1622 | | as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT |
1623 | | request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent |
1624 | | and visible to intermediaries, even though the exact effect is only known by the origin server. |
1625 | | </p> |
1626 | | <p id="rfc.section.6.6.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that |
1627 | | is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to |
1628 | | the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved |
1629 | | to a different URI, then the origin server <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. |
1630 | | </p> |
1631 | | <p id="rfc.section.6.6.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) |
1632 | | which is separate from the URIs identifying each particular version (different resources that at one point shared the same |
1633 | | state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new |
1634 | | version resource in addition to changing the state of the target resource, and might also cause links to be added between |
1635 | | the related resources. |
1636 | | </p> |
1637 | | <p id="rfc.section.6.6.p.10">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or |
1638 | | might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting |
1639 | | a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method |
1640 | | that has been specifically defined for partial updates (for example, the PATCH method defined in <a href="#RFC5789" id="rfc.xref.RFC5789.1"><cite title="PATCH Method for HTTP">[RFC5789]</cite></a>). |
1641 | | </p> |
1642 | | <p id="rfc.section.6.6.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses |
1643 | | for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
1644 | | </p> |
1645 | | <div id="rfc.iref.d.1"></div> |
1646 | | <div id="rfc.iref.m.6"></div> |
1647 | | <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> |
1648 | | <p id="rfc.section.6.7.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation |
1649 | | has been carried out, even if the status code returned from the origin server indicates that the action has been completed |
1650 | | successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible |
1651 | | location. |
1652 | | </p> |
1653 | | <p id="rfc.section.6.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been |
1654 | | enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. |
1655 | | </p> |
1656 | | <p id="rfc.section.6.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing |
1657 | | implementations to reject the request. |
1658 | | </p> |
1659 | | <p id="rfc.section.6.7.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses |
1660 | | for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
1661 | | </p> |
1662 | | <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> |
1663 | | <div id="rfc.iref.t.1"></div> |
1664 | | <div id="rfc.iref.m.7"></div> |
1665 | | <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either |
1666 | | the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. |
1667 | | </p> |
1668 | | <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing |
1669 | | or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the |
1670 | | client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an |
1671 | | infinite loop. |
1672 | | </p> |
1673 | | <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. |
1674 | | </p> |
1675 | | <div id="rfc.iref.c.1"></div> |
1676 | | <div id="rfc.iref.m.8"></div> |
1677 | | <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> |
1678 | | <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind |
1679 | | forwarding of packets until the connection is closed. |
1680 | | </p> |
1681 | | <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. |
1682 | | For example, |
1683 | | </p> |
1684 | | <div id="rfc.figure.u.6"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 |
1685 | | Host: server.example.com:80 |
1686 | | |
1687 | | </pre><p id="rfc.section.6.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method — except end-to-end protocol Upgrade requests, since the |
1688 | | tunnel must be established first. |
1689 | | </p> |
1690 | | <p id="rfc.section.6.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p> |
1691 | | <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 |
1692 | | Host: server.example.com:80 |
1693 | | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
1694 | | |
1695 | | </pre><p id="rfc.section.6.9.p.7">Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing |
1696 | | implementations to reject the request. |
1697 | | </p> |
1698 | | <p id="rfc.section.6.9.p.8">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats |
1699 | | also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if |
1700 | | more than one TCP segment is outstanding. |
1701 | | </p> |
1702 | | <h3 id="rfc.section.6.9.1"><a href="#rfc.section.6.9.1">6.9.1</a> Establishing a Tunnel with CONNECT |
1703 | | </h3> |
1704 | | <p id="rfc.section.6.9.1.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested |
1705 | | host and port, and has switched to tunneling the current connection to that server connection. |
1706 | | </p> |
1707 | | <p id="rfc.section.6.9.1.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the |
1708 | | first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority. |
1709 | | </p> |
1710 | | <p id="rfc.section.6.9.1.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. |
1711 | | </p> |
1712 | | <p id="rfc.section.6.9.1.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to |
1713 | | the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that |
1714 | | peer undelivered, that data will be discarded. |
1715 | | </p> |
1716 | | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> |
1717 | | <p id="rfc.section.7.p.1">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. |
1718 | | There are 5 values for the first digit: |
1719 | | </p> |
1720 | | <ul> |
1721 | | <li>1xx: Informational - Request received, continuing process</li> |
1722 | | <li>2xx: Success - The action was successfully received, understood, and accepted</li> |
1723 | | <li>3xx: Redirection - Further action must be taken in order to complete the request</li> |
1724 | | <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li> |
1725 | | <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> |
1726 | | </ul> |
1727 | | <p id="rfc.section.7.p.2">Each Status-Code is described below, including any metadata required in the response.</p> |
1728 | | <p id="rfc.section.7.p.3">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's |
1729 | | media type (<a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
1730 | | </p> |
1731 | | <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> |
1732 | | <p id="rfc.section.7.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header fields, |
1733 | | and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did |
1734 | | not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. |
1735 | | </p> |
1736 | | <p id="rfc.section.7.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 |
1737 | | (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. |
1738 | | </p> |
1739 | | <p id="rfc.section.7.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself |
1740 | | requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards |
1741 | | a request, then it need not forward the corresponding 100 (Continue) response(s).) |
1742 | | </p> |
1743 | | <div id="rfc.iref.22"></div> |
1744 | | <div id="rfc.iref.s.2"></div> |
1745 | | <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> |
1746 | | <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been |
1747 | | received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The |
1748 | | server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. |
1749 | | </p> |
1750 | | <div id="rfc.iref.23"></div> |
1751 | | <div id="rfc.iref.s.3"></div> |
1752 | | <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> |
1753 | | <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined |
1754 | | by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
1755 | | </p> |
1756 | | <p id="rfc.section.7.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over |
1757 | | older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use |
1758 | | such features. |
1759 | | </p> |
1760 | | <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> |
1761 | | <p id="rfc.section.7.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> |
1762 | | <div id="rfc.iref.24"></div> |
1763 | | <div id="rfc.iref.s.4"></div> |
1764 | | <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> |
1765 | | <p id="rfc.section.7.2.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p> |
1766 | | <dl> |
1767 | | <dt>GET</dt> |
1768 | | <dd>a representation of the target resource is sent in the response;</dd> |
1769 | | <dt>HEAD</dt> |
1770 | | <dd>the same representation as GET, except without the message body;</dd> |
1771 | | <dt>POST</dt> |
1772 | | <dd>a representation describing or containing the result of the action;</dd> |
1773 | | <dt>TRACE</dt> |
1774 | | <dd>a representation containing the request message as received by the end server.</dd> |
1775 | | </dl> |
1776 | | <p id="rfc.section.7.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. |
1777 | | </p> |
1778 | | <div id="rfc.iref.25"></div> |
1779 | | <div id="rfc.iref.s.5"></div> |
1780 | | <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> |
1781 | | <p id="rfc.section.7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created. The newly created resource can be referenced |
1782 | | by the URI(s) returned in the payload of the response, with the most specific URI for the resource given by a Location header |
1783 | | field. The response can include a payload containing a list of resource characteristics and location(s) from which the user |
1784 | | or user agent can choose the one most appropriate. |
1785 | | </p> |
1786 | | <p id="rfc.section.7.2.2.p.2">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. |
1787 | | </p> |
1788 | | <p id="rfc.section.7.2.2.p.3">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource |
1789 | | just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
1790 | | </p> |
1791 | | <div id="rfc.iref.26"></div> |
1792 | | <div id="rfc.iref.s.6"></div> |
1793 | | <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> |
1794 | | <p id="rfc.section.7.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually |
1795 | | be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status |
1796 | | code from an asynchronous operation such as this. |
1797 | | </p> |
1798 | | <p id="rfc.section.7.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process |
1799 | | (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the |
1800 | | server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the |
1801 | | user can expect the request to be fulfilled. |
1802 | | </p> |
1803 | | <div id="rfc.iref.27"></div> |
1804 | | <div id="rfc.iref.s.7"></div> |
1805 | | <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> |
1806 | | <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). |
1807 | | </p> |
1808 | | <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code |
1809 | | before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. |
1810 | | </p> |
1811 | | <p id="rfc.section.7.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. |
1812 | | </p> |
1813 | | <div id="rfc.iref.28"></div> |
1814 | | <div id="rfc.iref.s.8"></div> |
1815 | | <h3 id="rfc.section.7.2.5"><a href="#rfc.section.7.2.5">7.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> |
1816 | | <p id="rfc.section.7.2.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional |
1817 | | content to return in the response payload body. Metadata in the response header fields refer to the target resource and its |
1818 | | current representation after the requested action. |
1819 | | </p> |
1820 | | <p id="rfc.section.7.2.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, |
1821 | | then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource. |
1822 | | </p> |
1823 | | <p id="rfc.section.7.2.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying |
1824 | | that the user agent <em class="bcp14">SHOULD NOT</em> traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication |
1825 | | of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the |
1826 | | active representation. |
1827 | | </p> |
1828 | | <p id="rfc.section.7.2.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that |
1829 | | the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect |
1830 | | automated data transfers to be prevalent, such as within distributed version control systems. |
1831 | | </p> |
1832 | | <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields. |
1833 | | </p> |
1834 | | <div id="rfc.iref.29"></div> |
1835 | | <div id="rfc.iref.s.9"></div> |
1836 | | <h3 id="rfc.section.7.2.6"><a href="#rfc.section.7.2.6">7.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> |
1837 | | <p id="rfc.section.7.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions |
1838 | | to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate |
1839 | | another input action. |
1840 | | </p> |
1841 | | <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. |
1842 | | </p> |
1843 | | <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> |
1844 | | <p id="rfc.section.7.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. |
1845 | | If the required action involves a subsequent HTTP request, it <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is |
1846 | | known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>. |
1847 | | </p> |
1848 | | <p id="rfc.section.7.3.p.2">There are several types of redirects: </p> |
1849 | | <ol> |
1850 | | <li> |
1851 | | <p>Redirects of the request to another URI, either temporarily or permanently. The new URI is specified in the Location header |
1852 | | field. In this specification, the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect) fall under |
1853 | | this category. |
1854 | | </p> |
1855 | | </li> |
1856 | | <li> |
1857 | | <p>Redirection to a new location that represents an indirect response to the request, such as the result of a POST operation |
1858 | | to be retrieved with a subsequent GET request. This is status code 303 (See Other). |
1859 | | </p> |
1860 | | </li> |
1861 | | <li> |
1862 | | <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices). |
1863 | | </p> |
1864 | | </li> |
1865 | | <li> |
1866 | | <p>Other kinds of redirection, such as to a cached result (status code 304 (Not Modified), see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). |
1867 | | </p> |
1868 | | </li> |
1869 | | </ol> |
1870 | | <div class="note" id="rfc.section.7.3.p.3"> |
1871 | | <p> <b>Note:</b> In HTTP/1.0, only the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect, and |
1872 | | the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to |
1873 | | retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code 303 (See Other) |
1874 | | (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added |
1875 | | yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification |
1876 | | makes that behavior conformant in case the original request was POST. |
1877 | | </p> |
1878 | | </div> |
1879 | | <p id="rfc.section.7.3.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.5</a>. |
1880 | | </p> |
1881 | | <p id="rfc.section.7.3.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was |
1882 | | issued. |
1883 | | </p> |
1884 | | <p id="rfc.section.7.3.p.6">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops). |
1885 | | </p> |
1886 | | <div class="note" id="rfc.section.7.3.p.7"> |
1887 | | <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. |
1888 | | </p> |
1889 | | </div> |
1890 | | <div id="rfc.iref.30"></div> |
1891 | | <div id="rfc.iref.s.10"></div> |
1892 | | <h3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> |
1893 | | <p id="rfc.section.7.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information |
1894 | | (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that |
1895 | | location. |
1896 | | </p> |
1897 | | <p id="rfc.section.7.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can |
1898 | | choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection of the most appropriate |
1899 | | choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
1900 | | </p> |
1901 | | <p id="rfc.section.7.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. |
1902 | | </p> |
1903 | | <p id="rfc.section.7.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. |
1904 | | </p> |
1905 | | <div id="rfc.iref.31"></div> |
1906 | | <div id="rfc.iref.s.11"></div> |
1907 | | <h3 id="rfc.section.7.3.2"><a href="#rfc.section.7.3.2">7.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> |
1908 | | <p id="rfc.section.7.3.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective |
1909 | | request URI to one or more of the new references returned by the server, where possible. |
1910 | | </p> |
1911 | | <p id="rfc.section.7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. |
1912 | | </p> |
1913 | | <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
1914 | | the new URI(s). |
1915 | | </p> |
1916 | | <div class="note" id="rfc.section.7.3.2.p.4"> |
1917 | | <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
1918 | | Redirect) can be used instead. |
1919 | | </p> |
1920 | | </div> |
1921 | | <div id="rfc.iref.32"></div> |
1922 | | <div id="rfc.iref.s.12"></div> |
1923 | | <h3 id="rfc.section.7.3.3"><a href="#rfc.section.7.3.3">7.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> |
1924 | | <p id="rfc.section.7.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
1925 | | </p> |
1926 | | <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
1927 | | the new URI(s). |
1928 | | </p> |
1929 | | <div class="note" id="rfc.section.7.3.3.p.3"> |
1930 | | <p> <b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code 307 (Temporary |
1931 | | Redirect) can be used instead. |
1932 | | </p> |
1933 | | </div> |
1934 | | <div id="rfc.iref.33"></div> |
1935 | | <div id="rfc.iref.s.13"></div> |
1936 | | <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> |
1937 | | <p id="rfc.section.7.3.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI |
1938 | | in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy |
1939 | | the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further, |
1940 | | and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is |
1941 | | not considered equivalent to the effective request URI. |
1942 | | </p> |
1943 | | <p id="rfc.section.7.3.4.p.2">This status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to |
1944 | | redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response |
1945 | | in a form that can be separately identified, bookmarked, and cached independent of the original request. |
1946 | | </p> |
1947 | | <p id="rfc.section.7.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be |
1948 | | transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such |
1949 | | that the follow-on representation might be useful to recipients without implying that it adequately represents the target |
1950 | | resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might |
1951 | | be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s). |
1952 | | </p> |
1953 | | <p id="rfc.section.7.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI. |
1954 | | </p> |
1955 | | <div id="rfc.iref.34"></div> |
1956 | | <div id="rfc.iref.s.14"></div> |
1957 | | <h3 id="rfc.section.7.3.5"><a href="#rfc.section.7.3.5">7.3.5</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> |
1958 | | <p id="rfc.section.7.3.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A</a>), and is now deprecated. |
1959 | | </p> |
1960 | | <div id="rfc.iref.35"></div> |
1961 | | <div id="rfc.iref.s.15"></div> |
1962 | | <h3 id="rfc.section.7.3.6"><a href="#rfc.section.7.3.6">7.3.6</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> |
1963 | | <p id="rfc.section.7.3.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> |
1964 | | <div id="rfc.iref.36"></div> |
1965 | | <div id="rfc.iref.s.16"></div> |
1966 | | <h3 id="rfc.section.7.3.7"><a href="#rfc.section.7.3.7">7.3.7</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> |
1967 | | <p id="rfc.section.7.3.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. |
1968 | | </p> |
1969 | | <p id="rfc.section.7.3.7.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to |
1970 | | the new URI(s). |
1971 | | </p> |
1972 | | <div class="note" id="rfc.section.7.3.7.p.3"> |
1973 | | <p> <b>Note:</b> This status code is similar to 302 Found, except that it does not allow rewriting the request method from POST to GET. This |
1974 | | specification defines no equivalent counterpart for 301 Moved Permanently. |
1975 | | </p> |
1976 | | </div> |
1977 | | <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> |
1978 | | <p id="rfc.section.7.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD |
1979 | | request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
1980 | | These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. |
1981 | | </p> |
1982 | | <div id="rfc.iref.37"></div> |
1983 | | <div id="rfc.iref.s.17"></div> |
1984 | | <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> |
1985 | | <p id="rfc.section.7.4.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p> |
1986 | | <div id="rfc.iref.38"></div> |
1987 | | <div id="rfc.iref.s.18"></div> |
1988 | | <h3 id="rfc.section.7.4.2"><a href="#rfc.section.7.4.2">7.4.2</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> |
1989 | | <p id="rfc.section.7.4.2.p.1">This code is reserved for future use.</p> |
1990 | | <div id="rfc.iref.39"></div> |
1991 | | <div id="rfc.iref.s.19"></div> |
1992 | | <h3 id="rfc.section.7.4.3"><a href="#rfc.section.7.4.3">7.4.3</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> |
1993 | | <p id="rfc.section.7.4.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might |
1994 | | be successful, but any credentials that were provided in the request are insufficient. The request <em class="bcp14">SHOULD NOT</em> be repeated with the same credentials. |
1995 | | </p> |
1996 | | <p id="rfc.section.7.4.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available |
1997 | | to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead. |
1998 | | </p> |
1999 | | <div id="rfc.iref.40"></div> |
2000 | | <div id="rfc.iref.s.20"></div> |
2001 | | <h3 id="rfc.section.7.4.4"><a href="#rfc.section.7.4.4">7.4.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> |
2002 | | <p id="rfc.section.7.4.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary |
2003 | | or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable |
2004 | | and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request |
2005 | | has been refused, or when no other response is applicable. |
2006 | | </p> |
2007 | | <div id="rfc.iref.41"></div> |
2008 | | <div id="rfc.iref.s.21"></div> |
2009 | | <h3 id="rfc.section.7.4.5"><a href="#rfc.section.7.4.5">7.4.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> |
2010 | | <p id="rfc.section.7.4.5.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource. |
2011 | | </p> |
2012 | | <div id="rfc.iref.42"></div> |
2013 | | <div id="rfc.iref.s.22"></div> |
2014 | | <h3 id="rfc.section.7.4.6"><a href="#rfc.section.7.4.6">7.4.6</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> |
2015 | | <p id="rfc.section.7.4.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics |
2016 | | not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). |
2017 | | </p> |
2018 | | <p id="rfc.section.7.4.6.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user |
2019 | | or user agent can choose the one most appropriate. Depending upon the format and the capabilities of the user agent, selection |
2020 | | of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. |
2021 | | </p> |
2022 | | <div class="note" id="rfc.section.7.4.6.p.3"> |
2023 | | <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the |
2024 | | request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the |
2025 | | header fields of an incoming response to determine if it is acceptable. |
2026 | | </p> |
2027 | | </div> |
2028 | | <p id="rfc.section.7.4.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. |
2029 | | </p> |
2030 | | <div id="rfc.iref.43"></div> |
2031 | | <div id="rfc.iref.s.23"></div> |
2032 | | <h3 id="rfc.section.7.4.7"><a href="#rfc.section.7.4.7">7.4.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> |
2033 | | <p id="rfc.section.7.4.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. |
2034 | | </p> |
2035 | | <div id="rfc.iref.44"></div> |
2036 | | <div id="rfc.iref.s.24"></div> |
2037 | | <h3 id="rfc.section.7.4.8"><a href="#rfc.section.7.4.8">7.4.8</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> |
2038 | | <p id="rfc.section.7.4.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in |
2039 | | situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response |
2040 | | body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would |
2041 | | include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. |
2042 | | </p> |
2043 | | <p id="rfc.section.7.4.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation |
2044 | | being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might |
2045 | | use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely |
2046 | | contain a list of the differences between the two versions. |
2047 | | </p> |
2048 | | <div id="rfc.iref.45"></div> |
2049 | | <div id="rfc.iref.s.25"></div> |
2050 | | <h3 id="rfc.section.7.4.9"><a href="#rfc.section.7.4.9">7.4.9</a> <a id="status.410" href="#status.410">410 Gone</a></h3> |
2051 | | <p id="rfc.section.7.4.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to |
2052 | | be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine, |
2053 | | whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. |
2054 | | </p> |
2055 | | <p id="rfc.section.7.4.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource |
2056 | | is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event |
2057 | | is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's |
2058 | | site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time |
2059 | | — that is left to the discretion of the server owner. |
2060 | | </p> |
2061 | | <p id="rfc.section.7.4.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. |
2062 | | </p> |
2063 | | <div id="rfc.iref.46"></div> |
2064 | | <div id="rfc.iref.s.26"></div> |
2065 | | <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> |
2066 | | <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request |
2067 | | message. |
2068 | | </p> |
2069 | | <div id="rfc.iref.47"></div> |
2070 | | <div id="rfc.iref.s.27"></div> |
2071 | | <h3 id="rfc.section.7.4.11"><a href="#rfc.section.7.4.11">7.4.11</a> <a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3> |
2072 | | <p id="rfc.section.7.4.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able |
2073 | | to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. |
2074 | | </p> |
2075 | | <p id="rfc.section.7.4.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. |
2076 | | </p> |
2077 | | <div id="rfc.iref.48"></div> |
2078 | | <div id="rfc.iref.s.28"></div> |
2079 | | <h3 id="rfc.section.7.4.12"><a href="#rfc.section.7.4.12">7.4.12</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> |
2080 | | <p id="rfc.section.7.4.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret. |
2081 | | This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long |
2082 | | query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that |
2083 | | points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present |
2084 | | in some servers using fixed-length buffers for reading or manipulating the effective request URI. |
2085 | | </p> |
2086 | | <div id="rfc.iref.49"></div> |
2087 | | <div id="rfc.iref.s.29"></div> |
2088 | | <h3 id="rfc.section.7.4.13"><a href="#rfc.section.7.4.13">7.4.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> |
2089 | | <p id="rfc.section.7.4.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method |
2090 | | on the target resource. |
2091 | | </p> |
2092 | | <div id="rfc.iref.50"></div> |
2093 | | <div id="rfc.iref.s.30"></div> |
2094 | | <h3 id="rfc.section.7.4.14"><a href="#rfc.section.7.4.14">7.4.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> |
2095 | | <p id="rfc.section.7.4.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could |
2096 | | not be met by the next-hop server. |
2097 | | </p> |
2098 | | <div id="rfc.iref.51"></div> |
2099 | | <div id="rfc.iref.s.31"></div> |
2100 | | <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> |
2101 | | <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. |
2102 | | </p> |
2103 | | <div id="rfc.figure.u.8"></div> |
2104 | | <p>Example:</p> <pre class="text">HTTP/1.1 426 Upgrade Required |
2105 | | Upgrade: HTTP/3.0 |
2106 | | Connection: Upgrade |
2107 | | Content-Length: 53 |
2108 | | Content-Type: text/plain |
2109 | | |
2110 | | <span id="s426body">This service requires use of the HTTP/3.0 protocol. |
2111 | | </span></pre><p id="rfc.section.7.4.15.p.3">The server <em class="bcp14">SHOULD</em> include a message body in the 426 response which indicates in human readable form the reason for the error and describes any |
2112 | | alternative courses which may be available to the user. |
2113 | | </p> |
2114 | | <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> |
2115 | | <p id="rfc.section.7.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable |
2116 | | of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
2117 | | User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. |
2118 | | </p> |
2119 | | <div id="rfc.iref.52"></div> |
2120 | | <div id="rfc.iref.s.32"></div> |
2121 | | <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> |
2122 | | <p id="rfc.section.7.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> |
2123 | | <div id="rfc.iref.53"></div> |
2124 | | <div id="rfc.iref.s.33"></div> |
2125 | | <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3> |
2126 | | <p id="rfc.section.7.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server |
2127 | | does not recognize the request method and is not capable of supporting it for any resource. |
2128 | | </p> |
2129 | | <div id="rfc.iref.54"></div> |
2130 | | <div id="rfc.iref.s.34"></div> |
2131 | | <h3 id="rfc.section.7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3> |
2132 | | <p id="rfc.section.7.5.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting |
2133 | | to fulfill the request. |
2134 | | </p> |
2135 | | <div id="rfc.iref.55"></div> |
2136 | | <div id="rfc.iref.s.35"></div> |
2137 | | <h3 id="rfc.section.7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> |
2138 | | <p id="rfc.section.7.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> |
2139 | | <p id="rfc.section.7.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the |
2140 | | delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 10.8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. |
2141 | | </p> |
2142 | | <div class="note" id="rfc.section.7.5.4.p.3"> |
2143 | | <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers might |
2144 | | wish to simply refuse the connection. |
2145 | | </p> |
2146 | | </div> |
2147 | | <div id="rfc.iref.56"></div> |
2148 | | <div id="rfc.iref.s.36"></div> |
2149 | | <h3 id="rfc.section.7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> |
2150 | | <p id="rfc.section.7.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the |
2151 | | URI (e.g., HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed to access in attempting to complete the request. |
2152 | | </p> |
2153 | | <div class="note" id="rfc.section.7.5.5.p.2"> |
2154 | | <p> <b>Note</b> to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. |
2155 | | </p> |
2156 | | </div> |
2157 | | <div id="rfc.iref.57"></div> |
2158 | | <div id="rfc.iref.s.37"></div> |
2159 | | <h3 id="rfc.section.7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> |
2160 | | <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server |
2161 | | is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described |
2162 | | in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. |
2163 | | </p> |
2164 | | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> |
2165 | | <p id="rfc.section.8.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is |
2166 | | a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: |
2167 | | </p> |
2168 | | <div id="rfc.figure.u.9"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
2169 | | </pre><p id="rfc.section.8.p.3">The other formats are described here only for compatibility with obsolete implementations.</p> |
2170 | | <div id="rfc.figure.u.10"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
2171 | | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
2172 | | </pre><p id="rfc.section.8.p.5">HTTP/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. |
2173 | | </p> |
2174 | | <p id="rfc.section.8.p.6">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated |
2175 | | Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for |
2176 | | time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. |
2177 | | </p> |
2178 | | <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#http.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> |
2179 | | </pre><div id="preferred.date.format"> |
2180 | | <p id="rfc.section.8.p.8"> Preferred format:</p> |
2181 | | </div> |
2182 | | <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#notation" class="smpl">SP</a> date1 <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> |
2183 | | ; fixed length subset of the format defined in |
2184 | | ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> |
2185 | | |
2186 | | <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive |
2187 | | / %x54.75.65 ; "Tue", case-sensitive |
2188 | | / %x57.65.64 ; "Wed", case-sensitive |
2189 | | / %x54.68.75 ; "Thu", case-sensitive |
2190 | | / %x46.72.69 ; "Fri", case-sensitive |
2191 | | / %x53.61.74 ; "Sat", case-sensitive |
2192 | | / %x53.75.6E ; "Sun", case-sensitive |
2193 | | |
2194 | | <a href="#obsolete.date.formats" class="smpl">date1</a> = <a href="#preferred.date.format" class="smpl">day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">month</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> |
2195 | | ; e.g., 02 Jun 1982 |
2196 | | |
2197 | | <a href="#preferred.date.format" class="smpl">day</a> = 2<a href="#notation" class="smpl">DIGIT</a> |
2198 | | <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; "Jan", case-sensitive |
2199 | | / %x46.65.62 ; "Feb", case-sensitive |
2200 | | / %x4D.61.72 ; "Mar", case-sensitive |
2201 | | / %x41.70.72 ; "Apr", case-sensitive |
2202 | | / %x4D.61.79 ; "May", case-sensitive |
2203 | | / %x4A.75.6E ; "Jun", case-sensitive |
2204 | | / %x4A.75.6C ; "Jul", case-sensitive |
2205 | | / %x41.75.67 ; "Aug", case-sensitive |
2206 | | / %x53.65.70 ; "Sep", case-sensitive |
2207 | | / %x4F.63.74 ; "Oct", case-sensitive |
2208 | | / %x4E.6F.76 ; "Nov", case-sensitive |
2209 | | / %x44.65.63 ; "Dec", case-sensitive |
2210 | | <a href="#preferred.date.format" class="smpl">year</a> = 4<a href="#notation" class="smpl">DIGIT</a> |
2211 | | |
2212 | | <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; "GMT", case-sensitive |
2213 | | |
2214 | | <a href="#preferred.date.format" class="smpl">time-of-day</a> = <a href="#preferred.date.format" class="smpl">hour</a> ":" <a href="#preferred.date.format" class="smpl">minute</a> ":" <a href="#preferred.date.format" class="smpl">second</a> |
2215 | | ; 00:00:00 - 23:59:59 |
2216 | | |
2217 | | <a href="#preferred.date.format" class="smpl">hour</a> = 2<a href="#notation" class="smpl">DIGIT</a> |
2218 | | <a href="#preferred.date.format" class="smpl">minute</a> = 2<a href="#notation" class="smpl">DIGIT</a> |
2219 | | <a href="#preferred.date.format" class="smpl">second</a> = 2<a href="#notation" class="smpl">DIGIT</a> |
2220 | | </pre><p id="rfc.section.8.p.10">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>). |
2221 | | </p> |
2222 | | <div id="obsolete.date.formats"> |
2223 | | <p id="rfc.section.8.p.11"> Obsolete formats:</p> |
2224 | | </div> |
2225 | | <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.19"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> |
2226 | | </pre><div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.20"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#notation" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> |
2227 | | <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#notation" class="smpl">DIGIT</a> |
2228 | | ; day-month-year (e.g., 02-Jun-82) |
2229 | | |
2230 | | <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
2231 | | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
2232 | | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
2233 | | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
2234 | | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
2235 | | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
2236 | | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
2237 | | </pre><div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#notation" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#notation" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> |
2238 | | <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#notation" class="smpl">SP</a> ( 2<a href="#notation" class="smpl">DIGIT</a> / ( <a href="#notation" class="smpl">SP</a> 1<a href="#notation" class="smpl">DIGIT</a> )) |
2239 | | ; month day (e.g., Jun 2) |
2240 | | </pre><div class="note" id="rfc.section.8.p.15"> |
2241 | | <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications, |
2242 | | as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. |
2243 | | </p> |
2244 | | </div> |
2245 | | <div class="note" id="rfc.section.8.p.16"> |
2246 | | <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers |
2247 | | are not required to use these formats for user presentation, request logging, etc. |
2248 | | </p> |
2249 | | </div> |
2250 | | <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1> |
2251 | | <p id="rfc.section.9.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields |
2252 | | using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. |
2253 | | By convention, the products are listed in order of their significance for identifying the application. |
2254 | | </p> |
2255 | | <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#core.rules" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] |
2256 | | <a href="#product.tokens" class="smpl">product-version</a> = <a href="#core.rules" class="smpl">token</a> |
2257 | | </pre><p id="rfc.section.9.p.3">Examples:</p> |
2258 | | <div id="rfc.figure.u.17"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
2259 | | Server: Apache/0.8.4 |
2260 | | </pre><p id="rfc.section.9.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). |
2261 | | </p> |
2262 | | <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> |
2263 | | <p id="rfc.section.10.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> |
2264 | | <div id="rfc.iref.a.1"></div> |
2265 | | <div id="rfc.iref.h.2"></div> |
2266 | | <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> |
2267 | | <p id="rfc.section.10.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field |
2268 | | is strictly to inform the recipient of valid request methods associated with the resource. |
2269 | | </p> |
2270 | | <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.24"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#method" class="smpl">Method</a> |
2271 | | </pre><p id="rfc.section.10.1.p.3">Example of use:</p> |
2272 | | <div id="rfc.figure.u.19"></div><pre class="text"> Allow: GET, HEAD, PUT |
2273 | | </pre><p id="rfc.section.10.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> |
2274 | | <p id="rfc.section.10.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according |
2275 | | to the generic message handling rules. |
2276 | | </p> |
2277 | | <div id="rfc.iref.d.2"></div> |
2278 | | <div id="rfc.iref.h.3"></div> |
2279 | | <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="header.date" href="#header.date">Date</a></h2> |
2280 | | <p id="rfc.section.10.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the |
2281 | | Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 8</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. |
2282 | | </p> |
2283 | | <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> |
2284 | | </pre><p id="rfc.section.10.2.p.3">An example is</p> |
2285 | | <div id="rfc.figure.u.21"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT |
2286 | | </pre><p id="rfc.section.10.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: |
2287 | | </p> |
2288 | | <ol> |
2289 | | <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option. |
2290 | | </li> |
2291 | | <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or 503 (Service Unavailable), and it |
2292 | | is inconvenient or impossible to generate a valid Date. |
2293 | | </li> |
2294 | | <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. |
2295 | | </li> |
2296 | | </ol> |
2297 | | <p id="rfc.section.10.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. |
2298 | | </p> |
2299 | | <p id="rfc.section.10.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it |
2300 | | when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). |
2301 | | </p> |
2302 | | <p id="rfc.section.10.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means |
2303 | | of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload |
2304 | | is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic |
2305 | | value. |
2306 | | </p> |
2307 | | <div id="rfc.iref.e.1"></div> |
2308 | | <div id="rfc.iref.h.4"></div> |
2309 | | <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2> |
2310 | | <p id="rfc.section.10.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> |
2311 | | <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> |
2312 | | |
2313 | | <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] |
2314 | | *( <a href="#core.rules" class="smpl">OWS</a> ";" [ <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">expect-param</a> ] ) |
2315 | | <a href="#header.expect" class="smpl">expect-param</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] |
2316 | | |
2317 | | <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> |
2318 | | <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> |
2319 | | </pre><p id="rfc.section.10.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand |
2320 | | or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. |
2321 | | </p> |
2322 | | <p id="rfc.section.10.3.p.4">The only expectation defined by this specification is:</p> |
2323 | | <p id="rfc.section.10.3.p.5"><span id="rfc.iref.89"></span><span id="rfc.iref.e.2"></span> 100-continue |
2324 | | </p> |
2325 | | <ul class="empty"> |
2326 | | <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. |
2327 | | </li> |
2328 | | </ul> |
2329 | | <p id="rfc.section.10.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> |
2330 | | <p id="rfc.section.10.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header |
2331 | | field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. |
2332 | | </p> |
2333 | | <p id="rfc.section.10.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> |
2334 | | <div id="rfc.iref.f.1"></div> |
2335 | | <div id="rfc.iref.h.5"></div> |
2336 | | <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="header.from" href="#header.from">From</a></h2> |
2337 | | <p id="rfc.section.10.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: |
2338 | | </p> |
2339 | | <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> |
2340 | | |
2341 | | <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> |
2342 | | </pre><p id="rfc.section.10.4.p.3">An example is:</p> |
2343 | | <div id="rfc.figure.u.24"></div><pre class="text"> From: webmaster@example.org |
2344 | | </pre><p id="rfc.section.10.4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed |
2345 | | on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving |
2346 | | end. |
2347 | | </p> |
2348 | | <p id="rfc.section.10.4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original |
2349 | | issuer's address <em class="bcp14">SHOULD</em> be used. |
2350 | | </p> |
2351 | | <p id="rfc.section.10.4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's |
2352 | | security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at |
2353 | | any time prior to a request. |
2354 | | </p> |
2355 | | <div id="rfc.iref.l.1"></div> |
2356 | | <div id="rfc.iref.h.6"></div> |
2357 | | <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="header.location" href="#header.location">Location</a></h2> |
2358 | | <p id="rfc.section.10.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. |
2359 | | </p> |
2360 | | <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> |
2361 | | </pre><p id="rfc.section.10.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, |
2362 | | the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. |
2363 | | </p> |
2364 | | <p id="rfc.section.10.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, |
2365 | | then the original URI's fragment identifier is added to the final value. |
2366 | | </p> |
2367 | | <div id="rfc.figure.u.26"></div> |
2368 | | <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim |
2369 | | </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> |
2370 | | <div id="rfc.figure.u.27"></div> |
2371 | | <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html |
2372 | | </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> |
2373 | | <div class="note" id="rfc.section.10.5.p.7"> |
2374 | | <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate |
2375 | | or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.1</a>). |
2376 | | </p> |
2377 | | </div> |
2378 | | <p id="rfc.section.10.5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears |
2379 | | in a 201 Created response, where the Location header field specifies the URI for the entire created resource. |
2380 | | </p> |
2381 | | <div class="note" id="rfc.section.10.5.p.9"> |
2382 | | <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. |
2383 | | It is therefore possible for a response to contain header fields for both Location and Content-Location. |
2384 | | </p> |
2385 | | </div> |
2386 | | <div id="rfc.iref.m.9"></div> |
2387 | | <div id="rfc.iref.h.7"></div> |
2388 | | <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> |
2389 | | <p id="rfc.section.10.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting |
2390 | | to trace a request which appears to be failing or looping mid-chain. |
2391 | | </p> |
2392 | | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> |
2393 | | </pre><p id="rfc.section.10.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> |
2394 | | <p id="rfc.section.10.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). |
2395 | | </p> |
2396 | | <p id="rfc.section.10.6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. |
2397 | | </p> |
2398 | | <div id="rfc.iref.r.1"></div> |
2399 | | <div id="rfc.iref.h.8"></div> |
2400 | | <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2> |
2401 | | <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI |
2402 | | was obtained (the "referrer", although the header field is misspelled.). |
2403 | | </p> |
2404 | | <p id="rfc.section.10.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, |
2405 | | etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling |
2406 | | where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. |
2407 | | </p> |
2408 | | <p id="rfc.section.10.7.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), |
2409 | | the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with |
2410 | | non-HTTP URIs (e.g., FTP). |
2411 | | </p> |
2412 | | <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> |
2413 | | </pre><p id="rfc.section.10.7.p.5">Example:</p> |
2414 | | <div id="rfc.figure.u.30"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html |
2415 | | </pre><p id="rfc.section.10.7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations. |
2416 | | </p> |
2417 | | <div id="rfc.iref.r.2"></div> |
2418 | | <div id="rfc.iref.h.9"></div> |
2419 | | <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> |
2420 | | <p id="rfc.section.10.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected |
2421 | | to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing |
2422 | | the redirected request. |
2423 | | </p> |
2424 | | <p id="rfc.section.10.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> |
2425 | | <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> |
2426 | | </pre><div id="rule.delta-seconds"> |
2427 | | <p id="rfc.section.10.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> |
2428 | | </div> |
2429 | | <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> |
2430 | | </pre><p id="rfc.section.10.8.p.6">Two examples of its use are</p> |
2431 | | <div id="rfc.figure.u.33"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
2432 | | Retry-After: 120 |
2433 | | </pre><p id="rfc.section.10.8.p.8">In the latter example, the delay is 2 minutes.</p> |
2434 | | <div id="rfc.iref.s.38"></div> |
2435 | | <div id="rfc.iref.h.10"></div> |
2436 | | <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.server" href="#header.server">Server</a></h2> |
2437 | | <p id="rfc.section.10.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> |
2438 | | <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for |
2439 | | identifying the application. |
2440 | | </p> |
2441 | | <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.37"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) |
2442 | | </pre><p id="rfc.section.10.9.p.4">Example:</p> |
2443 | | <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 |
2444 | | </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
2445 | | </p> |
2446 | | <div class="note" id="rfc.section.10.9.p.7"> |
2447 | | <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks |
2448 | | against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable |
2449 | | option. |
2450 | | </p> |
2451 | | </div> |
2452 | | <div id="rfc.iref.u.1"></div> |
2453 | | <div id="rfc.iref.h.11"></div> |
2454 | | <h2 id="rfc.section.10.10"><a href="#rfc.section.10.10">10.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> |
2455 | | <p id="rfc.section.10.10.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests. |
2456 | | </p> |
2457 | | <p id="rfc.section.10.10.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular |
2458 | | user agent limitations. |
2459 | | </p> |
2460 | | <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance |
2461 | | for identifying the application. |
2462 | | </p> |
2463 | | <p id="rfc.section.10.10.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly |
2464 | | fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed |
2465 | | User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. |
2466 | | </p> |
2467 | | <p id="rfc.section.10.10.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility |
2468 | | with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; |
2469 | | doing so makes the field value more difficult to parse. |
2470 | | </p> |
2471 | | <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.38"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) |
2472 | | </pre><p id="rfc.section.10.10.p.7">Example:</p> |
2473 | | <div id="rfc.figure.u.37"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
2474 | | </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> |
2475 | | <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> |
2476 | | <p id="rfc.section.11.1.p.1">The registration procedure for HTTP request methods is defined by <a href="#method.registry" title="Method Registry">Section 2.2</a> of this document. |
2477 | | </p> |
2478 | | <p id="rfc.section.11.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: |
2479 | | </p> |
2480 | | <div id="rfc.table.1"> |
2481 | | <div id="iana.method.registration.table"></div> |
2482 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
2483 | | <thead> |
2484 | | <tr> |
2485 | | <th>Method</th> |
2486 | | <th>Safe</th> |
2487 | | <th>Reference</th> |
2488 | | </tr> |
2489 | | </thead> |
2490 | | <tbody> |
2491 | | <tr> |
2492 | | <td class="left">CONNECT</td> |
2493 | | <td class="left">no</td> |
2494 | | <td class="left"> <a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 6.9</a> |
2495 | | </td> |
2496 | | </tr> |
2497 | | <tr> |
2498 | | <td class="left">DELETE</td> |
2499 | | <td class="left">no</td> |
2500 | | <td class="left"> <a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 6.7</a> |
2501 | | </td> |
2502 | | </tr> |
2503 | | <tr> |
2504 | | <td class="left">GET</td> |
2505 | | <td class="left">yes</td> |
2506 | | <td class="left"> <a href="#GET" id="rfc.xref.GET.2" title="GET">Section 6.3</a> |
2507 | | </td> |
2508 | | </tr> |
2509 | | <tr> |
2510 | | <td class="left">HEAD</td> |
2511 | | <td class="left">yes</td> |
2512 | | <td class="left"> <a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 6.4</a> |
2513 | | </td> |
2514 | | </tr> |
2515 | | <tr> |
2516 | | <td class="left">OPTIONS</td> |
2517 | | <td class="left">yes</td> |
2518 | | <td class="left"> <a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 6.2</a> |
2519 | | </td> |
2520 | | </tr> |
2521 | | <tr> |
2522 | | <td class="left">POST</td> |
2523 | | <td class="left">no</td> |
2524 | | <td class="left"> <a href="#POST" id="rfc.xref.POST.2" title="POST">Section 6.5</a> |
2525 | | </td> |
2526 | | </tr> |
2527 | | <tr> |
2528 | | <td class="left">PUT</td> |
2529 | | <td class="left">no</td> |
2530 | | <td class="left"> <a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 6.6</a> |
2531 | | </td> |
2532 | | </tr> |
2533 | | <tr> |
2534 | | <td class="left">TRACE</td> |
2535 | | <td class="left">yes</td> |
2536 | | <td class="left"> <a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 6.8</a> |
2537 | | </td> |
2538 | | </tr> |
2539 | | </tbody> |
2540 | | </table> |
2541 | | </div> |
2542 | | <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2> |
2543 | | <p id="rfc.section.11.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.2</a> of this document. |
2544 | | </p> |
2545 | | <p id="rfc.section.11.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: |
2546 | | </p> |
2547 | | <div id="rfc.table.2"> |
2548 | | <div id="iana.status.code.registration.table"></div> |
2549 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
2550 | | <thead> |
2551 | | <tr> |
2552 | | <th>Value</th> |
2553 | | <th>Description</th> |
2554 | | <th>Reference</th> |
2555 | | </tr> |
2556 | | </thead> |
2557 | | <tbody> |
2558 | | <tr> |
2559 | | <td class="left">100</td> |
2560 | | <td class="left">Continue</td> |
2561 | | <td class="left"> <a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 7.1.1</a> |
2562 | | </td> |
2563 | | </tr> |
2564 | | <tr> |
2565 | | <td class="left">101</td> |
2566 | | <td class="left">Switching Protocols</td> |
2567 | | <td class="left"> <a href="#status.101" id="rfc.xref.status.101.2" title="101 Switching Protocols">Section 7.1.2</a> |
2568 | | </td> |
2569 | | </tr> |
2570 | | <tr> |
2571 | | <td class="left">200</td> |
2572 | | <td class="left">OK</td> |
2573 | | <td class="left"> <a href="#status.200" id="rfc.xref.status.200.2" title="200 OK">Section 7.2.1</a> |
2574 | | </td> |
2575 | | </tr> |
2576 | | <tr> |
2577 | | <td class="left">201</td> |
2578 | | <td class="left">Created</td> |
2579 | | <td class="left"> <a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 7.2.2</a> |
2580 | | </td> |
2581 | | </tr> |
2582 | | <tr> |
2583 | | <td class="left">202</td> |
2584 | | <td class="left">Accepted</td> |
2585 | | <td class="left"> <a href="#status.202" id="rfc.xref.status.202.2" title="202 Accepted">Section 7.2.3</a> |
2586 | | </td> |
2587 | | </tr> |
2588 | | <tr> |
2589 | | <td class="left">203</td> |
2590 | | <td class="left">Non-Authoritative Information</td> |
2591 | | <td class="left"> <a href="#status.203" id="rfc.xref.status.203.2" title="203 Non-Authoritative Information">Section 7.2.4</a> |
2592 | | </td> |
2593 | | </tr> |
2594 | | <tr> |
2595 | | <td class="left">204</td> |
2596 | | <td class="left">No Content</td> |
2597 | | <td class="left"> <a href="#status.204" id="rfc.xref.status.204.2" title="204 No Content">Section 7.2.5</a> |
2598 | | </td> |
2599 | | </tr> |
2600 | | <tr> |
2601 | | <td class="left">205</td> |
2602 | | <td class="left">Reset Content</td> |
2603 | | <td class="left"> <a href="#status.205" id="rfc.xref.status.205.2" title="205 Reset Content">Section 7.2.6</a> |
2604 | | </td> |
2605 | | </tr> |
2606 | | <tr> |
2607 | | <td class="left">300</td> |
2608 | | <td class="left">Multiple Choices</td> |
2609 | | <td class="left"> <a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section 7.3.1</a> |
2610 | | </td> |
2611 | | </tr> |
2612 | | <tr> |
2613 | | <td class="left">301</td> |
2614 | | <td class="left">Moved Permanently</td> |
2615 | | <td class="left"> <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">Section 7.3.2</a> |
2616 | | </td> |
2617 | | </tr> |
2618 | | <tr> |
2619 | | <td class="left">302</td> |
2620 | | <td class="left">Found</td> |
2621 | | <td class="left"> <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">Section 7.3.3</a> |
2622 | | </td> |
2623 | | </tr> |
2624 | | <tr> |
2625 | | <td class="left">303</td> |
2626 | | <td class="left">See Other</td> |
2627 | | <td class="left"> <a href="#status.303" id="rfc.xref.status.303.2" title="303 See Other">Section 7.3.4</a> |
2628 | | </td> |
2629 | | </tr> |
2630 | | <tr> |
2631 | | <td class="left">305</td> |
2632 | | <td class="left">Use Proxy</td> |
2633 | | <td class="left"> <a href="#status.305" id="rfc.xref.status.305.2" title="305 Use Proxy">Section 7.3.5</a> |
2634 | | </td> |
2635 | | </tr> |
2636 | | <tr> |
2637 | | <td class="left">306</td> |
2638 | | <td class="left">(Unused)</td> |
2639 | | <td class="left"> <a href="#status.306" id="rfc.xref.status.306.1" title="306 (Unused)">Section 7.3.6</a> |
2640 | | </td> |
2641 | | </tr> |
2642 | | <tr> |
2643 | | <td class="left">307</td> |
2644 | | <td class="left">Temporary Redirect</td> |
2645 | | <td class="left"> <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">Section 7.3.7</a> |
2646 | | </td> |
2647 | | </tr> |
2648 | | <tr> |
2649 | | <td class="left">400</td> |
2650 | | <td class="left">Bad Request</td> |
2651 | | <td class="left"> <a href="#status.400" id="rfc.xref.status.400.2" title="400 Bad Request">Section 7.4.1</a> |
2652 | | </td> |
2653 | | </tr> |
2654 | | <tr> |
2655 | | <td class="left">402</td> |
2656 | | <td class="left">Payment Required</td> |
2657 | | <td class="left"> <a href="#status.402" id="rfc.xref.status.402.2" title="402 Payment Required">Section 7.4.2</a> |
2658 | | </td> |
2659 | | </tr> |
2660 | | <tr> |
2661 | | <td class="left">403</td> |
2662 | | <td class="left">Forbidden</td> |
2663 | | <td class="left"> <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">Section 7.4.3</a> |
2664 | | </td> |
2665 | | </tr> |
2666 | | <tr> |
2667 | | <td class="left">404</td> |
2668 | | <td class="left">Not Found</td> |
2669 | | <td class="left"> <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">Section 7.4.4</a> |
2670 | | </td> |
2671 | | </tr> |
2672 | | <tr> |
2673 | | <td class="left">405</td> |
2674 | | <td class="left">Method Not Allowed</td> |
2675 | | <td class="left"> <a href="#status.405" id="rfc.xref.status.405.2" title="405 Method Not Allowed">Section 7.4.5</a> |
2676 | | </td> |
2677 | | </tr> |
2678 | | <tr> |
2679 | | <td class="left">406</td> |
2680 | | <td class="left">Not Acceptable</td> |
2681 | | <td class="left"> <a href="#status.406" id="rfc.xref.status.406.2" title="406 Not Acceptable">Section 7.4.6</a> |
2682 | | </td> |
2683 | | </tr> |
2684 | | <tr> |
2685 | | <td class="left">408</td> |
2686 | | <td class="left">Request Timeout</td> |
2687 | | <td class="left"> <a href="#status.408" id="rfc.xref.status.408.2" title="408 Request Timeout">Section 7.4.7</a> |
2688 | | </td> |
2689 | | </tr> |
2690 | | <tr> |
2691 | | <td class="left">409</td> |
2692 | | <td class="left">Conflict</td> |
2693 | | <td class="left"> <a href="#status.409" id="rfc.xref.status.409.2" title="409 Conflict">Section 7.4.8</a> |
2694 | | </td> |
2695 | | </tr> |
2696 | | <tr> |
2697 | | <td class="left">410</td> |
2698 | | <td class="left">Gone</td> |
2699 | | <td class="left"> <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">Section 7.4.9</a> |
2700 | | </td> |
2701 | | </tr> |
2702 | | <tr> |
2703 | | <td class="left">411</td> |
2704 | | <td class="left">Length Required</td> |
2705 | | <td class="left"> <a href="#status.411" id="rfc.xref.status.411.2" title="411 Length Required">Section 7.4.10</a> |
2706 | | </td> |
2707 | | </tr> |
2708 | | <tr> |
2709 | | <td class="left">413</td> |
2710 | | <td class="left">Request Representation Too Large</td> |
2711 | | <td class="left"> <a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Representation Too Large">Section 7.4.11</a> |
2712 | | </td> |
2713 | | </tr> |
2714 | | <tr> |
2715 | | <td class="left">414</td> |
2716 | | <td class="left">URI Too Long</td> |
2717 | | <td class="left"> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section 7.4.12</a> |
2718 | | </td> |
2719 | | </tr> |
2720 | | <tr> |
2721 | | <td class="left">415</td> |
2722 | | <td class="left">Unsupported Media Type</td> |
2723 | | <td class="left"> <a href="#status.415" id="rfc.xref.status.415.2" title="415 Unsupported Media Type">Section 7.4.13</a> |
2724 | | </td> |
2725 | | </tr> |
2726 | | <tr> |
2727 | | <td class="left">417</td> |
2728 | | <td class="left">Expectation Failed</td> |
2729 | | <td class="left"> <a href="#status.417" id="rfc.xref.status.417.2" title="417 Expectation Failed">Section 7.4.14</a> |
2730 | | </td> |
2731 | | </tr> |
2732 | | <tr> |
2733 | | <td class="left">426</td> |
2734 | | <td class="left">Upgrade Required</td> |
2735 | | <td class="left"> <a href="#status.426" id="rfc.xref.status.426.2" title="426 Upgrade Required">Section 7.4.15</a> |
2736 | | </td> |
2737 | | </tr> |
2738 | | <tr> |
2739 | | <td class="left">500</td> |
2740 | | <td class="left">Internal Server Error</td> |
2741 | | <td class="left"> <a href="#status.500" id="rfc.xref.status.500.2" title="500 Internal Server Error">Section 7.5.1</a> |
2742 | | </td> |
2743 | | </tr> |
2744 | | <tr> |
2745 | | <td class="left">501</td> |
2746 | | <td class="left">Not Implemented</td> |
2747 | | <td class="left"> <a href="#status.501" id="rfc.xref.status.501.2" title="501 Not Implemented">Section 7.5.2</a> |
2748 | | </td> |
2749 | | </tr> |
2750 | | <tr> |
2751 | | <td class="left">502</td> |
2752 | | <td class="left">Bad Gateway</td> |
2753 | | <td class="left"> <a href="#status.502" id="rfc.xref.status.502.2" title="502 Bad Gateway">Section 7.5.3</a> |
2754 | | </td> |
2755 | | </tr> |
2756 | | <tr> |
2757 | | <td class="left">503</td> |
2758 | | <td class="left">Service Unavailable</td> |
2759 | | <td class="left"> <a href="#status.503" id="rfc.xref.status.503.2" title="503 Service Unavailable">Section 7.5.4</a> |
2760 | | </td> |
2761 | | </tr> |
2762 | | <tr> |
2763 | | <td class="left">504</td> |
2764 | | <td class="left">Gateway Timeout</td> |
2765 | | <td class="left"> <a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 7.5.5</a> |
2766 | | </td> |
2767 | | </tr> |
2768 | | <tr> |
2769 | | <td class="left">505</td> |
2770 | | <td class="left">HTTP Version Not Supported</td> |
2771 | | <td class="left"> <a href="#status.505" id="rfc.xref.status.505.2" title="505 HTTP Version Not Supported">Section 7.5.6</a> |
2772 | | </td> |
2773 | | </tr> |
2774 | | </tbody> |
2775 | | </table> |
2776 | | </div> |
2777 | | <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> |
2778 | | <p id="rfc.section.11.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.3"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): |
2779 | | </p> |
2780 | | <div id="rfc.table.3"> |
2781 | | <div id="iana.header.registration.table"></div> |
2782 | | <table class="tt full left" cellpadding="3" cellspacing="0"> |
2783 | | <thead> |
2784 | | <tr> |
2785 | | <th>Header Field Name</th> |
2786 | | <th>Protocol</th> |
2787 | | <th>Status</th> |
2788 | | <th>Reference</th> |
2789 | | </tr> |
2790 | | </thead> |
2791 | | <tbody> |
2792 | | <tr> |
2793 | | <td class="left">Allow</td> |
2794 | | <td class="left">http</td> |
2795 | | <td class="left">standard</td> |
2796 | | <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 10.1</a> |
2797 | | </td> |
2798 | | </tr> |
2799 | | <tr> |
2800 | | <td class="left">Date</td> |
2801 | | <td class="left">http</td> |
2802 | | <td class="left">standard</td> |
2803 | | <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 10.2</a> |
2804 | | </td> |
2805 | | </tr> |
2806 | | <tr> |
2807 | | <td class="left">Expect</td> |
2808 | | <td class="left">http</td> |
2809 | | <td class="left">standard</td> |
2810 | | <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 10.3</a> |
2811 | | </td> |
2812 | | </tr> |
2813 | | <tr> |
2814 | | <td class="left">From</td> |
2815 | | <td class="left">http</td> |
2816 | | <td class="left">standard</td> |
2817 | | <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 10.4</a> |
2818 | | </td> |
2819 | | </tr> |
2820 | | <tr> |
2821 | | <td class="left">Location</td> |
2822 | | <td class="left">http</td> |
2823 | | <td class="left">standard</td> |
2824 | | <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 10.5</a> |
2825 | | </td> |
2826 | | </tr> |
2827 | | <tr> |
2828 | | <td class="left">Max-Forwards</td> |
2829 | | <td class="left">http</td> |
2830 | | <td class="left">standard</td> |
2831 | | <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 10.6</a> |
2832 | | </td> |
2833 | | </tr> |
2834 | | <tr> |
2835 | | <td class="left">Referer</td> |
2836 | | <td class="left">http</td> |
2837 | | <td class="left">standard</td> |
2838 | | <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 10.7</a> |
2839 | | </td> |
2840 | | </tr> |
2841 | | <tr> |
2842 | | <td class="left">Retry-After</td> |
2843 | | <td class="left">http</td> |
2844 | | <td class="left">standard</td> |
2845 | | <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 10.8</a> |
2846 | | </td> |
2847 | | </tr> |
2848 | | <tr> |
2849 | | <td class="left">Server</td> |
2850 | | <td class="left">http</td> |
2851 | | <td class="left">standard</td> |
2852 | | <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.9</a> |
2853 | | </td> |
2854 | | </tr> |
2855 | | <tr> |
2856 | | <td class="left">User-Agent</td> |
2857 | | <td class="left">http</td> |
2858 | | <td class="left">standard</td> |
2859 | | <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.10</a> |
2860 | | </td> |
2861 | | </tr> |
2862 | | </tbody> |
2863 | | </table> |
2864 | | </div> |
2865 | | <p id="rfc.section.11.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> |
2866 | | <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> |
2867 | | <p id="rfc.section.12.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 |
2868 | | as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does |
2869 | | make some suggestions for reducing security risks. |
2870 | | </p> |
2871 | | <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> |
2872 | | <p id="rfc.section.12.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any |
2873 | | a priori method of determining the sensitivity of any particular piece of information within the context of any given request. |
2874 | | Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth |
2875 | | special mention in this context: Server, Via, Referer and From. |
2876 | | </p> |
2877 | | <p id="rfc.section.12.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks |
2878 | | against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. |
2879 | | </p> |
2880 | | <p id="rfc.section.12.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, |
2881 | | they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. |
2882 | | </p> |
2883 | | <p id="rfc.section.12.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its |
2884 | | power can be abused if user details are not separated from the information contained in the Referer. Even when the personal |
2885 | | information has been removed, the Referer header field might indicate a private document's URI whose publication would be |
2886 | | inappropriate. |
2887 | | </p> |
2888 | | <p id="rfc.section.12.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and |
2889 | | hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. |
2890 | | </p> |
2891 | | <p id="rfc.section.12.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending |
2892 | | of From and Referer information. |
2893 | | </p> |
2894 | | <p id="rfc.section.12.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 10.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might |
2895 | | be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has |
2896 | | no better mechanism. |
2897 | | </p> |
2898 | | <p id="rfc.section.12.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material, |
2899 | | to uniquely identify the user. |
2900 | | </p> |
2901 | | <p id="rfc.section.12.1.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 6.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used |
2902 | | to collect data from the client. |
2903 | | </p> |
2904 | | <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> |
2905 | | <p id="rfc.section.12.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly |
2906 | | recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could |
2907 | | have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From |
2908 | | information. |
2909 | | </p> |
2910 | | <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. |
2911 | | </p> |
2912 | | <p id="rfc.section.12.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing |
2913 | | servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. |
2914 | | Such services can use POST-based form submission instead. |
2915 | | </p> |
2916 | | <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> |
2917 | | <p id="rfc.section.12.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations |
2918 | | to make sure that they do not attempt to invalidate resources over which they have no authority. |
2919 | | </p> |
2920 | | <p id="rfc.section.12.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak |
2921 | | confidential information to the target server — although the fragment identifier is not transmitted in the final request, |
2922 | | it might be visible to the user agent through other means, such as scripting. |
2923 | | </p> |
2924 | | <h2 id="rfc.section.12.4"><a href="#rfc.section.12.4">12.4</a> Security Considerations for CONNECT |
2925 | | </h2> |
2926 | | <p id="rfc.section.12.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. |
2927 | | A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports. |
2928 | | </p> |
2929 | | <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> |
2930 | | <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. |
2931 | | </p> |
2932 | | <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References |
2933 | | </h1> |
2934 | | <h2 id="rfc.references.1"><a href="#rfc.section.14.1" id="rfc.section.14.1">14.1</a> Normative References |
2935 | | </h2> |
2936 | | <table> |
2937 | | <tr> |
2938 | | <td class="reference"><b id="Part1">[Part1]</b></td> |
2939 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), March 2012. |
2940 | | </td> |
2941 | | </tr> |
2942 | | <tr> |
2943 | | <td class="reference"><b id="Part3">[Part3]</b></td> |
2944 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-latest (work in progress), March 2012. |
2945 | | </td> |
2946 | | </tr> |
2947 | | <tr> |
2948 | | <td class="reference"><b id="Part4">[Part4]</b></td> |
2949 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), March 2012. |
2950 | | </td> |
2951 | | </tr> |
2952 | | <tr> |
2953 | | <td class="reference"><b id="Part5">[Part5]</b></td> |
2954 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), March 2012. |
2955 | | </td> |
2956 | | </tr> |
2957 | | <tr> |
2958 | | <td class="reference"><b id="Part6">[Part6]</b></td> |
2959 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), March 2012. |
2960 | | </td> |
2961 | | </tr> |
2962 | | <tr> |
2963 | | <td class="reference"><b id="Part7">[Part7]</b></td> |
2964 | | <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), March 2012. |
2965 | | </td> |
2966 | | </tr> |
2967 | | <tr> |
2968 | | <td class="reference"><b id="RFC2119">[RFC2119]</b></td> |
2969 | | <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. |
2970 | | </td> |
2971 | | </tr> |
2972 | | <tr> |
2973 | | <td class="reference"><b id="RFC3986">[RFC3986]</b></td> |
2974 | | <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005. |
2975 | | </td> |
2976 | | </tr> |
2977 | | <tr> |
2978 | | <td class="reference"><b id="RFC5234">[RFC5234]</b></td> |
2979 | | <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD 68, RFC 5234, January 2008. |
2980 | | </td> |
2981 | | </tr> |
2982 | | </table> |
2983 | | <h2 id="rfc.references.2"><a href="#rfc.section.14.2" id="rfc.section.14.2">14.2</a> Informative References |
2984 | | </h2> |
2985 | | <table> |
2986 | | <tr> |
2987 | | <td class="reference"><b id="RFC1123">[RFC1123]</b></td> |
2988 | | <td class="top"><a href="mailto:Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989. |
2989 | | </td> |
2990 | | </tr> |
2991 | | <tr> |
2992 | | <td class="reference"><b id="RFC1945">[RFC1945]</b></td> |
2993 | | <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. |
2994 | | </td> |
2995 | | </tr> |
2996 | | <tr> |
2997 | | <td class="reference"><b id="RFC2068">[RFC2068]</b></td> |
2998 | | <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. |
2999 | | </td> |
3000 | | </tr> |
3001 | | <tr> |
3002 | | <td class="reference"><b id="RFC2616">[RFC2616]</b></td> |
3003 | | <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. |
3004 | | </td> |
3005 | | </tr> |
3006 | | <tr> |
3007 | | <td class="reference"><b id="RFC2817">[RFC2817]</b></td> |
3008 | | <td class="top"><a href="mailto:rohit@4K-associates.com" title="4K Associates / UC Irvine">Khare, R.</a> and <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">S. Lawrence</a>, “<a href="http://tools.ietf.org/html/rfc2817">Upgrading to TLS Within HTTP/1.1</a>”, RFC 2817, May 2000. |
3009 | | </td> |
3010 | | </tr> |
3011 | | <tr> |
3012 | | <td class="reference"><b id="RFC3864">[RFC3864]</b></td> |
3013 | | <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. |
3014 | | </td> |
3015 | | </tr> |
3016 | | <tr> |
3017 | | <td class="reference"><b id="RFC5226">[RFC5226]</b></td> |
3018 | | <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 5226, May 2008. |
3019 | | </td> |
3020 | | </tr> |
3021 | | <tr> |
3022 | | <td class="reference"><b id="RFC5322">[RFC5322]</b></td> |
3023 | | <td class="top">Resnick, P., “<a href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>”, RFC 5322, October 2008. |
3024 | | </td> |
3025 | | </tr> |
3026 | | <tr> |
3027 | | <td class="reference"><b id="RFC5789">[RFC5789]</b></td> |
3028 | | <td class="top">Dusseault, L. and J. Snell, “<a href="http://tools.ietf.org/html/rfc5789">PATCH Method for HTTP</a>”, RFC 5789, March 2010. |
3029 | | </td> |
3030 | | </tr> |
3031 | | <tr> |
3032 | | <td class="reference"><b id="RFC5987">[RFC5987]</b></td> |
3033 | | <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC 5987, August 2010. |
3034 | | </td> |
3035 | | </tr> |
3036 | | </table> |
3037 | | <div class="avoidbreak"> |
3038 | | <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> |
3039 | | <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span> |
3040 | | (editor) |
3041 | | <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:fielding@gbiv.com"><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address> |
3042 | | <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">Alcatel-Lucent Bell Labs</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span> <span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:jg@freedesktop.org"><span class="email">jg@freedesktop.org</span></a></span><span class="vcardline">URI: <a href="http://gettys.wordpress.com/" class="url">http://gettys.wordpress.com/</a></span></address> |
3043 | | <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:JeffMogul@acm.org"><span class="email">JeffMogul@acm.org</span></a></span></address> |
3044 | | <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:henrikn@microsoft.com"><span class="email">henrikn@microsoft.com</span></a></span></address> |
3045 | | <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:LMM@acm.org"><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address> |
3046 | | <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">Email: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address> |
3047 | | <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address> |
3048 | | <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span> |
3049 | | (editor) |
3050 | | <span class="n hidden"><span class="family-name">Lafon</span><span class="given-name">Yves</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">W3C / ERCIM</span><span class="street-address vcardline">2004, rte des Lucioles</span><span class="vcardline"><span class="locality">Sophia-Antipolis</span>, <span class="region">AM</span> <span class="postal-code">06902</span></span><span class="country-name vcardline">France</span></span><span class="vcardline">Email: <a href="mailto:ylafon@w3.org"><span class="email">ylafon@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.raubacapeu.net/people/yves/" class="url">http://www.raubacapeu.net/people/yves/</a></span></address> |
3051 | | <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span> |
3052 | | (editor) |
3053 | | <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> |
3054 | | </div> |
3055 | | <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> |
3056 | | <p id="rfc.section.A.p.1">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) |
3057 | | </p> |
3058 | | <p id="rfc.section.A.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 6.5</a>) |
3059 | | </p> |
3060 | | <p id="rfc.section.A.p.3">Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (<a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section 6.6</a>) |
3061 | | </p> |
3062 | | <p id="rfc.section.A.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 6.9</a>) |
3063 | | </p> |
3064 | | <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.2.4</a>) |
3065 | | </p> |
3066 | | <p id="rfc.section.A.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" title="Redirection 3xx">Section 7.3</a>) |
3067 | | </p> |
3068 | | <p id="rfc.section.A.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the |
3069 | | user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite |
3070 | | the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">7.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.3.7</a>) |
3071 | | </p> |
3072 | | <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource |
3073 | | must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient |
3074 | | was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.3.5</a>) |
3075 | | </p> |
3076 | | <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.4.15</a>) |
3077 | | </p> |
3078 | | <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 10</a>) |
3079 | | </p> |
3080 | | <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement |
3081 | | on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 10.1</a>) |
3082 | | </p> |
3083 | | <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified |
3084 | | (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 10.3</a>) |
3085 | | </p> |
3086 | | <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred |
3087 | | symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. |
3088 | | (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 10.5</a>) |
3089 | | </p> |
3090 | | <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 10.6</a>) |
3091 | | </p> |
3092 | | <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 10.7</a>) |
3093 | | </p> |
3094 | | <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated |
3095 | | correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>) |
3096 | | </p> |
3097 | | <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> |
3098 | | <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] |
3099 | | |
3100 | | <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 3.2.1> |
3101 | | |
3102 | | <a href="#header.date" class="smpl">Date</a> = HTTP-date |
3103 | | |
3104 | | <a href="#header.expect" class="smpl">Expect</a> = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
3105 | | |
3106 | | <a href="#header.from" class="smpl">From</a> = mailbox |
3107 | | |
3108 | | <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT |
3109 | | |
3110 | | <a href="#http.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date |
3111 | | |
3112 | | <a href="#header.location" class="smpl">Location</a> = URI-reference |
3113 | | |
3114 | | <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT |
3115 | | <a href="#method" class="smpl">Method</a> = token |
3116 | | |
3117 | | <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2.1> |
3118 | | |
3119 | | <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in [Part1], Section 3.2.1> |
3120 | | <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( HTAB / SP / VCHAR / obs-text ) |
3121 | | <a href="#header.referer" class="smpl">Referer</a> = absolute-URI / partial-URI |
3122 | | <a href="#header.retry-after" class="smpl">Retry-After</a> = HTTP-date / delta-seconds |
3123 | | |
3124 | | <a href="#header.server" class="smpl">Server</a> = product *( RWS ( product / comment ) ) |
3125 | | <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3DIGIT |
3126 | | |
3127 | | <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in [Part1], Section 2.7> |
3128 | | <a href="#header.user-agent" class="smpl">User-Agent</a> = product *( RWS ( product / comment ) ) |
3129 | | |
3130 | | <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in [Part1], Section 2.7> |
3131 | | <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = day-name SP date3 SP time-of-day SP year |
3132 | | |
3133 | | <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in [Part1], Section 3.2.4> |
3134 | | |
3135 | | <a href="#obsolete.date.formats" class="smpl">date1</a> = day SP month SP year |
3136 | | <a href="#obsolete.date.formats" class="smpl">date2</a> = day "-" month "-" 2DIGIT |
3137 | | <a href="#obsolete.date.formats" class="smpl">date3</a> = month SP ( 2DIGIT / ( SP DIGIT ) ) |
3138 | | <a href="#preferred.date.format" class="smpl">day</a> = 2DIGIT |
3139 | | <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; Mon |
3140 | | / %x54.75.65 ; Tue |
3141 | | / %x57.65.64 ; Wed |
3142 | | / %x54.68.75 ; Thu |
3143 | | / %x46.72.69 ; Fri |
3144 | | / %x53.61.74 ; Sat |
3145 | | / %x53.75.6E ; Sun |
3146 | | <a href="#obsolete.date.formats" class="smpl">day-name-l</a> = %x4D.6F.6E.64.61.79 ; Monday |
3147 | | / %x54.75.65.73.64.61.79 ; Tuesday |
3148 | | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
3149 | | / %x54.68.75.72.73.64.61.79 ; Thursday |
3150 | | / %x46.72.69.64.61.79 ; Friday |
3151 | | / %x53.61.74.75.72.64.61.79 ; Saturday |
3152 | | / %x53.75.6E.64.61.79 ; Sunday |
3153 | | <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT |
3154 | | |
3155 | | <a href="#header.expect" class="smpl">expect-name</a> = token |
3156 | | <a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ] |
3157 | | <a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string |
3158 | | <a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ |
3159 | | OWS expect-param ] ) |
3160 | | |
3161 | | <a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT |
3162 | | |
3163 | | <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in [RFC5322], Section 3.4> |
3164 | | <a href="#preferred.date.format" class="smpl">minute</a> = 2DIGIT |
3165 | | <a href="#preferred.date.format" class="smpl">month</a> = %x4A.61.6E ; Jan |
3166 | | / %x46.65.62 ; Feb |
3167 | | / %x4D.61.72 ; Mar |
3168 | | / %x41.70.72 ; Apr |
3169 | | / %x4D.61.79 ; May |
3170 | | / %x4A.75.6E ; Jun |
3171 | | / %x4A.75.6C ; Jul |
3172 | | / %x41.75.67 ; Aug |
3173 | | / %x53.65.70 ; Sep |
3174 | | / %x4F.63.74 ; Oct |
3175 | | / %x4E.6F.76 ; Nov |
3176 | | / %x44.65.63 ; Dec |
3177 | | |
3178 | | <a href="#obsolete.date.formats" class="smpl">obs-date</a> = rfc850-date / asctime-date |
3179 | | <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in [Part1], Section 3.2.4> |
3180 | | |
3181 | | <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.7> |
3182 | | <a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ] |
3183 | | <a href="#product.tokens" class="smpl">product-version</a> = token |
3184 | | |
3185 | | <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2.4> |
3186 | | |
3187 | | <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT |
3188 | | <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT |
3189 | | |
3190 | | <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT |
3191 | | |
3192 | | <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second |
3193 | | <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.4> |
3194 | | |
3195 | | <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT |
3196 | | </pre> <div id="rfc.figure.u.39"></div> |
3197 | | <p>ABNF diagnostics:</p><pre class="inline">; Allow defined but not used |
3198 | | ; Date defined but not used |
3199 | | ; Expect defined but not used |
3200 | | ; From defined but not used |
3201 | | ; Location defined but not used |
3202 | | ; Max-Forwards defined but not used |
3203 | | ; Reason-Phrase defined but not used |
3204 | | ; Referer defined but not used |
3205 | | ; Retry-After defined but not used |
3206 | | ; Server defined but not used |
3207 | | ; Status-Code defined but not used |
3208 | | ; User-Agent defined but not used |
3209 | | </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> |
3210 | | <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 |
3211 | | </h2> |
3212 | | <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. |
3213 | | </p> |
3214 | | <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p2-semantics-00 |
3215 | | </h2> |
3216 | | <p id="rfc.section.C.2.p.1">Closed issues: </p> |
3217 | | <ul> |
3218 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/5">http://tools.ietf.org/wg/httpbis/trac/ticket/5</a>>: "Via is a MUST" (<<a href="http://purl.org/NET/http-errata#via-must">http://purl.org/NET/http-errata#via-must</a>>) |
3219 | | </li> |
3220 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/6">http://tools.ietf.org/wg/httpbis/trac/ticket/6</a>>: "Fragments allowed in Location" (<<a href="http://purl.org/NET/http-errata#location-fragments">http://purl.org/NET/http-errata#location-fragments</a>>) |
3221 | | </li> |
3222 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/10">http://tools.ietf.org/wg/httpbis/trac/ticket/10</a>>: "Safe Methods vs Redirection" (<<a href="http://purl.org/NET/http-errata#saferedirect">http://purl.org/NET/http-errata#saferedirect</a>>) |
3223 | | </li> |
3224 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/17">http://tools.ietf.org/wg/httpbis/trac/ticket/17</a>>: "Revise description of the POST method" (<<a href="http://purl.org/NET/http-errata#post">http://purl.org/NET/http-errata#post</a>>) |
3225 | | </li> |
3226 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/35">http://tools.ietf.org/wg/httpbis/trac/ticket/35</a>>: "Normative and Informative references" |
3227 | | </li> |
3228 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/42">http://tools.ietf.org/wg/httpbis/trac/ticket/42</a>>: "RFC2606 Compliance" |
3229 | | </li> |
3230 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/65">http://tools.ietf.org/wg/httpbis/trac/ticket/65</a>>: "Informative references" |
3231 | | </li> |
3232 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/84">http://tools.ietf.org/wg/httpbis/trac/ticket/84</a>>: "Redundant cross-references" |
3233 | | </li> |
3234 | | </ul> |
3235 | | <p id="rfc.section.C.2.p.2">Other changes: </p> |
3236 | | <ul> |
3237 | | <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> |
3238 | | </li> |
3239 | | </ul> |
3240 | | <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a> Since draft-ietf-httpbis-p2-semantics-01 |
3241 | | </h2> |
3242 | | <p id="rfc.section.C.3.p.1">Closed issues: </p> |
3243 | | <ul> |
3244 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/21">http://tools.ietf.org/wg/httpbis/trac/ticket/21</a>>: "PUT side effects" |
3245 | | </li> |
3246 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/91">http://tools.ietf.org/wg/httpbis/trac/ticket/91</a>>: "Duplicate Host header requirements" |
3247 | | </li> |
3248 | | </ul> |
3249 | | <p id="rfc.section.C.3.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
3250 | | </p> |
3251 | | <ul> |
3252 | | <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li> |
3253 | | <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> |
3254 | | <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li> |
3255 | | </ul> |
3256 | | <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p2-semantics-02</a></h2> |
3257 | | <p id="rfc.section.C.4.p.1">Closed issues: </p> |
3258 | | <ul> |
3259 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/24">http://tools.ietf.org/wg/httpbis/trac/ticket/24</a>>: "Requiring Allow in 405 responses" |
3260 | | </li> |
3261 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/59">http://tools.ietf.org/wg/httpbis/trac/ticket/59</a>>: "Status Code Registry" |
3262 | | </li> |
3263 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/61">http://tools.ietf.org/wg/httpbis/trac/ticket/61</a>>: "Redirection vs. Location" |
3264 | | </li> |
3265 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/70">http://tools.ietf.org/wg/httpbis/trac/ticket/70</a>>: "Cacheability of 303 response" |
3266 | | </li> |
3267 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/76">http://tools.ietf.org/wg/httpbis/trac/ticket/76</a>>: "305 Use Proxy" |
3268 | | </li> |
3269 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header" |
3270 | | </li> |
3271 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>>: "PUT - 'store under' vs 'store at'" |
3272 | | </li> |
3273 | | </ul> |
3274 | | <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): |
3275 | | </p> |
3276 | | <ul> |
3277 | | <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> |
3278 | | </ul> |
3279 | | <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
3280 | | </p> |
3281 | | <ul> |
3282 | | <li>Replace string literals when the string really is case-sensitive (method).</li> |
3283 | | </ul> |
3284 | | <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></h2> |
3285 | | <p id="rfc.section.C.5.p.1">Closed issues: </p> |
3286 | | <ul> |
3287 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/98">http://tools.ietf.org/wg/httpbis/trac/ticket/98</a>>: "OPTIONS request bodies" |
3288 | | </li> |
3289 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/119">http://tools.ietf.org/wg/httpbis/trac/ticket/119</a>>: "Description of CONNECT should refer to RFC2817" |
3290 | | </li> |
3291 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/125">http://tools.ietf.org/wg/httpbis/trac/ticket/125</a>>: "Location Content-Location reference request/response mixup" |
3292 | | </li> |
3293 | | </ul> |
3294 | | <p id="rfc.section.C.5.p.2">Ongoing work on Method Registry (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/72">http://tools.ietf.org/wg/httpbis/trac/ticket/72</a>>): |
3295 | | </p> |
3296 | | <ul> |
3297 | | <li>Added initial proposal for registration process, plus initial content (non-HTTP/1.1 methods to be added by a separate specification).</li> |
3298 | | </ul> |
3299 | | <h2 id="rfc.section.C.6"><a href="#rfc.section.C.6">C.6</a> <a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-p2-semantics-04</a></h2> |
3300 | | <p id="rfc.section.C.6.p.1">Closed issues: </p> |
3301 | | <ul> |
3302 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/103">http://tools.ietf.org/wg/httpbis/trac/ticket/103</a>>: "Content-*" |
3303 | | </li> |
3304 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/132">http://tools.ietf.org/wg/httpbis/trac/ticket/132</a>>: "RFC 2822 is updated by RFC 5322" |
3305 | | </li> |
3306 | | </ul> |
3307 | | <p id="rfc.section.C.6.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
3308 | | </p> |
3309 | | <ul> |
3310 | | <li>Use "/" instead of "|" for alternatives.</li> |
3311 | | <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li> |
3312 | | <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li> |
3313 | | </ul> |
3314 | | <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p2-semantics-05</a></h2> |
3315 | | <p id="rfc.section.C.7.p.1">Closed issues: </p> |
3316 | | <ul> |
3317 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/94">http://tools.ietf.org/wg/httpbis/trac/ticket/94</a>>: "Reason-Phrase BNF" |
3318 | | </li> |
3319 | | </ul> |
3320 | | <p id="rfc.section.C.7.p.2">Final work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
3321 | | </p> |
3322 | | <ul> |
3323 | | <li>Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.</li> |
3324 | | </ul> |
3325 | | <h2 id="rfc.section.C.8"><a href="#rfc.section.C.8">C.8</a> <a id="changes.since.06" href="#changes.since.06">Since draft-ietf-httpbis-p2-semantics-06</a></h2> |
3326 | | <p id="rfc.section.C.8.p.1">Closed issues: </p> |
3327 | | <ul> |
3328 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/144">http://tools.ietf.org/wg/httpbis/trac/ticket/144</a>>: "Clarify when Referer is sent" |
3329 | | </li> |
3330 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/164">http://tools.ietf.org/wg/httpbis/trac/ticket/164</a>>: "status codes vs methods" |
3331 | | </li> |
3332 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/170">http://tools.ietf.org/wg/httpbis/trac/ticket/170</a>>: "Do not require "updates" relation for specs that register status codes or method names" |
3333 | | </li> |
3334 | | </ul> |
3335 | | <h2 id="rfc.section.C.9"><a href="#rfc.section.C.9">C.9</a> <a id="changes.since.07" href="#changes.since.07">Since draft-ietf-httpbis-p2-semantics-07</a></h2> |
3336 | | <p id="rfc.section.C.9.p.1">Closed issues: </p> |
3337 | | <ul> |
3338 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/27">http://tools.ietf.org/wg/httpbis/trac/ticket/27</a>>: "Idempotency" |
3339 | | </li> |
3340 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/33">http://tools.ietf.org/wg/httpbis/trac/ticket/33</a>>: "TRACE security considerations" |
3341 | | </li> |
3342 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/110">http://tools.ietf.org/wg/httpbis/trac/ticket/110</a>>: "Clarify rules for determining what entities a response carries" |
3343 | | </li> |
3344 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/140">http://tools.ietf.org/wg/httpbis/trac/ticket/140</a>>: "update note citing RFC 1945 and 2068" |
3345 | | </li> |
3346 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/182">http://tools.ietf.org/wg/httpbis/trac/ticket/182</a>>: "update note about redirect limit" |
3347 | | </li> |
3348 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/191">http://tools.ietf.org/wg/httpbis/trac/ticket/191</a>>: "Location header ABNF should use 'URI'" |
3349 | | </li> |
3350 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/192">http://tools.ietf.org/wg/httpbis/trac/ticket/192</a>>: "fragments in Location vs status 303" |
3351 | | </li> |
3352 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/198">http://tools.ietf.org/wg/httpbis/trac/ticket/198</a>>: "move IANA registrations for optional status codes" |
3353 | | </li> |
3354 | | </ul> |
3355 | | <p id="rfc.section.C.9.p.2">Partly resolved issues: </p> |
3356 | | <ul> |
3357 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/171">http://tools.ietf.org/wg/httpbis/trac/ticket/171</a>>: "Are OPTIONS and TRACE safe?" |
3358 | | </li> |
3359 | | </ul> |
3360 | | <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a> <a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p2-semantics-08</a></h2> |
3361 | | <p id="rfc.section.C.10.p.1">Closed issues: </p> |
3362 | | <ul> |
3363 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/10">http://tools.ietf.org/wg/httpbis/trac/ticket/10</a>>: "Safe Methods vs Redirection" (we missed the introduction to the 3xx status codes when fixing this previously) |
3364 | | </li> |
3365 | | </ul> |
3366 | | <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a> <a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p2-semantics-09</a></h2> |
3367 | | <p id="rfc.section.C.11.p.1">Closed issues: </p> |
3368 | | <ul> |
3369 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/43">http://tools.ietf.org/wg/httpbis/trac/ticket/43</a>>: "Fragment combination / precedence during redirects" |
3370 | | </li> |
3371 | | </ul> |
3372 | | <p id="rfc.section.C.11.p.2">Partly resolved issues: </p> |
3373 | | <ul> |
3374 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header payload handling" |
3375 | | </li> |
3376 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" |
3377 | | </li> |
3378 | | </ul> |
3379 | | <h2 id="rfc.section.C.12"><a href="#rfc.section.C.12">C.12</a> <a id="changes.since.10" href="#changes.since.10">Since draft-ietf-httpbis-p2-semantics-10</a></h2> |
3380 | | <p id="rfc.section.C.12.p.1">Closed issues: </p> |
3381 | | <ul> |
3382 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/69">http://tools.ietf.org/wg/httpbis/trac/ticket/69</a>>: "Clarify 'Requested Variant'" |
3383 | | </li> |
3384 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>>: "Clarify entity / representation / variant terminology" |
3385 | | </li> |
3386 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/139">http://tools.ietf.org/wg/httpbis/trac/ticket/139</a>>: "Methods and Caching" |
3387 | | </li> |
3388 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/190">http://tools.ietf.org/wg/httpbis/trac/ticket/190</a>>: "OPTIONS vs Max-Forwards" |
3389 | | </li> |
3390 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/199">http://tools.ietf.org/wg/httpbis/trac/ticket/199</a>>: "Status codes and caching" |
3391 | | </li> |
3392 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "consider removing the 'changes from 2068' sections" |
3393 | | </li> |
3394 | | </ul> |
3395 | | <h2 id="rfc.section.C.13"><a href="#rfc.section.C.13">C.13</a> <a id="changes.since.11" href="#changes.since.11">Since draft-ietf-httpbis-p2-semantics-11</a></h2> |
3396 | | <p id="rfc.section.C.13.p.1">Closed issues: </p> |
3397 | | <ul> |
3398 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/229">http://tools.ietf.org/wg/httpbis/trac/ticket/229</a>>: "Considerations for new status codes" |
3399 | | </li> |
3400 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/230">http://tools.ietf.org/wg/httpbis/trac/ticket/230</a>>: "Considerations for new methods" |
3401 | | </li> |
3402 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/232">http://tools.ietf.org/wg/httpbis/trac/ticket/232</a>>: "User-Agent guidelines" (relating to the 'User-Agent' header field) |
3403 | | </li> |
3404 | | </ul> |
3405 | | <h2 id="rfc.section.C.14"><a href="#rfc.section.C.14">C.14</a> <a id="changes.since.12" href="#changes.since.12">Since draft-ietf-httpbis-p2-semantics-12</a></h2> |
3406 | | <p id="rfc.section.C.14.p.1">Closed issues: </p> |
3407 | | <ul> |
3408 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/43">http://tools.ietf.org/wg/httpbis/trac/ticket/43</a>>: "Fragment combination / precedence during redirects" (added warning about having a fragid on the redirect may cause inconvenience |
3409 | | in some cases) |
3410 | | </li> |
3411 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/79">http://tools.ietf.org/wg/httpbis/trac/ticket/79</a>>: "Content-* vs. PUT" |
3412 | | </li> |
3413 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>>: "205 Bodies" |
3414 | | </li> |
3415 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/102">http://tools.ietf.org/wg/httpbis/trac/ticket/102</a>>: "Understanding Content-* on non-PUT requests" |
3416 | | </li> |
3417 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/103">http://tools.ietf.org/wg/httpbis/trac/ticket/103</a>>: "Content-*" |
3418 | | </li> |
3419 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/104">http://tools.ietf.org/wg/httpbis/trac/ticket/104</a>>: "Header type defaulting" |
3420 | | </li> |
3421 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>>: "PUT - 'store under' vs 'store at'" |
3422 | | </li> |
3423 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/137">http://tools.ietf.org/wg/httpbis/trac/ticket/137</a>>: "duplicate ABNF for Reason-Phrase" |
3424 | | </li> |
3425 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/180">http://tools.ietf.org/wg/httpbis/trac/ticket/180</a>>: "Note special status of Content-* prefix in header registration procedures" |
3426 | | </li> |
3427 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/203">http://tools.ietf.org/wg/httpbis/trac/ticket/203</a>>: "Max-Forwards vs extension methods" |
3428 | | </li> |
3429 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/213">http://tools.ietf.org/wg/httpbis/trac/ticket/213</a>>: "What is the value space of HTTP status codes?" (actually fixed in draft-ietf-httpbis-p2-semantics-11) |
3430 | | </li> |
3431 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification" |
3432 | | </li> |
3433 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/225">http://tools.ietf.org/wg/httpbis/trac/ticket/225</a>>: "PUT side effect: invalidation or just stale?" |
3434 | | </li> |
3435 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/226">http://tools.ietf.org/wg/httpbis/trac/ticket/226</a>>: "proxies not supporting certain methods" |
3436 | | </li> |
3437 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/239">http://tools.ietf.org/wg/httpbis/trac/ticket/239</a>>: "Migrate CONNECT from RFC2817 to p2" |
3438 | | </li> |
3439 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/240">http://tools.ietf.org/wg/httpbis/trac/ticket/240</a>>: "Migrate Upgrade details from RFC2817" |
3440 | | </li> |
3441 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/267">http://tools.ietf.org/wg/httpbis/trac/ticket/267</a>>: "clarify PUT semantics'" |
3442 | | </li> |
3443 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/275">http://tools.ietf.org/wg/httpbis/trac/ticket/275</a>>: "duplicate ABNF for 'Method'" |
3444 | | </li> |
3445 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" |
3446 | | </li> |
3447 | | </ul> |
3448 | | <h2 id="rfc.section.C.15"><a href="#rfc.section.C.15">C.15</a> <a id="changes.since.13" href="#changes.since.13">Since draft-ietf-httpbis-p2-semantics-13</a></h2> |
3449 | | <p id="rfc.section.C.15.p.1">Closed issues: </p> |
3450 | | <ul> |
3451 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" |
3452 | | </li> |
3453 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>>: "message body in CONNECT request" |
3454 | | </li> |
3455 | | </ul> |
3456 | | <h2 id="rfc.section.C.16"><a href="#rfc.section.C.16">C.16</a> <a id="changes.since.14" href="#changes.since.14">Since draft-ietf-httpbis-p2-semantics-14</a></h2> |
3457 | | <p id="rfc.section.C.16.p.1">Closed issues: </p> |
3458 | | <ul> |
3459 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>>: "Clarify status code for rate limiting" |
3460 | | </li> |
3461 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/294">http://tools.ietf.org/wg/httpbis/trac/ticket/294</a>>: "clarify 403 forbidden" |
3462 | | </li> |
3463 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/296">http://tools.ietf.org/wg/httpbis/trac/ticket/296</a>>: "Clarify 203 Non-Authoritative Information" |
3464 | | </li> |
3465 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/298">http://tools.ietf.org/wg/httpbis/trac/ticket/298</a>>: "update default reason phrase for 413" |
3466 | | </li> |
3467 | | </ul> |
3468 | | <h2 id="rfc.section.C.17"><a href="#rfc.section.C.17">C.17</a> <a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p2-semantics-15</a></h2> |
3469 | | <p id="rfc.section.C.17.p.1">Closed issues: </p> |
3470 | | <ul> |
3471 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>>: "Strength of requirements on Accept re: 406" |
3472 | | </li> |
3473 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/303">http://tools.ietf.org/wg/httpbis/trac/ticket/303</a>>: "400 response isn't generic" |
3474 | | </li> |
3475 | | </ul> |
3476 | | <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p2-semantics-16</a></h2> |
3477 | | <p id="rfc.section.C.18.p.1">Closed issues: </p> |
3478 | | <ul> |
3479 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/160">http://tools.ietf.org/wg/httpbis/trac/ticket/160</a>>: "Redirects and non-GET methods" |
3480 | | </li> |
3481 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" |
3482 | | </li> |
3483 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>>: "Considerations for new headers" |
3484 | | </li> |
3485 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>>: "clarify 303 redirect on HEAD" |
3486 | | </li> |
3487 | | </ul> |
3488 | | <h2 id="rfc.section.C.19"><a href="#rfc.section.C.19">C.19</a> <a id="changes.since.17" href="#changes.since.17">Since draft-ietf-httpbis-p2-semantics-17</a></h2> |
3489 | | <p id="rfc.section.C.19.p.1">Closed issues: </p> |
3490 | | <ul> |
3491 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header payload handling" |
3492 | | </li> |
3493 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>>: "Clarify status code for rate limiting" (change backed out because a new status code is being defined for this purpose) |
3494 | | </li> |
3495 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/312">http://tools.ietf.org/wg/httpbis/trac/ticket/312</a>>: "should there be a permanent variant of 307" |
3496 | | </li> |
3497 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/325">http://tools.ietf.org/wg/httpbis/trac/ticket/325</a>>: "When are Location's semantics triggered?" |
3498 | | </li> |
3499 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/327">http://tools.ietf.org/wg/httpbis/trac/ticket/327</a>>: "'expect' grammar missing OWS" |
3500 | | </li> |
3501 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/329">http://tools.ietf.org/wg/httpbis/trac/ticket/329</a>>: "header field considerations: quoted-string vs use of double quotes" |
3502 | | </li> |
3503 | | </ul> |
3504 | | <h2 id="rfc.section.C.20"><a href="#rfc.section.C.20">C.20</a> <a id="changes.since.18" href="#changes.since.18">Since draft-ietf-httpbis-p2-semantics-18</a></h2> |
3505 | | <p id="rfc.section.C.20.p.1">Closed issues: </p> |
3506 | | <ul> |
3507 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/238">http://tools.ietf.org/wg/httpbis/trac/ticket/238</a>>: "Requirements for user intervention during redirects" |
3508 | | </li> |
3509 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/295">http://tools.ietf.org/wg/httpbis/trac/ticket/295</a>>: "Applying original fragment to 'plain' redirected URI" |
3510 | | </li> |
3511 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/302">http://tools.ietf.org/wg/httpbis/trac/ticket/302</a>>: "Misplaced text on connection handling in p2" |
3512 | | </li> |
3513 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/332">http://tools.ietf.org/wg/httpbis/trac/ticket/332</a>>: "relax requirements on hypertext in 3/4/5xx error responses" |
3514 | | </li> |
3515 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/333">http://tools.ietf.org/wg/httpbis/trac/ticket/333</a>>: "example for 426 response should have a payload" |
3516 | | </li> |
3517 | | <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/336">http://tools.ietf.org/wg/httpbis/trac/ticket/336</a>>: "drop indirection entries for status codes" |
3518 | | </li> |
3519 | | </ul> |
3520 | | <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> |
3521 | | <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> |
3522 | | </p> |
3523 | | <div class="print2col"> |
3524 | | <ul class="ind"> |
3525 | | <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> |
3526 | | <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> |
3527 | | <li>100-continue (expect value) <a href="#rfc.iref.89"><b>10.3</b></a></li> |
3528 | | <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> |
3529 | | </ul> |
3530 | | </li> |
3531 | | <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> |
3532 | | <li>200 OK (status code) <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.24"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> |
3533 | | <li>201 Created (status code) <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.25"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li> |
3534 | | <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.26"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> |
3535 | | <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.27"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> |
3536 | | <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.28"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> |
3537 | | <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.29"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> |
3538 | | </ul> |
3539 | | </li> |
3540 | | <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> |
3541 | | <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.30"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> |
3542 | | <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.31"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A</a></li> |
3543 | | <li>302 Found (status code) <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.32"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A</a></li> |
3544 | | <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.33"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> |
3545 | | <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.34"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A</a></li> |
3546 | | <li>306 (Unused) (status code) <a href="#rfc.iref.35"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> |
3547 | | <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.36"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A</a></li> |
3548 | | </ul> |
3549 | | </li> |
3550 | | <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> |
3551 | | <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.37"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> |
3552 | | <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.38"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> |
3553 | | <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.39"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li> |
3554 | | <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.40"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li> |
3555 | | <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.41"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> |
3556 | | <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.42"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> |
3557 | | <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.43"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> |
3558 | | <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.44"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> |
3559 | | <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.45"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li> |
3560 | | <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.46"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> |
3561 | | <li>413 Request Representation Too Large (status code) <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.47"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> |
3562 | | <li>414 URI Too Long (status code) <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.48"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> |
3563 | | <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.49"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> |
3564 | | <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.50"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> |
3565 | | <li>426 Upgrade Required (status code) <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.51"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">A</a></li> |
3566 | | </ul> |
3567 | | </li> |
3568 | | <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> |
3569 | | <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> |
3570 | | <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.53"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> |
3571 | | <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.54"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> |
3572 | | <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.55"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> |
3573 | | <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.56"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li> |
3574 | | <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.57"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> |
3575 | | </ul> |
3576 | | </li> |
3577 | | <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> |
3578 | | <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.1"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> |
3579 | | </ul> |
3580 | | </li> |
3581 | | <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> |
3582 | | <li>CONNECT method <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.c.1"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li> |
3583 | | </ul> |
3584 | | </li> |
3585 | | <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> |
3586 | | <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.2"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li> |
3587 | | <li>DELETE method <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.d.1"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> |
3588 | | </ul> |
3589 | | </li> |
3590 | | <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> |
3591 | | <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.e.1"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> |
3592 | | <li>Expect Values |
3593 | | <ul> |
3594 | | <li>100-continue <a href="#rfc.iref.e.2"><b>10.3</b></a></li> |
3595 | | </ul> |
3596 | | </li> |
3597 | | </ul> |
3598 | | </li> |
3599 | | <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> |
3600 | | <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> |
3601 | | </ul> |
3602 | | </li> |
3603 | | <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> |
3604 | | <li>GET method <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.g.5"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> |
3605 | | <li><tt>Grammar</tt> |
3606 | | <ul> |
3607 | | <li><tt>Allow</tt> <a href="#rfc.iref.g.24"><b>10.1</b></a></li> |
3608 | | <li><tt>asctime-date</tt> <a href="#rfc.iref.g.21"><b>8</b></a></li> |
3609 | | <li><tt>Date</tt> <a href="#rfc.iref.g.25"><b>10.2</b></a></li> |
3610 | | <li><tt>date1</tt> <a href="#rfc.iref.g.8"><b>8</b></a></li> |
3611 | | <li><tt>day</tt> <a href="#rfc.iref.g.15"><b>8</b></a></li> |
3612 | | <li><tt>day-name</tt> <a href="#rfc.iref.g.13"><b>8</b></a></li> |
3613 | | <li><tt>day-name-l</tt> <a href="#rfc.iref.g.14"><b>8</b></a></li> |
3614 | | <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.36"><b>10.8</b></a></li> |
3615 | | <li><tt>Expect</tt> <a href="#rfc.iref.g.26"><b>10.3</b></a></li> |
3616 | | <li><tt>expect-name</tt> <a href="#rfc.iref.g.30"><b>10.3</b></a></li> |
3617 | | <li><tt>expect-param</tt> <a href="#rfc.iref.g.28"><b>10.3</b></a></li> |
3618 | | <li><tt>expect-value</tt> <a href="#rfc.iref.g.29"><b>10.3</b></a></li> |
3619 | | <li><tt>expectation</tt> <a href="#rfc.iref.g.27"><b>10.3</b></a></li> |
3620 | | <li><tt>extension-code</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> |
3621 | | <li><tt>From</tt> <a href="#rfc.iref.g.31"><b>10.4</b></a></li> |
3622 | | <li><tt>GMT</tt> <a href="#rfc.iref.g.18"><b>8</b></a></li> |
3623 | | <li><tt>hour</tt> <a href="#rfc.iref.g.10"><b>8</b></a></li> |
3624 | | <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.6"><b>8</b></a></li> |
3625 | | <li><tt>Location</tt> <a href="#rfc.iref.g.32"><b>10.5</b></a></li> |
3626 | | <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.33"><b>10.6</b></a></li> |
3627 | | <li><tt>Method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> |
3628 | | <li><tt>minute</tt> <a href="#rfc.iref.g.11"><b>8</b></a></li> |
3629 | | <li><tt>month</tt> <a href="#rfc.iref.g.16"><b>8</b></a></li> |
3630 | | <li><tt>obs-date</tt> <a href="#rfc.iref.g.19"><b>8</b></a></li> |
3631 | | <li><tt>product</tt> <a href="#rfc.iref.g.22"><b>9</b></a></li> |
3632 | | <li><tt>product-version</tt> <a href="#rfc.iref.g.23"><b>9</b></a></li> |
3633 | | <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.4"><b>4</b></a></li> |
3634 | | <li><tt>Referer</tt> <a href="#rfc.iref.g.34"><b>10.7</b></a></li> |
3635 | | <li><tt>Retry-After</tt> <a href="#rfc.iref.g.35"><b>10.8</b></a></li> |
3636 | | <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.7"><b>8</b></a></li> |
3637 | | <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.20"><b>8</b></a></li> |
3638 | | <li><tt>second</tt> <a href="#rfc.iref.g.12"><b>8</b></a></li> |
3639 | | <li><tt>Server</tt> <a href="#rfc.iref.g.37"><b>10.9</b></a></li> |
3640 | | <li><tt>Status-Code</tt> <a href="#rfc.iref.g.2"><b>4</b></a></li> |
3641 | | <li><tt>time-of-day</tt> <a href="#rfc.iref.g.9"><b>8</b></a></li> |
3642 | | <li><tt>User-Agent</tt> <a href="#rfc.iref.g.38"><b>10.10</b></a></li> |
3643 | | <li><tt>year</tt> <a href="#rfc.iref.g.17"><b>8</b></a></li> |
3644 | | </ul> |
3645 | | </li> |
3646 | | </ul> |
3647 | | </li> |
3648 | | <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> |
3649 | | <li>HEAD method <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> |
3650 | | <li>Header Fields |
3651 | | <ul> |
3652 | | <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.2"><b>10.1</b></a>, <a href="#rfc.xref.header.allow.3">11.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> |
3653 | | <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.3"><b>10.2</b></a>, <a href="#rfc.xref.header.date.2">11.3</a></li> |
3654 | | <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.14</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> |
3655 | | <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.5"><b>10.4</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> |
3656 | | <li>Location <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> |
3657 | | <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> |
3658 | | <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> |
3659 | | <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.h.9"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li> |
3660 | | <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> |
3661 | | <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><b>10.10</b></a>, <a href="#rfc.xref.header.user-agent.2">11.3</a>, <a href="#rfc.xref.header.user-agent.3">12.1</a></li> |
3662 | | </ul> |
3663 | | </li> |
3664 | | </ul> |
3665 | | </li> |
3666 | | <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> |
3667 | | <li>Idempotent Methods <a href="#rfc.iref.i.1"><b>6.1.2</b></a></li> |
3668 | | </ul> |
3669 | | </li> |
3670 | | <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> |
3671 | | <li>Location header field <a href="#rfc.xref.header.location.1">3.3</a>, <a href="#rfc.xref.header.location.2">6.5</a>, <a href="#rfc.xref.header.location.3">7.3</a>, <a href="#rfc.iref.l.1"><b>10.5</b></a>, <a href="#rfc.xref.header.location.4">11.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> |
3672 | | </ul> |
3673 | | </li> |
3674 | | <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> |
3675 | | <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">3.2</a>, <a href="#rfc.xref.header.max-forwards.2">6.2</a>, <a href="#rfc.xref.header.max-forwards.3">6.8</a>, <a href="#rfc.iref.m.9"><b>10.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">11.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> |
3676 | | <li>Methods |
3677 | | <ul> |
3678 | | <li>CONNECT <a href="#rfc.xref.CONNECT.1">2.1</a>, <a href="#rfc.iref.m.8"><b>6.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a>, <a href="#rfc.xref.CONNECT.3">A</a></li> |
3679 | | <li>DELETE <a href="#rfc.xref.DELETE.1">2.1</a>, <a href="#rfc.iref.m.6"><b>6.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> |
3680 | | <li>GET <a href="#rfc.xref.GET.1">2.1</a>, <a href="#rfc.iref.m.2"><b>6.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> |
3681 | | <li>HEAD <a href="#rfc.xref.HEAD.1">2.1</a>, <a href="#rfc.iref.m.3"><b>6.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> |
3682 | | <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.m.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> |
3683 | | <li>POST <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.m.4"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li> |
3684 | | <li>PUT <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.m.5"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li> |
3685 | | <li>TRACE <a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.m.7"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">10.6</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> |
3686 | | </ul> |
3687 | | </li> |
3688 | | </ul> |
3689 | | </li> |
3690 | | <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> |
3691 | | <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">2.1</a>, <a href="#rfc.iref.o.1"><b>6.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.6</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> |
3692 | | </ul> |
3693 | | </li> |
3694 | | <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> |
3695 | | <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.15</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">10.3</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a>, <a href="#rfc.xref.Part1.41">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.42">A</a><ul> |
3696 | | <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> |
3697 | | <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> |
3698 | | <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.33">7.2.4</a></li> |
3699 | | <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">7.5.6</a></li> |
3700 | | <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> |
3701 | | <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li> |
3702 | | <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> |
3703 | | <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.38">10.9</a>, <a href="#rfc.xref.Part1.40">10.10</a></li> |
3704 | | <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> |
3705 | | <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.18">3.1</a></li> |
3706 | | <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> |
3707 | | <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> |
3708 | | <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> |
3709 | | <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> |
3710 | | <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li> |
3711 | | <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> |
3712 | | <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.23">3.2</a></li> |
3713 | | <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li> |
3714 | | <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li> |
3715 | | <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> |
3716 | | <li><em>Section 11</em> <a href="#rfc.xref.Part1.41">13</a></li> |
3717 | | </ul> |
3718 | | </li> |
3719 | | <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">7.3</a>, <a href="#rfc.xref.Part3.11">7.3.1</a>, <a href="#rfc.xref.Part3.12">7.4.6</a>, <a href="#rfc.xref.Part3.13">10.5</a>, <a href="#Part3"><b>14.1</b></a><ul> |
3720 | | <li><em>Section 2.3</em> <a href="#rfc.xref.Part3.2">3.1</a></li> |
3721 | | <li><em>Section 5</em> <a href="#rfc.xref.Part3.11">7.3.1</a></li> |
3722 | | <li><em>Section 5.2</em> <a href="#rfc.xref.Part3.10">7.3</a></li> |
3723 | | <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.3">3.2</a></li> |
3724 | | <li><em>Section 6</em> <a href="#rfc.xref.Part3.12">7.4.6</a></li> |
3725 | | <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.4">3.2</a></li> |
3726 | | <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.5">3.2</a></li> |
3727 | | <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.6">3.2</a></li> |
3728 | | <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.13">10.5</a></li> |
3729 | | <li><em>Section 6.8</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.9">7</a></li> |
3730 | | </ul> |
3731 | | </li> |
3732 | | <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">7.2.2</a>, <a href="#rfc.xref.Part4.10">7.3</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a><ul> |
3733 | | <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">7.2.2</a></li> |
3734 | | <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> |
3735 | | <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3.2</a></li> |
3736 | | <li><em>Section 3.3</em> <a href="#rfc.xref.Part4.2">3.2</a></li> |
3737 | | <li><em>Section 3.4</em> <a href="#rfc.xref.Part4.4">3.2</a></li> |
3738 | | <li><em>Section 4</em> <a href="#rfc.xref.Part4.6">4.1</a></li> |
3739 | | <li><em>Section 4.1</em> <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.10">7.3</a></li> |
3740 | | <li><em>Section 4.2</em> <a href="#rfc.xref.Part4.8">4.1</a></li> |
3741 | | </ul> |
3742 | | </li> |
3743 | | <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.3</a>, <a href="#rfc.xref.Part5.4">4.1</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">6.3</a>, <a href="#Part5"><b>14.1</b></a><ul> |
3744 | | <li><em>Section 3</em> <a href="#rfc.xref.Part5.4">4.1</a></li> |
3745 | | <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.5">4.1</a></li> |
3746 | | <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.6">4.1</a></li> |
3747 | | <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.3">3.3</a></li> |
3748 | | <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">3.2</a></li> |
3749 | | <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.7">6.3</a></li> |
3750 | | </ul> |
3751 | | </li> |
3752 | | <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">3.1</a>, <a href="#rfc.xref.Part6.3">3.3</a>, <a href="#rfc.xref.Part6.4">3.3</a>, <a href="#rfc.xref.Part6.5">4.2.1</a>, <a href="#rfc.xref.Part6.6">6.3</a>, <a href="#rfc.xref.Part6.7">6.4</a>, <a href="#rfc.xref.Part6.8">6.5</a>, <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a>, <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.12">7.2.4</a>, <a href="#rfc.xref.Part6.13">7.2.4</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a>, <a href="#Part6"><b>14.1</b></a><ul> |
3753 | | <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.8">6.5</a></li> |
3754 | | <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">7.2.1</a>, <a href="#rfc.xref.Part6.14">7.2.4</a>, <a href="#rfc.xref.Part6.15">7.3.1</a>, <a href="#rfc.xref.Part6.16">7.3.2</a>, <a href="#rfc.xref.Part6.17">7.4.9</a></li> |
3755 | | <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.9">6.6</a>, <a href="#rfc.xref.Part6.10">6.7</a></li> |
3756 | | <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.3">3.3</a></li> |
3757 | | <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.12">7.2.4</a></li> |
3758 | | <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.4">3.3</a></li> |
3759 | | <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.13">7.2.4</a></li> |
3760 | | </ul> |
3761 | | </li> |
3762 | | <li><em>Part7</em> <a href="#rfc.xref.Part7.1">3.2</a>, <a href="#rfc.xref.Part7.2">3.2</a>, <a href="#rfc.xref.Part7.3">3.3</a>, <a href="#rfc.xref.Part7.4">3.3</a>, <a href="#rfc.xref.Part7.5">4.1</a>, <a href="#rfc.xref.Part7.6">4.1</a>, <a href="#rfc.xref.Part7.7">4.1</a>, <a href="#Part7"><b>14.1</b></a><ul> |
3763 | | <li><em>Section 3</em> <a href="#rfc.xref.Part7.5">4.1</a></li> |
3764 | | <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.6">4.1</a></li> |
3765 | | <li><em>Section 3.2</em> <a href="#rfc.xref.Part7.7">4.1</a></li> |
3766 | | <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">3.2</a></li> |
3767 | | <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.3">3.3</a></li> |
3768 | | <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.2">3.2</a></li> |
3769 | | <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.4">3.3</a></li> |
3770 | | </ul> |
3771 | | </li> |
3772 | | <li>POST method <a href="#rfc.xref.POST.1">2.1</a>, <a href="#rfc.iref.p.1"><b>6.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A</a></li> |
3773 | | <li>PUT method <a href="#rfc.xref.PUT.1">2.1</a>, <a href="#rfc.iref.p.2"><b>6.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a>, <a href="#rfc.xref.PUT.3">A</a></li> |
3774 | | </ul> |
3775 | | </li> |
3776 | | <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> |
3777 | | <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>10.7</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> |
3778 | | <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">7.5.4</a>, <a href="#rfc.iref.r.2"><b>10.8</b></a>, <a href="#rfc.xref.header.retry-after.3">11.3</a></li> |
3779 | | <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">8</a>, <a href="#rfc.xref.RFC1123.2">8</a>, <a href="#RFC1123"><b>14.2</b></a><ul> |
3780 | | <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">8</a></li> |
3781 | | </ul> |
3782 | | </li> |
3783 | | <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">7.3</a>, <a href="#RFC1945"><b>14.2</b></a><ul> |
3784 | | <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">7.3</a></li> |
3785 | | </ul> |
3786 | | </li> |
3787 | | <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">7.3</a>, <a href="#rfc.xref.RFC2068.2">7.3</a>, <a href="#RFC2068"><b>14.2</b></a><ul> |
3788 | | <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">7.3</a></li> |
3789 | | <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">7.3</a></li> |
3790 | | </ul> |
3791 | | </li> |
3792 | | <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>14.1</b></a></li> |
3793 | | <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7.3</a>, <a href="#RFC2616"><b>14.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a><ul> |
3794 | | <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">7.3</a></li> |
3795 | | </ul> |
3796 | | </li> |
3797 | | <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#RFC2817"><b>14.2</b></a>, <a href="#rfc.xref.RFC2817.2">A</a>, <a href="#rfc.xref.RFC2817.3">A</a>, <a href="#rfc.xref.RFC2817.4">A</a><ul> |
3798 | | <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">11.2</a>, <a href="#rfc.xref.RFC2817.2">A</a></li> |
3799 | | </ul> |
3800 | | </li> |
3801 | | <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">11.3</a>, <a href="#RFC3864"><b>14.2</b></a><ul> |
3802 | | <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> |
3803 | | </ul> |
3804 | | </li> |
3805 | | <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">10.5</a>, <a href="#rfc.xref.RFC3986.2">10.5</a>, <a href="#RFC3986"><b>14.1</b></a><ul> |
3806 | | <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">10.5</a></li> |
3807 | | <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">10.5</a></li> |
3808 | | </ul> |
3809 | | </li> |
3810 | | <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#RFC5226"><b>14.2</b></a><ul> |
3811 | | <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a></li> |
3812 | | </ul> |
3813 | | </li> |
3814 | | <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#rfc.xref.RFC5234.3">3.1</a>, <a href="#RFC5234"><b>14.1</b></a><ul> |
3815 | | <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> |
3816 | | </ul> |
3817 | | </li> |
3818 | | <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">8</a>, <a href="#rfc.xref.RFC5322.2">10.2</a>, <a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a>, <a href="#RFC5322"><b>14.2</b></a><ul> |
3819 | | <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">8</a></li> |
3820 | | <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">10.4</a>, <a href="#rfc.xref.RFC5322.4">10.4</a></li> |
3821 | | <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">10.2</a></li> |
3822 | | </ul> |
3823 | | </li> |
3824 | | <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">6.6</a>, <a href="#RFC5789"><b>14.2</b></a></li> |
3825 | | <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>14.2</b></a></li> |
3826 | | </ul> |
3827 | | </li> |
3828 | | <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> |
3829 | | <li>Safe Methods <a href="#rfc.iref.s.1"><b>6.1.1</b></a></li> |
3830 | | <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.38"><b>10.9</b></a>, <a href="#rfc.xref.header.server.2">11.3</a>, <a href="#rfc.xref.header.server.3">12.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> |
3831 | | <li>Status Codes |
3832 | | <ul> |
3833 | | <li>100 Continue <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.s.2"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> |
3834 | | <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.s.3"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> |
3835 | | <li>200 OK <a href="#rfc.xref.status.200.1">4.1</a>, <a href="#rfc.iref.s.4"><b>7.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> |
3836 | | <li>201 Created <a href="#rfc.xref.status.201.1">4.1</a>, <a href="#rfc.iref.s.5"><b>7.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a></li> |
3837 | | <li>202 Accepted <a href="#rfc.xref.status.202.1">4.1</a>, <a href="#rfc.iref.s.6"><b>7.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> |
3838 | | <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">4.1</a>, <a href="#rfc.iref.s.7"><b>7.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a>, <a href="#rfc.xref.status.203.3">A</a></li> |
3839 | | <li>204 No Content <a href="#rfc.xref.status.204.1">4.1</a>, <a href="#rfc.iref.s.8"><b>7.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> |
3840 | | <li>205 Reset Content <a href="#rfc.xref.status.205.1">4.1</a>, <a href="#rfc.iref.s.9"><b>7.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> |
3841 | | <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">4.1</a>, <a href="#rfc.iref.s.10"><b>7.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> |
3842 | | <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">4.1</a>, <a href="#rfc.iref.s.11"><b>7.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A</a></li> |
3843 | | <li>302 Found <a href="#rfc.xref.status.302.1">4.1</a>, <a href="#rfc.iref.s.12"><b>7.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A</a></li> |
3844 | | <li>303 See Other <a href="#rfc.xref.status.303.1">4.1</a>, <a href="#rfc.iref.s.13"><b>7.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> |
3845 | | <li>305 Use Proxy <a href="#rfc.xref.status.305.1">4.1</a>, <a href="#rfc.iref.s.14"><b>7.3.5</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A</a></li> |
3846 | | <li>306 (Unused) <a href="#rfc.iref.s.15"><b>7.3.6</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> |
3847 | | <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">4.1</a>, <a href="#rfc.iref.s.16"><b>7.3.7</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A</a></li> |
3848 | | <li>400 Bad Request <a href="#rfc.xref.status.400.1">4.1</a>, <a href="#rfc.iref.s.17"><b>7.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> |
3849 | | <li>402 Payment Required <a href="#rfc.xref.status.402.1">4.1</a>, <a href="#rfc.iref.s.18"><b>7.4.2</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> |
3850 | | <li>403 Forbidden <a href="#rfc.xref.status.403.1">4.1</a>, <a href="#rfc.iref.s.19"><b>7.4.3</b></a>, <a href="#rfc.xref.status.403.2">11.2</a></li> |
3851 | | <li>404 Not Found <a href="#rfc.xref.status.404.1">4.1</a>, <a href="#rfc.iref.s.20"><b>7.4.4</b></a>, <a href="#rfc.xref.status.404.2">11.2</a></li> |
3852 | | <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">4.1</a>, <a href="#rfc.iref.s.21"><b>7.4.5</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> |
3853 | | <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">4.1</a>, <a href="#rfc.iref.s.22"><b>7.4.6</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> |
3854 | | <li>408 Request Timeout <a href="#rfc.xref.status.408.1">4.1</a>, <a href="#rfc.iref.s.23"><b>7.4.7</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> |
3855 | | <li>409 Conflict <a href="#rfc.xref.status.409.1">4.1</a>, <a href="#rfc.iref.s.24"><b>7.4.8</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> |
3856 | | <li>410 Gone <a href="#rfc.xref.status.410.1">4.1</a>, <a href="#rfc.iref.s.25"><b>7.4.9</b></a>, <a href="#rfc.xref.status.410.2">11.2</a></li> |
3857 | | <li>411 Length Required <a href="#rfc.xref.status.411.1">4.1</a>, <a href="#rfc.iref.s.26"><b>7.4.10</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> |
3858 | | <li>413 Request Representation Too Large <a href="#rfc.xref.status.413.1">4.1</a>, <a href="#rfc.iref.s.27"><b>7.4.11</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> |
3859 | | <li>414 URI Too Long <a href="#rfc.xref.status.414.1">4.1</a>, <a href="#rfc.iref.s.28"><b>7.4.12</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> |
3860 | | <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">4.1</a>, <a href="#rfc.iref.s.29"><b>7.4.13</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> |
3861 | | <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">4.1</a>, <a href="#rfc.iref.s.30"><b>7.4.14</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> |
3862 | | <li>426 Upgrade Required <a href="#rfc.xref.status.426.1">4.1</a>, <a href="#rfc.iref.s.31"><b>7.4.15</b></a>, <a href="#rfc.xref.status.426.2">11.2</a>, <a href="#rfc.xref.status.426.3">A</a></li> |
3863 | | <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">4.1</a>, <a href="#rfc.iref.s.32"><b>7.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> |
3864 | | <li>501 Not Implemented <a href="#rfc.xref.status.501.1">4.1</a>, <a href="#rfc.iref.s.33"><b>7.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> |
3865 | | <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">4.1</a>, <a href="#rfc.iref.s.34"><b>7.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> |
3866 | | <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">4.1</a>, <a href="#rfc.iref.s.35"><b>7.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> |
3867 | | <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">4.1</a>, <a href="#rfc.iref.s.36"><b>7.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a></li> |
3868 | | <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">4.1</a>, <a href="#rfc.iref.s.37"><b>7.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> |
3869 | | </ul> |
3870 | | </li> |
3871 | | </ul> |
3872 | | </li> |
3873 | | <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> |
3874 | | <li>TRACE method <a href="#rfc.xref.TRACE.1">2.1</a>, <a href="#rfc.iref.t.1"><b>6.8</b></a>, <a href="#rfc.xref.TRACE.2">10.6</a>, <a href="#rfc.xref.TRACE.3">11.1</a>, <a href="#rfc.xref.TRACE.4">12.1</a></li> |
3875 | | </ul> |
3876 | | </li> |
3877 | | <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> |
3878 | | <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>10.10</b></a>, <a href="#rfc.xref.header.user-agent.2">11.3</a>, <a href="#rfc.xref.header.user-agent.3">12.1</a></li> |
3879 | | </ul> |
3880 | | </li> |
3881 | | </ul> |
3882 | | </div> |
3883 | | </body> |
3884 | | </html> |