| 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> |
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)