| 1 | <!DOCTYPE html |
|---|
| 2 | PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
|---|
| 3 | <html lang="en"> |
|---|
| 4 | <head profile="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><style type="text/css" title="Xml2Rfc (sans serif)"> |
|---|
| 7 | a { |
|---|
| 8 | text-decoration: none; |
|---|
| 9 | } |
|---|
| 10 | a.smpl { |
|---|
| 11 | color: black; |
|---|
| 12 | } |
|---|
| 13 | a:hover { |
|---|
| 14 | text-decoration: underline; |
|---|
| 15 | } |
|---|
| 16 | a:active { |
|---|
| 17 | text-decoration: underline; |
|---|
| 18 | } |
|---|
| 19 | address { |
|---|
| 20 | margin-top: 1em; |
|---|
| 21 | margin-left: 2em; |
|---|
| 22 | font-style: normal; |
|---|
| 23 | } |
|---|
| 24 | body { |
|---|
| 25 | color: black; |
|---|
| 26 | font-family: cambria, helvetica, arial, sans-serif; |
|---|
| 27 | font-size: 11pt; |
|---|
| 28 | margin-right: 2em; |
|---|
| 29 | } |
|---|
| 30 | cite { |
|---|
| 31 | font-style: normal; |
|---|
| 32 | } |
|---|
| 33 | dl { |
|---|
| 34 | margin-left: 2em; |
|---|
| 35 | } |
|---|
| 36 | ul.empty { |
|---|
| 37 | list-style-type: none; |
|---|
| 38 | } |
|---|
| 39 | ul.empty li { |
|---|
| 40 | margin-top: .5em; |
|---|
| 41 | } |
|---|
| 42 | dl p { |
|---|
| 43 | margin-left: 0em; |
|---|
| 44 | } |
|---|
| 45 | dt { |
|---|
| 46 | margin-top: .5em; |
|---|
| 47 | } |
|---|
| 48 | h1 { |
|---|
| 49 | font-size: 130%; |
|---|
| 50 | line-height: 21pt; |
|---|
| 51 | page-break-after: avoid; |
|---|
| 52 | } |
|---|
| 53 | h1.np { |
|---|
| 54 | page-break-before: always; |
|---|
| 55 | } |
|---|
| 56 | h2 { |
|---|
| 57 | font-size: 120%; |
|---|
| 58 | line-height: 15pt; |
|---|
| 59 | page-break-after: avoid; |
|---|
| 60 | } |
|---|
| 61 | h3 { |
|---|
| 62 | font-size: 110%; |
|---|
| 63 | page-break-after: avoid; |
|---|
| 64 | } |
|---|
| 65 | h4, h5, h6 { |
|---|
| 66 | page-break-after: avoid; |
|---|
| 67 | } |
|---|
| 68 | h1 a, h2 a, h3 a, h4 a, h5 a, h6 a { |
|---|
| 69 | color: black; |
|---|
| 70 | } |
|---|
| 71 | img { |
|---|
| 72 | margin-left: 3em; |
|---|
| 73 | } |
|---|
| 74 | li { |
|---|
| 75 | margin-left: 2em; |
|---|
| 76 | } |
|---|
| 77 | ol { |
|---|
| 78 | margin-left: 2em; |
|---|
| 79 | } |
|---|
| 80 | ol.la { |
|---|
| 81 | list-style-type: lower-alpha; |
|---|
| 82 | } |
|---|
| 83 | ol.ua { |
|---|
| 84 | list-style-type: upper-alpha; |
|---|
| 85 | } |
|---|
| 86 | ol p { |
|---|
| 87 | margin-left: 0em; |
|---|
| 88 | } |
|---|
| 89 | p { |
|---|
| 90 | margin-left: 2em; |
|---|
| 91 | } |
|---|
| 92 | pre { |
|---|
| 93 | margin-left: 3em; |
|---|
| 94 | background-color: lightyellow; |
|---|
| 95 | padding: .25em; |
|---|
| 96 | page-break-inside: avoid; |
|---|
| 97 | } |
|---|
| 98 | pre.text2 { |
|---|
| 99 | border-style: dotted; |
|---|
| 100 | border-width: 1px; |
|---|
| 101 | background-color: #f0f0f0; |
|---|
| 102 | width: 69em; |
|---|
| 103 | } |
|---|
| 104 | pre.inline { |
|---|
| 105 | background-color: white; |
|---|
| 106 | padding: 0em; |
|---|
| 107 | } |
|---|
| 108 | pre.text { |
|---|
| 109 | border-style: dotted; |
|---|
| 110 | border-width: 1px; |
|---|
| 111 | background-color: #f8f8f8; |
|---|
| 112 | width: 69em; |
|---|
| 113 | } |
|---|
| 114 | pre.drawing { |
|---|
| 115 | border-style: solid; |
|---|
| 116 | border-width: 1px; |
|---|
| 117 | background-color: #f8f8f8; |
|---|
| 118 | padding: 2em; |
|---|
| 119 | } |
|---|
| 120 | table { |
|---|
| 121 | margin-left: 2em; |
|---|
| 122 | } |
|---|
| 123 | table.tt { |
|---|
| 124 | vertical-align: top; |
|---|
| 125 | border-color: gray; |
|---|
| 126 | } |
|---|
| 127 | table.tt th { |
|---|
| 128 | border-color: gray; |
|---|
| 129 | } |
|---|
| 130 | table.tt td { |
|---|
| 131 | border-color: gray; |
|---|
| 132 | } |
|---|
| 133 | table.all { |
|---|
| 134 | border-style: solid; |
|---|
| 135 | border-width: 2px; |
|---|
| 136 | } |
|---|
| 137 | table.full { |
|---|
| 138 | border-style: solid; |
|---|
| 139 | border-width: 2px; |
|---|
| 140 | } |
|---|
| 141 | table.tt td { |
|---|
| 142 | vertical-align: top; |
|---|
| 143 | } |
|---|
| 144 | table.all td { |
|---|
| 145 | border-style: solid; |
|---|
| 146 | border-width: 1px; |
|---|
| 147 | } |
|---|
| 148 | table.full td { |
|---|
| 149 | border-style: none solid; |
|---|
| 150 | border-width: 1px; |
|---|
| 151 | } |
|---|
| 152 | table.tt th { |
|---|
| 153 | vertical-align: top; |
|---|
| 154 | } |
|---|
| 155 | table.all th { |
|---|
| 156 | border-style: solid; |
|---|
| 157 | border-width: 1px; |
|---|
| 158 | } |
|---|
| 159 | table.full th { |
|---|
| 160 | border-style: solid; |
|---|
| 161 | border-width: 1px 1px 2px 1px; |
|---|
| 162 | } |
|---|
| 163 | table.headers th { |
|---|
| 164 | border-style: none none solid none; |
|---|
| 165 | border-width: 2px; |
|---|
| 166 | } |
|---|
| 167 | table.left { |
|---|
| 168 | margin-right: auto; |
|---|
| 169 | } |
|---|
| 170 | table.right { |
|---|
| 171 | margin-left: auto; |
|---|
| 172 | } |
|---|
| 173 | table.center { |
|---|
| 174 | margin-left: auto; |
|---|
| 175 | margin-right: auto; |
|---|
| 176 | } |
|---|
| 177 | caption { |
|---|
| 178 | caption-side: bottom; |
|---|
| 179 | font-weight: bold; |
|---|
| 180 | font-size: 10pt; |
|---|
| 181 | margin-top: .5em; |
|---|
| 182 | } |
|---|
| 183 | |
|---|
| 184 | table.header { |
|---|
| 185 | border-spacing: 1px; |
|---|
| 186 | width: 95%; |
|---|
| 187 | font-size: 11pt; |
|---|
| 188 | color: white; |
|---|
| 189 | } |
|---|
| 190 | td.top { |
|---|
| 191 | vertical-align: top; |
|---|
| 192 | } |
|---|
| 193 | td.topnowrap { |
|---|
| 194 | vertical-align: top; |
|---|
| 195 | white-space: nowrap; |
|---|
| 196 | } |
|---|
| 197 | table.header td { |
|---|
| 198 | background-color: gray; |
|---|
| 199 | width: 50%; |
|---|
| 200 | } |
|---|
| 201 | table.header a { |
|---|
| 202 | color: white; |
|---|
| 203 | } |
|---|
| 204 | td.reference { |
|---|
| 205 | vertical-align: top; |
|---|
| 206 | white-space: nowrap; |
|---|
| 207 | padding-right: 1em; |
|---|
| 208 | } |
|---|
| 209 | thead { |
|---|
| 210 | display:table-header-group; |
|---|
| 211 | } |
|---|
| 212 | ul.toc, ul.toc ul { |
|---|
| 213 | list-style: none; |
|---|
| 214 | margin-left: 1.5em; |
|---|
| 215 | padding-left: 0em; |
|---|
| 216 | } |
|---|
| 217 | ul.toc li { |
|---|
| 218 | line-height: 150%; |
|---|
| 219 | font-weight: bold; |
|---|
| 220 | margin-left: 0em; |
|---|
| 221 | } |
|---|
| 222 | ul.toc li li { |
|---|
| 223 | line-height: normal; |
|---|
| 224 | font-weight: normal; |
|---|
| 225 | font-size: 10pt; |
|---|
| 226 | margin-left: 0em; |
|---|
| 227 | } |
|---|
| 228 | li.excluded { |
|---|
| 229 | font-size: 0pt; |
|---|
| 230 | } |
|---|
| 231 | ul p { |
|---|
| 232 | margin-left: 0em; |
|---|
| 233 | } |
|---|
| 234 | .title, .filename, h1, h2, h3, h4 { |
|---|
| 235 | font-family: candara, helvetica, arial, sans-serif; |
|---|
| 236 | } |
|---|
| 237 | samp, tt, code, pre { |
|---|
| 238 | font: consolas, monospace; |
|---|
| 239 | } |
|---|
| 240 | ul.ind, ul.ind ul { |
|---|
| 241 | list-style: none; |
|---|
| 242 | margin-left: 1.5em; |
|---|
| 243 | padding-left: 0em; |
|---|
| 244 | page-break-before: avoid; |
|---|
| 245 | } |
|---|
| 246 | ul.ind li { |
|---|
| 247 | font-weight: bold; |
|---|
| 248 | line-height: 200%; |
|---|
| 249 | margin-left: 0em; |
|---|
| 250 | } |
|---|
| 251 | ul.ind li li { |
|---|
| 252 | font-weight: normal; |
|---|
| 253 | line-height: 150%; |
|---|
| 254 | margin-left: 0em; |
|---|
| 255 | } |
|---|
| 256 | .avoidbreak { |
|---|
| 257 | page-break-inside: avoid; |
|---|
| 258 | } |
|---|
| 259 | .bcp14 { |
|---|
| 260 | font-style: normal; |
|---|
| 261 | text-transform: lowercase; |
|---|
| 262 | font-variant: small-caps; |
|---|
| 263 | } |
|---|
| 264 | .comment { |
|---|
| 265 | background-color: yellow; |
|---|
| 266 | } |
|---|
| 267 | .center { |
|---|
| 268 | text-align: center; |
|---|
| 269 | } |
|---|
| 270 | .error { |
|---|
| 271 | color: red; |
|---|
| 272 | font-style: italic; |
|---|
| 273 | font-weight: bold; |
|---|
| 274 | } |
|---|
| 275 | .figure { |
|---|
| 276 | font-weight: bold; |
|---|
| 277 | text-align: center; |
|---|
| 278 | font-size: 10pt; |
|---|
| 279 | } |
|---|
| 280 | .filename { |
|---|
| 281 | color: #333333; |
|---|
| 282 | font-size: 75%; |
|---|
| 283 | font-weight: bold; |
|---|
| 284 | line-height: 21pt; |
|---|
| 285 | text-align: center; |
|---|
| 286 | } |
|---|
| 287 | .fn { |
|---|
| 288 | font-weight: bold; |
|---|
| 289 | } |
|---|
| 290 | .left { |
|---|
| 291 | text-align: left; |
|---|
| 292 | } |
|---|
| 293 | .right { |
|---|
| 294 | text-align: right; |
|---|
| 295 | } |
|---|
| 296 | .title { |
|---|
| 297 | color: green; |
|---|
| 298 | font-size: 150%; |
|---|
| 299 | line-height: 18pt; |
|---|
| 300 | font-weight: bold; |
|---|
| 301 | text-align: center; |
|---|
| 302 | margin-top: 36pt; |
|---|
| 303 | } |
|---|
| 304 | .warning { |
|---|
| 305 | font-size: 130%; |
|---|
| 306 | background-color: yellow; |
|---|
| 307 | } |
|---|
| 308 | |
|---|
| 309 | |
|---|
| 310 | @media print { |
|---|
| 311 | .noprint { |
|---|
| 312 | display: none; |
|---|
| 313 | } |
|---|
| 314 | |
|---|
| 315 | a { |
|---|
| 316 | color: black; |
|---|
| 317 | text-decoration: none; |
|---|
| 318 | } |
|---|
| 319 | |
|---|
| 320 | table.header { |
|---|
| 321 | width: 90%; |
|---|
| 322 | } |
|---|
| 323 | |
|---|
| 324 | td.header { |
|---|
| 325 | width: 50%; |
|---|
| 326 | color: black; |
|---|
| 327 | background-color: white; |
|---|
| 328 | vertical-align: top; |
|---|
| 329 | font-size: 110%; |
|---|
| 330 | } |
|---|
| 331 | |
|---|
| 332 | ul.toc a:nth-child(2)::after { |
|---|
| 333 | content: leader('.') target-counter(attr(href), page); |
|---|
| 334 | } |
|---|
| 335 | |
|---|
| 336 | ul.ind li li a { |
|---|
| 337 | content: target-counter(attr(href), page); |
|---|
| 338 | } |
|---|
| 339 | |
|---|
| 340 | .print2col { |
|---|
| 341 | column-count: 2; |
|---|
| 342 | -moz-column-count: 2; |
|---|
| 343 | column-fill: auto; |
|---|
| 344 | } |
|---|
| 345 | } |
|---|
| 346 | |
|---|
| 347 | @page { |
|---|
| 348 | @top-left { |
|---|
| 349 | content: "Internet-Draft"; |
|---|
| 350 | } |
|---|
| 351 | @top-right { |
|---|
| 352 | content: "August 2008"; |
|---|
| 353 | } |
|---|
| 354 | @top-center { |
|---|
| 355 | content: "HTTP/1.1, Part 2"; |
|---|
| 356 | } |
|---|
| 357 | @bottom-left { |
|---|
| 358 | content: "Fielding, et al."; |
|---|
| 359 | } |
|---|
| 360 | @bottom-center { |
|---|
| 361 | content: "Expires March 2, 2009"; |
|---|
| 362 | } |
|---|
| 363 | @bottom-right { |
|---|
| 364 | content: "[Page " counter(page) "]"; |
|---|
| 365 | } |
|---|
| 366 | } |
|---|
| 367 | |
|---|
| 368 | @page:first { |
|---|
| 369 | @top-left { |
|---|
| 370 | content: normal; |
|---|
| 371 | } |
|---|
| 372 | @top-right { |
|---|
| 373 | content: normal; |
|---|
| 374 | } |
|---|
| 375 | @top-center { |
|---|
| 376 | content: normal; |
|---|
| 377 | } |
|---|
| 378 | } |
|---|
| 379 | </style><link rel="Contents" href="#rfc.toc"> |
|---|
| 380 | <link rel="Author" href="#rfc.authors"> |
|---|
| 381 | <link rel="Copyright" href="#rfc.copyright"> |
|---|
| 382 | <link rel="Index" href="#rfc.index"> |
|---|
| 383 | <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> |
|---|
| 384 | <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"> |
|---|
| 385 | <link rel="Chapter" title="3 Method" href="#rfc.section.3"> |
|---|
| 386 | <link rel="Chapter" title="4 Request Header Fields" href="#rfc.section.4"> |
|---|
| 387 | <link rel="Chapter" title="5 Status Code and Reason Phrase" href="#rfc.section.5"> |
|---|
| 388 | <link rel="Chapter" title="6 Response Header Fields" href="#rfc.section.6"> |
|---|
| 389 | <link rel="Chapter" title="7 Entity" href="#rfc.section.7"> |
|---|
| 390 | <link rel="Chapter" title="8 Method Definitions" href="#rfc.section.8"> |
|---|
| 391 | <link rel="Chapter" title="9 Status Code Definitions" href="#rfc.section.9"> |
|---|
| 392 | <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10"> |
|---|
| 393 | <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"> |
|---|
| 394 | <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12"> |
|---|
| 395 | <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13"> |
|---|
| 396 | <link rel="Chapter" href="#rfc.section.14" title="14 References"> |
|---|
| 397 | <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> |
|---|
| 398 | <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> |
|---|
| 399 | <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> |
|---|
| 400 | <link rel="schema.dct" href="http://purl.org/dc/terms/"> |
|---|
| 401 | <meta name="dct.creator" content="Fielding, R."> |
|---|
| 402 | <meta name="dct.creator" content="Gettys, J."> |
|---|
| 403 | <meta name="dct.creator" content="Mogul, J."> |
|---|
| 404 | <meta name="dct.creator" content="Frystyk, H."> |
|---|
| 405 | <meta name="dct.creator" content="Masinter, L."> |
|---|
| 406 | <meta name="dct.creator" content="Leach, P."> |
|---|
| 407 | <meta name="dct.creator" content="Berners-Lee, T."> |
|---|
| 408 | <meta name="dct.creator" content="Lafon, Y."> |
|---|
| 409 | <meta name="dct.creator" content="Reschke, J. F."> |
|---|
| 410 | <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-04"> |
|---|
| 411 | <meta name="dct.issued" scheme="ISO8601" content="2008-08-29"> |
|---|
| 412 | <meta name="dct.replaces" content="urn:ietf:rfc:2616"> |
|---|
| 413 | <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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."> |
|---|
| 414 | <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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."> |
|---|
| 415 | </head> |
|---|
| 416 | <body> |
|---|
| 417 | <table class="header"> |
|---|
| 418 | <tbody> |
|---|
| 419 | <tr> |
|---|
| 420 | <td class="left">Network Working Group</td> |
|---|
| 421 | <td class="right">R. Fielding, Editor</td> |
|---|
| 422 | </tr> |
|---|
| 423 | <tr> |
|---|
| 424 | <td class="left">Internet-Draft</td> |
|---|
| 425 | <td class="right">Day Software</td> |
|---|
| 426 | </tr> |
|---|
| 427 | <tr> |
|---|
| 428 | <td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a> (if approved) |
|---|
| 429 | </td> |
|---|
| 430 | <td class="right">J. Gettys</td> |
|---|
| 431 | </tr> |
|---|
| 432 | <tr> |
|---|
| 433 | <td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2817">2817</a> (if approved) |
|---|
| 434 | </td> |
|---|
| 435 | <td class="right">One Laptop per Child</td> |
|---|
| 436 | </tr> |
|---|
| 437 | <tr> |
|---|
| 438 | <td class="left">Intended status: Standards Track</td> |
|---|
| 439 | <td class="right">J. Mogul</td> |
|---|
| 440 | </tr> |
|---|
| 441 | <tr> |
|---|
| 442 | <td class="left">Expires: March 2, 2009</td> |
|---|
| 443 | <td class="right">HP</td> |
|---|
| 444 | </tr> |
|---|
| 445 | <tr> |
|---|
| 446 | <td class="left"></td> |
|---|
| 447 | <td class="right">H. Frystyk</td> |
|---|
| 448 | </tr> |
|---|
| 449 | <tr> |
|---|
| 450 | <td class="left"></td> |
|---|
| 451 | <td class="right">Microsoft</td> |
|---|
| 452 | </tr> |
|---|
| 453 | <tr> |
|---|
| 454 | <td class="left"></td> |
|---|
| 455 | <td class="right">L. Masinter</td> |
|---|
| 456 | </tr> |
|---|
| 457 | <tr> |
|---|
| 458 | <td class="left"></td> |
|---|
| 459 | <td class="right">Adobe Systems</td> |
|---|
| 460 | </tr> |
|---|
| 461 | <tr> |
|---|
| 462 | <td class="left"></td> |
|---|
| 463 | <td class="right">P. Leach</td> |
|---|
| 464 | </tr> |
|---|
| 465 | <tr> |
|---|
| 466 | <td class="left"></td> |
|---|
| 467 | <td class="right">Microsoft</td> |
|---|
| 468 | </tr> |
|---|
| 469 | <tr> |
|---|
| 470 | <td class="left"></td> |
|---|
| 471 | <td class="right">T. Berners-Lee</td> |
|---|
| 472 | </tr> |
|---|
| 473 | <tr> |
|---|
| 474 | <td class="left"></td> |
|---|
| 475 | <td class="right">W3C/MIT</td> |
|---|
| 476 | </tr> |
|---|
| 477 | <tr> |
|---|
| 478 | <td class="left"></td> |
|---|
| 479 | <td class="right">Y. Lafon, Editor</td> |
|---|
| 480 | </tr> |
|---|
| 481 | <tr> |
|---|
| 482 | <td class="left"></td> |
|---|
| 483 | <td class="right">W3C</td> |
|---|
| 484 | </tr> |
|---|
| 485 | <tr> |
|---|
| 486 | <td class="left"></td> |
|---|
| 487 | <td class="right">J. Reschke, Editor</td> |
|---|
| 488 | </tr> |
|---|
| 489 | <tr> |
|---|
| 490 | <td class="left"></td> |
|---|
| 491 | <td class="right">greenbytes</td> |
|---|
| 492 | </tr> |
|---|
| 493 | <tr> |
|---|
| 494 | <td class="left"></td> |
|---|
| 495 | <td class="right">August 29, 2008</td> |
|---|
| 496 | </tr> |
|---|
| 497 | </tbody> |
|---|
| 498 | </table> |
|---|
| 499 | <p class="title">HTTP/1.1, part 2: Message Semantics<br><span class="filename">draft-ietf-httpbis-p2-semantics-04</span></p> |
|---|
| 500 | <div id="rfc.status"> |
|---|
| 501 | <h1><a href="#rfc.status">Status of this Memo</a></h1> |
|---|
| 502 | <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she |
|---|
| 503 | is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section |
|---|
| 504 | 6 of BCP 79. |
|---|
| 505 | </p> |
|---|
| 506 | <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note |
|---|
| 507 | that other groups may also distribute working documents as Internet-Drafts. |
|---|
| 508 | </p> |
|---|
| 509 | <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other |
|---|
| 510 | documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work |
|---|
| 511 | in progress”. |
|---|
| 512 | </p> |
|---|
| 513 | <p>The list of current Internet-Drafts can be accessed at <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>. |
|---|
| 514 | </p> |
|---|
| 515 | <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. |
|---|
| 516 | </p> |
|---|
| 517 | <p>This Internet-Draft will expire on March 2, 2009.</p> |
|---|
| 518 | </div> |
|---|
| 519 | <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> |
|---|
| 520 | <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information |
|---|
| 521 | systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the |
|---|
| 522 | seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part |
|---|
| 523 | 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and |
|---|
| 524 | response-header fields. |
|---|
| 525 | </p> |
|---|
| 526 | <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> |
|---|
| 527 | <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues |
|---|
| 528 | list is at <<a href="http://www.tools.ietf.org/wg/httpbis/trac/report/11">http://www.tools.ietf.org/wg/httpbis/trac/report/11</a>> and related documents (including fancy diffs) can be found at <<a href="http://www.tools.ietf.org/wg/httpbis/">http://www.tools.ietf.org/wg/httpbis/</a>>. |
|---|
| 529 | </p> |
|---|
| 530 | <p>The changes in this draft are summarized in <a href="#changes.since.02" title="Since draft-ietf-httpbis-p2-semantics-02">Appendix B.4</a>. |
|---|
| 531 | </p> |
|---|
| 532 | <hr class="noprint"> |
|---|
| 533 | <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> |
|---|
| 534 | <ul class="toc"> |
|---|
| 535 | <li><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a><ul> |
|---|
| 536 | <li><a href="#rfc.section.1.1">1.1</a> <a href="#intro.requirements">Requirements</a></li> |
|---|
| 537 | </ul> |
|---|
| 538 | </li> |
|---|
| 539 | <li><a href="#rfc.section.2">2.</a> <a href="#notation">Notational Conventions and Generic Grammar</a></li> |
|---|
| 540 | <li><a href="#rfc.section.3">3.</a> <a href="#method">Method</a><ul> |
|---|
| 541 | <li><a href="#rfc.section.3.1">3.1</a> <a href="#method.registry">Method Registry</a></li> |
|---|
| 542 | </ul> |
|---|
| 543 | </li> |
|---|
| 544 | <li><a href="#rfc.section.4">4.</a> <a href="#request.header.fields">Request Header Fields</a></li> |
|---|
| 545 | <li><a href="#rfc.section.5">5.</a> <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a><ul> |
|---|
| 546 | <li><a href="#rfc.section.5.1">5.1</a> <a href="#status.code.registry">Status Code Registry</a></li> |
|---|
| 547 | </ul> |
|---|
| 548 | </li> |
|---|
| 549 | <li><a href="#rfc.section.6">6.</a> <a href="#response.header.fields">Response Header Fields</a></li> |
|---|
| 550 | <li><a href="#rfc.section.7">7.</a> <a href="#entity">Entity</a></li> |
|---|
| 551 | <li><a href="#rfc.section.8">8.</a> <a href="#method.definitions">Method Definitions</a><ul> |
|---|
| 552 | <li><a href="#rfc.section.8.1">8.1</a> <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul> |
|---|
| 553 | <li><a href="#rfc.section.8.1.1">8.1.1</a> <a href="#safe.methods">Safe Methods</a></li> |
|---|
| 554 | <li><a href="#rfc.section.8.1.2">8.1.2</a> <a href="#idempotent.methods">Idempotent Methods</a></li> |
|---|
| 555 | </ul> |
|---|
| 556 | </li> |
|---|
| 557 | <li><a href="#rfc.section.8.2">8.2</a> <a href="#OPTIONS">OPTIONS</a></li> |
|---|
| 558 | <li><a href="#rfc.section.8.3">8.3</a> <a href="#GET">GET</a></li> |
|---|
| 559 | <li><a href="#rfc.section.8.4">8.4</a> <a href="#HEAD">HEAD</a></li> |
|---|
| 560 | <li><a href="#rfc.section.8.5">8.5</a> <a href="#POST">POST</a></li> |
|---|
| 561 | <li><a href="#rfc.section.8.6">8.6</a> <a href="#PUT">PUT</a></li> |
|---|
| 562 | <li><a href="#rfc.section.8.7">8.7</a> <a href="#DELETE">DELETE</a></li> |
|---|
| 563 | <li><a href="#rfc.section.8.8">8.8</a> <a href="#TRACE">TRACE</a></li> |
|---|
| 564 | <li><a href="#rfc.section.8.9">8.9</a> <a href="#CONNECT">CONNECT</a></li> |
|---|
| 565 | </ul> |
|---|
| 566 | </li> |
|---|
| 567 | <li><a href="#rfc.section.9">9.</a> <a href="#status.codes">Status Code Definitions</a><ul> |
|---|
| 568 | <li><a href="#rfc.section.9.1">9.1</a> <a href="#status.1xx">Informational 1xx</a><ul> |
|---|
| 569 | <li><a href="#rfc.section.9.1.1">9.1.1</a> <a href="#status.100">100 Continue</a></li> |
|---|
| 570 | <li><a href="#rfc.section.9.1.2">9.1.2</a> <a href="#status.101">101 Switching Protocols</a></li> |
|---|
| 571 | </ul> |
|---|
| 572 | </li> |
|---|
| 573 | <li><a href="#rfc.section.9.2">9.2</a> <a href="#status.2xx">Successful 2xx</a><ul> |
|---|
| 574 | <li><a href="#rfc.section.9.2.1">9.2.1</a> <a href="#status.200">200 OK</a></li> |
|---|
| 575 | <li><a href="#rfc.section.9.2.2">9.2.2</a> <a href="#status.201">201 Created</a></li> |
|---|
| 576 | <li><a href="#rfc.section.9.2.3">9.2.3</a> <a href="#status.202">202 Accepted</a></li> |
|---|
| 577 | <li><a href="#rfc.section.9.2.4">9.2.4</a> <a href="#status.203">203 Non-Authoritative Information</a></li> |
|---|
| 578 | <li><a href="#rfc.section.9.2.5">9.2.5</a> <a href="#status.204">204 No Content</a></li> |
|---|
| 579 | <li><a href="#rfc.section.9.2.6">9.2.6</a> <a href="#status.205">205 Reset Content</a></li> |
|---|
| 580 | <li><a href="#rfc.section.9.2.7">9.2.7</a> <a href="#status.206">206 Partial Content</a></li> |
|---|
| 581 | </ul> |
|---|
| 582 | </li> |
|---|
| 583 | <li><a href="#rfc.section.9.3">9.3</a> <a href="#status.3xx">Redirection 3xx</a><ul> |
|---|
| 584 | <li><a href="#rfc.section.9.3.1">9.3.1</a> <a href="#status.300">300 Multiple Choices</a></li> |
|---|
| 585 | <li><a href="#rfc.section.9.3.2">9.3.2</a> <a href="#status.301">301 Moved Permanently</a></li> |
|---|
| 586 | <li><a href="#rfc.section.9.3.3">9.3.3</a> <a href="#status.302">302 Found</a></li> |
|---|
| 587 | <li><a href="#rfc.section.9.3.4">9.3.4</a> <a href="#status.303">303 See Other</a></li> |
|---|
| 588 | <li><a href="#rfc.section.9.3.5">9.3.5</a> <a href="#status.304">304 Not Modified</a></li> |
|---|
| 589 | <li><a href="#rfc.section.9.3.6">9.3.6</a> <a href="#status.305">305 Use Proxy</a></li> |
|---|
| 590 | <li><a href="#rfc.section.9.3.7">9.3.7</a> <a href="#status.306">306 (Unused)</a></li> |
|---|
| 591 | <li><a href="#rfc.section.9.3.8">9.3.8</a> <a href="#status.307">307 Temporary Redirect</a></li> |
|---|
| 592 | </ul> |
|---|
| 593 | </li> |
|---|
| 594 | <li><a href="#rfc.section.9.4">9.4</a> <a href="#status.4xx">Client Error 4xx</a><ul> |
|---|
| 595 | <li><a href="#rfc.section.9.4.1">9.4.1</a> <a href="#status.400">400 Bad Request</a></li> |
|---|
| 596 | <li><a href="#rfc.section.9.4.2">9.4.2</a> <a href="#status.401">401 Unauthorized</a></li> |
|---|
| 597 | <li><a href="#rfc.section.9.4.3">9.4.3</a> <a href="#status.402">402 Payment Required</a></li> |
|---|
| 598 | <li><a href="#rfc.section.9.4.4">9.4.4</a> <a href="#status.403">403 Forbidden</a></li> |
|---|
| 599 | <li><a href="#rfc.section.9.4.5">9.4.5</a> <a href="#status.404">404 Not Found</a></li> |
|---|
| 600 | <li><a href="#rfc.section.9.4.6">9.4.6</a> <a href="#status.405">405 Method Not Allowed</a></li> |
|---|
| 601 | <li><a href="#rfc.section.9.4.7">9.4.7</a> <a href="#status.406">406 Not Acceptable</a></li> |
|---|
| 602 | <li><a href="#rfc.section.9.4.8">9.4.8</a> <a href="#status.407">407 Proxy Authentication Required</a></li> |
|---|
| 603 | <li><a href="#rfc.section.9.4.9">9.4.9</a> <a href="#status.408">408 Request Timeout</a></li> |
|---|
| 604 | <li><a href="#rfc.section.9.4.10">9.4.10</a> <a href="#status.409">409 Conflict</a></li> |
|---|
| 605 | <li><a href="#rfc.section.9.4.11">9.4.11</a> <a href="#status.410">410 Gone</a></li> |
|---|
| 606 | <li><a href="#rfc.section.9.4.12">9.4.12</a> <a href="#status.411">411 Length Required</a></li> |
|---|
| 607 | <li><a href="#rfc.section.9.4.13">9.4.13</a> <a href="#status.412">412 Precondition Failed</a></li> |
|---|
| 608 | <li><a href="#rfc.section.9.4.14">9.4.14</a> <a href="#status.413">413 Request Entity Too Large</a></li> |
|---|
| 609 | <li><a href="#rfc.section.9.4.15">9.4.15</a> <a href="#status.414">414 Request-URI Too Long</a></li> |
|---|
| 610 | <li><a href="#rfc.section.9.4.16">9.4.16</a> <a href="#status.415">415 Unsupported Media Type</a></li> |
|---|
| 611 | <li><a href="#rfc.section.9.4.17">9.4.17</a> <a href="#status.416">416 Requested Range Not Satisfiable</a></li> |
|---|
| 612 | <li><a href="#rfc.section.9.4.18">9.4.18</a> <a href="#status.417">417 Expectation Failed</a></li> |
|---|
| 613 | </ul> |
|---|
| 614 | </li> |
|---|
| 615 | <li><a href="#rfc.section.9.5">9.5</a> <a href="#status.5xx">Server Error 5xx</a><ul> |
|---|
| 616 | <li><a href="#rfc.section.9.5.1">9.5.1</a> <a href="#status.500">500 Internal Server Error</a></li> |
|---|
| 617 | <li><a href="#rfc.section.9.5.2">9.5.2</a> <a href="#status.501">501 Not Implemented</a></li> |
|---|
| 618 | <li><a href="#rfc.section.9.5.3">9.5.3</a> <a href="#status.502">502 Bad Gateway</a></li> |
|---|
| 619 | <li><a href="#rfc.section.9.5.4">9.5.4</a> <a href="#status.503">503 Service Unavailable</a></li> |
|---|
| 620 | <li><a href="#rfc.section.9.5.5">9.5.5</a> <a href="#status.504">504 Gateway Timeout</a></li> |
|---|
| 621 | <li><a href="#rfc.section.9.5.6">9.5.6</a> <a href="#status.505">505 HTTP Version Not Supported</a></li> |
|---|
| 622 | </ul> |
|---|
| 623 | </li> |
|---|
| 624 | </ul> |
|---|
| 625 | </li> |
|---|
| 626 | <li><a href="#rfc.section.10">10.</a> <a href="#header.fields">Header Field Definitions</a><ul> |
|---|
| 627 | <li><a href="#rfc.section.10.1">10.1</a> <a href="#header.allow">Allow</a></li> |
|---|
| 628 | <li><a href="#rfc.section.10.2">10.2</a> <a href="#header.expect">Expect</a></li> |
|---|
| 629 | <li><a href="#rfc.section.10.3">10.3</a> <a href="#header.from">From</a></li> |
|---|
| 630 | <li><a href="#rfc.section.10.4">10.4</a> <a href="#header.location">Location</a></li> |
|---|
| 631 | <li><a href="#rfc.section.10.5">10.5</a> <a href="#header.max-forwards">Max-Forwards</a></li> |
|---|
| 632 | <li><a href="#rfc.section.10.6">10.6</a> <a href="#header.referer">Referer</a></li> |
|---|
| 633 | <li><a href="#rfc.section.10.7">10.7</a> <a href="#header.retry-after">Retry-After</a></li> |
|---|
| 634 | <li><a href="#rfc.section.10.8">10.8</a> <a href="#header.server">Server</a></li> |
|---|
| 635 | <li><a href="#rfc.section.10.9">10.9</a> <a href="#header.user-agent">User-Agent</a></li> |
|---|
| 636 | </ul> |
|---|
| 637 | </li> |
|---|
| 638 | <li><a href="#rfc.section.11">11.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> |
|---|
| 639 | <li><a href="#rfc.section.11.1">11.1</a> <a href="#method.registration">Method Registry</a></li> |
|---|
| 640 | <li><a href="#rfc.section.11.2">11.2</a> <a href="#status.code.registration">Status Code Registry</a></li> |
|---|
| 641 | <li><a href="#rfc.section.11.3">11.3</a> <a href="#message.header.registration">Message Header Registration</a></li> |
|---|
| 642 | </ul> |
|---|
| 643 | </li> |
|---|
| 644 | <li><a href="#rfc.section.12">12.</a> <a href="#security.considerations">Security Considerations</a><ul> |
|---|
| 645 | <li><a href="#rfc.section.12.1">12.1</a> <a href="#security.sensitive">Transfer of Sensitive Information</a></li> |
|---|
| 646 | <li><a href="#rfc.section.12.2">12.2</a> <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> |
|---|
| 647 | <li><a href="#rfc.section.12.3">12.3</a> <a href="#location.spoofing">Location Headers and Spoofing</a></li> |
|---|
| 648 | </ul> |
|---|
| 649 | </li> |
|---|
| 650 | <li><a href="#rfc.section.13">13.</a> <a href="#ack">Acknowledgments</a></li> |
|---|
| 651 | <li><a href="#rfc.section.14">14.</a> <a href="#rfc.references">References</a><ul> |
|---|
| 652 | <li><a href="#rfc.section.14.1">14.1</a> <a href="#rfc.references.1">Normative References</a></li> |
|---|
| 653 | <li><a href="#rfc.section.14.2">14.2</a> <a href="#rfc.references.2">Informative References</a></li> |
|---|
| 654 | </ul> |
|---|
| 655 | </li> |
|---|
| 656 | <li><a href="#rfc.section.A">A.</a> <a href="#compatibility">Compatibility with Previous Versions</a><ul> |
|---|
| 657 | <li><a href="#rfc.section.A.1">A.1</a> <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li> |
|---|
| 658 | <li><a href="#rfc.section.A.2">A.2</a> <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> |
|---|
| 659 | </ul> |
|---|
| 660 | </li> |
|---|
| 661 | <li><a href="#rfc.section.B">B.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> |
|---|
| 662 | <li><a href="#rfc.section.B.1">B.1</a> <a href="#rfc.section.B.1">Since RFC2616</a></li> |
|---|
| 663 | <li><a href="#rfc.section.B.2">B.2</a> <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p2-semantics-00</a></li> |
|---|
| 664 | <li><a href="#rfc.section.B.3">B.3</a> <a href="#rfc.section.B.3">Since draft-ietf-httpbis-p2-semantics-01</a></li> |
|---|
| 665 | <li><a href="#rfc.section.B.4">B.4</a> <a href="#changes.since.02">Since draft-ietf-httpbis-p2-semantics-02</a></li> |
|---|
| 666 | <li><a href="#rfc.section.B.5">B.5</a> <a href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></li> |
|---|
| 667 | </ul> |
|---|
| 668 | </li> |
|---|
| 669 | <li><a href="#rfc.index">Index</a></li> |
|---|
| 670 | <li><a href="#rfc.authors">Authors' Addresses</a></li> |
|---|
| 671 | <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> |
|---|
| 672 | </ul> |
|---|
| 673 | <div id="introduction"> |
|---|
| 674 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> |
|---|
| 675 | <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 |
|---|
| 676 | to each request, in the order received on that connection, with one or more HTTP response messages. This document defines |
|---|
| 677 | the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various |
|---|
| 678 | response messages that might be expected as a result of applying that method for the requested resource. |
|---|
| 679 | </p> |
|---|
| 680 | <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 |
|---|
| 681 | errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will |
|---|
| 682 | be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general |
|---|
| 683 | header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed |
|---|
| 684 | 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>. |
|---|
| 685 | </p> |
|---|
| 686 | <div id="intro.requirements"> |
|---|
| 687 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a href="#intro.requirements">Requirements</a></h2> |
|---|
| 688 | <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" |
|---|
| 689 | 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>. |
|---|
| 690 | </p> |
|---|
| 691 | <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." |
|---|
| 692 | </p> |
|---|
| 693 | </div> |
|---|
| 694 | </div> |
|---|
| 695 | <div id="notation"> |
|---|
| 696 | <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#notation">Notational Conventions and Generic Grammar</a></h1> |
|---|
| 697 | <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="Augmented BNF">Section 2.1</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> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.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>: <span class="comment" id="abnf.dep">[<a href="#abnf.dep" class="smpl">abnf.dep</a>: ABNF syntax and basic rules will be adopted from RFC 5234, see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>.]</span> |
|---|
| 698 | </p> |
|---|
| 699 | <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">DIGIT</a> = <DIGIT, 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>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> |
|---|
| 700 | </pre><div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#notation" class="smpl">comment</a> = <comment, 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#basic.rules" title="Basic Rules">Section 2.2</a>> |
|---|
| 701 | <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, 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#basic.rules" title="Basic Rules">Section 2.2</a>> |
|---|
| 702 | <a href="#notation" class="smpl">token</a> = <token, 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#basic.rules" title="Basic Rules">Section 2.2</a>> |
|---|
| 703 | </pre><div id="abnf.dependencies"> |
|---|
| 704 | <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> |
|---|
| 705 | </div> |
|---|
| 706 | <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absoluteURI</a> = <absoluteURI, 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#general.syntax" title="General Syntax">Section 3.2.1</a>> |
|---|
| 707 | <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, 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#general.syntax" title="General Syntax">Section 3.2.1</a>> |
|---|
| 708 | <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, 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#header.host" title="Host">Section 8.4</a>> |
|---|
| 709 | <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, 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#full.date" title="Full Date">Section 3.3.1</a>> |
|---|
| 710 | <a href="#abnf.dependencies" class="smpl">product</a> = <product, 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#product.tokens" title="Product Tokens">Section 3.5</a>> |
|---|
| 711 | <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, 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#general.syntax" title="General Syntax">Section 3.2.1</a>> |
|---|
| 712 | <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, 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#header.upgrade" title="Upgrade">Section 8.8</a>> |
|---|
| 713 | </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> |
|---|
| 714 | <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> = |
|---|
| 715 | <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>> |
|---|
| 716 | <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> = |
|---|
| 717 | <Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>> |
|---|
| 718 | <a href="#abnf.dependencies" class="smpl">Accept-Language</a> = |
|---|
| 719 | <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>> |
|---|
| 720 | </pre><div id="rfc.figure.u.5"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">ETag</a> = <ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a>> |
|---|
| 721 | <a href="#abnf.dependencies" class="smpl">If-Match</a> = <If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 7.2</a>> |
|---|
| 722 | <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a> = |
|---|
| 723 | <If-Modified-Since, defined in <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 7.3</a>> |
|---|
| 724 | <a href="#abnf.dependencies" class="smpl">If-None-Match</a> = <If-None-Match, defined in <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 7.4</a>> |
|---|
| 725 | <a href="#abnf.dependencies" class="smpl">If-Unmodified-Since</a> = |
|---|
| 726 | <If-Unmodified-Since, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 7.5</a>> |
|---|
| 727 | </pre><div id="rfc.figure.u.6"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> = <Accept-Ranges, defined in <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a>> |
|---|
| 728 | <a href="#abnf.dependencies" class="smpl">If-Range</a> = <If-Range, defined in <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</a>> |
|---|
| 729 | <a href="#abnf.dependencies" class="smpl">Range</a> = <Range, defined in <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 6.4</a>> |
|---|
| 730 | </pre><div id="rfc.figure.u.7"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Age</a> = <Age, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a>> |
|---|
| 731 | <a href="#abnf.dependencies" class="smpl">Vary</a> = <Vary, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 16.5</a>> |
|---|
| 732 | </pre><div id="rfc.figure.u.8"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Authorization</a> = <Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a>> |
|---|
| 733 | <a href="#abnf.dependencies" class="smpl">Proxy-Authenticate</a> = |
|---|
| 734 | <Proxy-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a>> |
|---|
| 735 | <a href="#abnf.dependencies" class="smpl">Proxy-Authorization</a> = |
|---|
| 736 | <Proxy-Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a>> |
|---|
| 737 | <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> = |
|---|
| 738 | <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> |
|---|
| 739 | </pre></div> |
|---|
| 740 | <div id="method"> |
|---|
| 741 | <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#method">Method</a></h1> |
|---|
| 742 | <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p> |
|---|
| 743 | <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> |
|---|
| 744 | | %x47.45.54 ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> |
|---|
| 745 | | %x48.45.41.44 ; "HEAD", <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a> |
|---|
| 746 | | %x50.4F.53.54 ; "POST", <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 8.5</a> |
|---|
| 747 | | %x50.55.54 ; "PUT", <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 8.6</a> |
|---|
| 748 | | %x44.45.4C.45.54.45 ; "DELETE", <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 8.7</a> |
|---|
| 749 | | %x54.52.41.43.45 ; "TRACE", <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 8.8</a> |
|---|
| 750 | | %x43.4F.4E.4E.45.43.54 ; "CONNECT", <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 8.9</a> |
|---|
| 751 | | <a href="#method" class="smpl">extension-method</a> |
|---|
| 752 | <a href="#method" class="smpl">extension-method</a> = <a href="#notation" class="smpl">token</a> |
|---|
| 753 | </pre><p id="rfc.section.3.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 return code of the response always notifies the client whether a method is currently allowed on a resource, since the |
|---|
| 754 | set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested |
|---|
| 755 | resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET |
|---|
| 756 | 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 8</a>. |
|---|
| 757 | </p> |
|---|
| 758 | <div id="method.registry"> |
|---|
| 759 | <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a href="#method.registry">Method Registry</a></h2> |
|---|
| 760 | <p id="rfc.section.3.1.p.1">The HTTP Method Registry defines the name space for the Method token in the Request line of an HTTP request.</p> |
|---|
| 761 | <p id="rfc.section.3.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: |
|---|
| 762 | </p> |
|---|
| 763 | <ul> |
|---|
| 764 | <li>Method Name (see <a href="#method" title="Method">Section 3</a>) |
|---|
| 765 | </li> |
|---|
| 766 | <li>Safe ("yes" or "no", see <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>) |
|---|
| 767 | </li> |
|---|
| 768 | <li>Pointer to specification text</li> |
|---|
| 769 | </ul> |
|---|
| 770 | <p id="rfc.section.3.1.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="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). Any document registering new method names should be traceable through statuses of either 'Obsoletes' or 'Updates' to this |
|---|
| 771 | document. |
|---|
| 772 | </p> |
|---|
| 773 | <p id="rfc.section.3.1.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>>. |
|---|
| 774 | </p> |
|---|
| 775 | </div> |
|---|
| 776 | </div> |
|---|
| 777 | <div id="request.header.fields"> |
|---|
| 778 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#request.header.fields">Request Header Fields</a></h1> |
|---|
| 779 | <p id="rfc.section.4.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself, |
|---|
| 780 | to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language |
|---|
| 781 | method invocation. |
|---|
| 782 | </p> |
|---|
| 783 | <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.3"></span> <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a> ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> |
|---|
| 784 | | <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> |
|---|
| 785 | | <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> |
|---|
| 786 | | <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> |
|---|
| 787 | | <a href="#abnf.dependencies" class="smpl">Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> |
|---|
| 788 | | <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a> |
|---|
| 789 | | <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a> |
|---|
| 790 | | <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> |
|---|
| 791 | | <a href="#abnf.dependencies" class="smpl">If-Match</a> ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 7.2</a> |
|---|
| 792 | | <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 7.3</a> |
|---|
| 793 | | <a href="#abnf.dependencies" class="smpl">If-None-Match</a> ; <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 7.4</a> |
|---|
| 794 | | <a href="#abnf.dependencies" class="smpl">If-Range</a> ; <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</a> |
|---|
| 795 | | <a href="#abnf.dependencies" class="smpl">If-Unmodified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 7.5</a> |
|---|
| 796 | | <a href="#header.max-forwards" class="smpl">Max-Forwards</a> ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.5</a> |
|---|
| 797 | | <a href="#abnf.dependencies" class="smpl">Proxy-Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> |
|---|
| 798 | | <a href="#abnf.dependencies" class="smpl">Range</a> ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 6.4</a> |
|---|
| 799 | | <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a> |
|---|
| 800 | | <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a> |
|---|
| 801 | | <a href="#header.user-agent" class="smpl">User-Agent</a> ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a> |
|---|
| 802 | </pre><p id="rfc.section.4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new |
|---|
| 803 | or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. |
|---|
| 804 | Unrecognized header fields are treated as entity-header fields. |
|---|
| 805 | </p> |
|---|
| 806 | </div> |
|---|
| 807 | <div id="status.code.and.reason.phrase"> |
|---|
| 808 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> |
|---|
| 809 | <p id="rfc.section.5.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The status |
|---|
| 810 | codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 9</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use |
|---|
| 811 | by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. |
|---|
| 812 | </p> |
|---|
| 813 | <p id="rfc.section.5.p.2">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, |
|---|
| 814 | are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol. |
|---|
| 815 | </p> |
|---|
| 816 | <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = |
|---|
| 817 | "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue |
|---|
| 818 | | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols |
|---|
| 819 | | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 9.2.1</a>: OK |
|---|
| 820 | | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 9.2.2</a>: Created |
|---|
| 821 | | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 9.2.3</a>: Accepted |
|---|
| 822 | | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 9.2.4</a>: Non-Authoritative Information |
|---|
| 823 | | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 9.2.5</a>: No Content |
|---|
| 824 | | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 9.2.6</a>: Reset Content |
|---|
| 825 | | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 9.2.7</a>: Partial Content |
|---|
| 826 | | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 9.3.1</a>: Multiple Choices |
|---|
| 827 | | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 9.3.2</a>: Moved Permanently |
|---|
| 828 | | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 9.3.3</a>: Found |
|---|
| 829 | | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 9.3.4</a>: See Other |
|---|
| 830 | | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 9.3.5</a>: Not Modified |
|---|
| 831 | | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 9.3.6</a>: Use Proxy |
|---|
| 832 | | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 9.3.8</a>: Temporary Redirect |
|---|
| 833 | | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 9.4.1</a>: Bad Request |
|---|
| 834 | | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 9.4.2</a>: Unauthorized |
|---|
| 835 | | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 9.4.3</a>: Payment Required |
|---|
| 836 | | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 9.4.4</a>: Forbidden |
|---|
| 837 | | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 9.4.5</a>: Not Found |
|---|
| 838 | | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 9.4.6</a>: Method Not Allowed |
|---|
| 839 | | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 9.4.7</a>: Not Acceptable |
|---|
| 840 | | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 9.4.8</a>: Proxy Authentication Required |
|---|
| 841 | | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 9.4.9</a>: Request Time-out |
|---|
| 842 | | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 9.4.10</a>: Conflict |
|---|
| 843 | | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 9.4.11</a>: Gone |
|---|
| 844 | | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 9.4.12</a>: Length Required |
|---|
| 845 | | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 9.4.13</a>: Precondition Failed |
|---|
| 846 | | "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 9.4.14</a>: Request Entity Too Large |
|---|
| 847 | | "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-URI Too Long">Section 9.4.15</a>: Request-URI Too Large |
|---|
| 848 | | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 9.4.16</a>: Unsupported Media Type |
|---|
| 849 | | "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 9.4.17</a>: Requested range not satisfiable |
|---|
| 850 | | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 9.4.18</a>: Expectation Failed |
|---|
| 851 | | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 9.5.1</a>: Internal Server Error |
|---|
| 852 | | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 9.5.2</a>: Not Implemented |
|---|
| 853 | | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 9.5.3</a>: Bad Gateway |
|---|
| 854 | | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 9.5.4</a>: Service Unavailable |
|---|
| 855 | | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 9.5.5</a>: Gateway Time-out |
|---|
| 856 | | "505" ; <a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 9.5.6</a>: HTTP Version not supported |
|---|
| 857 | | <a href="#request.header.fields" class="smpl">extension-code</a> |
|---|
| 858 | |
|---|
| 859 | <a href="#request.header.fields" class="smpl">extension-code</a> = 3<a href="#notation" class="smpl">DIGIT</a> |
|---|
| 860 | <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *<TEXT, excluding CR, LF> |
|---|
| 861 | </pre><p id="rfc.section.5.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, |
|---|
| 862 | 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 |
|---|
| 863 | 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 |
|---|
| 864 | 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 entity returned with the response, since that entity is likely to include human-readable information |
|---|
| 865 | which will explain the unusual status. |
|---|
| 866 | </p> |
|---|
| 867 | <div id="status.code.registry"> |
|---|
| 868 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a href="#status.code.registry">Status Code Registry</a></h2> |
|---|
| 869 | <p id="rfc.section.5.1.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> |
|---|
| 870 | <p id="rfc.section.5.1.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="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). Any document registering new status codes should be traceable through statuses of either 'Obsoletes' or 'Updates' to this |
|---|
| 871 | document. |
|---|
| 872 | </p> |
|---|
| 873 | <p id="rfc.section.5.1.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>>. |
|---|
| 874 | </p> |
|---|
| 875 | </div> |
|---|
| 876 | </div> |
|---|
| 877 | <div id="response.header.fields"> |
|---|
| 878 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#response.header.fields">Response Header Fields</a></h1> |
|---|
| 879 | <p id="rfc.section.6.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the |
|---|
| 880 | Status-Line. These header fields give information about the server and about further access to the resource identified by |
|---|
| 881 | the Request-URI. |
|---|
| 882 | </p> |
|---|
| 883 | <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a> |
|---|
| 884 | | <a href="#abnf.dependencies" class="smpl">Age</a> ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a> |
|---|
| 885 | | <a href="#header.allow" class="smpl">Allow</a> ; <a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 10.1</a> |
|---|
| 886 | | <a href="#abnf.dependencies" class="smpl">ETag</a> ; <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a> |
|---|
| 887 | | <a href="#header.location" class="smpl">Location</a> ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a> |
|---|
| 888 | | <a href="#abnf.dependencies" class="smpl">Proxy-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> |
|---|
| 889 | | <a href="#header.retry-after" class="smpl">Retry-After</a> ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a> |
|---|
| 890 | | <a href="#header.server" class="smpl">Server</a> ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a> |
|---|
| 891 | | <a href="#abnf.dependencies" class="smpl">Vary</a> ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 16.5</a> |
|---|
| 892 | | <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.8"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> |
|---|
| 893 | </pre><p id="rfc.section.6.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new |
|---|
| 894 | or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header |
|---|
| 895 | fields. Unrecognized header fields are treated as entity-header fields. |
|---|
| 896 | </p> |
|---|
| 897 | </div> |
|---|
| 898 | <div id="entity"> |
|---|
| 899 | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#entity">Entity</a></h1> |
|---|
| 900 | <p id="rfc.section.7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header |
|---|
| 901 | fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header |
|---|
| 902 | fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. |
|---|
| 903 | </p> |
|---|
| 904 | <p id="rfc.section.7.p.2">An entity-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 4.3</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>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure |
|---|
| 905 | safe and proper transfer of the message. |
|---|
| 906 | </p> |
|---|
| 907 | </div> |
|---|
| 908 | <div id="method.definitions"> |
|---|
| 909 | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#method.definitions">Method Definitions</a></h1> |
|---|
| 910 | <p id="rfc.section.8.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed |
|---|
| 911 | to share the same semantics for separately extended clients and servers. |
|---|
| 912 | </p> |
|---|
| 913 | <div id="safe.and.idempotent"> |
|---|
| 914 | <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> |
|---|
| 915 | <div id="safe.methods"> |
|---|
| 916 | <div id="rfc.iref.s.1"></div> |
|---|
| 917 | <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a href="#safe.methods">Safe Methods</a></h3> |
|---|
| 918 | <p id="rfc.section.8.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be |
|---|
| 919 | careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves |
|---|
| 920 | or others. |
|---|
| 921 | </p> |
|---|
| 922 | <p id="rfc.section.8.1.1.p.2">In particular, the convention has been established that the GET and HEAD methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These 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 |
|---|
| 923 | made aware of the fact that a possibly unsafe action is being requested. |
|---|
| 924 | </p> |
|---|
| 925 | <p id="rfc.section.8.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; |
|---|
| 926 | in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the |
|---|
| 927 | side-effects, so therefore cannot be held accountable for them. |
|---|
| 928 | </p> |
|---|
| 929 | </div> |
|---|
| 930 | <div id="idempotent.methods"> |
|---|
| 931 | <div id="rfc.iref.i.1"></div> |
|---|
| 932 | <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a href="#idempotent.methods">Idempotent Methods</a></h3> |
|---|
| 933 | <p id="rfc.section.8.1.2.p.1">Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N |
|---|
| 934 | > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, |
|---|
| 935 | the methods OPTIONS and TRACE <em class="bcp14">SHOULD NOT</em> have side effects, and so are inherently idempotent. |
|---|
| 936 | </p> |
|---|
| 937 | <p id="rfc.section.8.1.2.p.2">However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that |
|---|
| 938 | sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that |
|---|
| 939 | is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result |
|---|
| 940 | depends on a value that is later modified in the same sequence. |
|---|
| 941 | </p> |
|---|
| 942 | <p id="rfc.section.8.1.2.p.3">A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed |
|---|
| 943 | on the same set of resources). |
|---|
| 944 | </p> |
|---|
| 945 | </div> |
|---|
| 946 | </div> |
|---|
| 947 | <div id="OPTIONS"> |
|---|
| 948 | <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a href="#OPTIONS">OPTIONS</a></h2> |
|---|
| 949 | <div id="rfc.iref.o.1"></div> |
|---|
| 950 | <div id="rfc.iref.m.1"></div> |
|---|
| 951 | <p id="rfc.section.8.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response |
|---|
| 952 | chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated |
|---|
| 953 | with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. |
|---|
| 954 | </p> |
|---|
| 955 | <p id="rfc.section.8.2.p.2">Responses to this method are not cacheable.</p> |
|---|
| 956 | <p id="rfc.section.8.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then |
|---|
| 957 | 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 |
|---|
| 958 | to HTTP might use the OPTIONS body to make more detailed queries on the server. |
|---|
| 959 | </p> |
|---|
| 960 | <p id="rfc.section.8.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to |
|---|
| 961 | a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful |
|---|
| 962 | as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. |
|---|
| 963 | For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). |
|---|
| 964 | </p> |
|---|
| 965 | <p id="rfc.section.8.2.p.5">If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating |
|---|
| 966 | with that resource. |
|---|
| 967 | </p> |
|---|
| 968 | <p id="rfc.section.8.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., |
|---|
| 969 | 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, |
|---|
| 970 | 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". |
|---|
| 971 | </p> |
|---|
| 972 | <p id="rfc.section.8.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which |
|---|
| 973 | request forwarding is permitted, the proxy <em class="bcp14">MUST</em> check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy <em class="bcp14">MUST NOT</em> forward the message; instead, the proxy <em class="bcp14">SHOULD</em> respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy <em class="bcp14">MUST</em> decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded |
|---|
| 974 | request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. |
|---|
| 975 | </p> |
|---|
| 976 | </div> |
|---|
| 977 | <div id="GET"> |
|---|
| 978 | <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a href="#GET">GET</a></h2> |
|---|
| 979 | <div id="rfc.iref.g.8"></div> |
|---|
| 980 | <div id="rfc.iref.m.2"></div> |
|---|
| 981 | <p id="rfc.section.8.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI |
|---|
| 982 | refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not |
|---|
| 983 | the source text of the process, unless that text happens to be the output of the process. |
|---|
| 984 | </p> |
|---|
| 985 | <p id="rfc.section.8.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, |
|---|
| 986 | If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under |
|---|
| 987 | the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary |
|---|
| 988 | network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already |
|---|
| 989 | held by the client. |
|---|
| 990 | </p> |
|---|
| 991 | <p id="rfc.section.8.3.p.3">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial |
|---|
| 992 | GET requests that only part of the entity be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 6.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 method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed |
|---|
| 993 | without transferring data already held by the client. |
|---|
| 994 | </p> |
|---|
| 995 | <p id="rfc.section.8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. |
|---|
| 996 | </p> |
|---|
| 997 | <p id="rfc.section.8.3.p.5">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. |
|---|
| 998 | </p> |
|---|
| 999 | </div> |
|---|
| 1000 | <div id="HEAD"> |
|---|
| 1001 | <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a href="#HEAD">HEAD</a></h2> |
|---|
| 1002 | <div id="rfc.iref.h.1"></div> |
|---|
| 1003 | <div id="rfc.iref.m.3"></div> |
|---|
| 1004 | <p id="rfc.section.8.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 metainformation contained in the HTTP headers 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 metainformation about |
|---|
| 1005 | the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext |
|---|
| 1006 | links for validity, accessibility, and recent modification. |
|---|
| 1007 | </p> |
|---|
| 1008 | <p id="rfc.section.8.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs |
|---|
| 1009 | from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the |
|---|
| 1010 | cache <em class="bcp14">MUST</em> treat the cache entry as stale. |
|---|
| 1011 | </p> |
|---|
| 1012 | </div> |
|---|
| 1013 | <div id="POST"> |
|---|
| 1014 | <div id="rfc.iref.p.1"></div> |
|---|
| 1015 | <div id="rfc.iref.m.4"></div> |
|---|
| 1016 | <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a href="#POST">POST</a></h2> |
|---|
| 1017 | <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed |
|---|
| 1018 | by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the |
|---|
| 1019 | following functions: |
|---|
| 1020 | </p> |
|---|
| 1021 | <ul> |
|---|
| 1022 | <li>Annotation of existing resources;</li> |
|---|
| 1023 | <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> |
|---|
| 1024 | <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> |
|---|
| 1025 | <li>Extending a database through an append operation.</li> |
|---|
| 1026 | </ul> |
|---|
| 1027 | <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p> |
|---|
| 1028 | <p id="rfc.section.8.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 |
|---|
| 1029 | 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity |
|---|
| 1030 | that describes the result. |
|---|
| 1031 | </p> |
|---|
| 1032 | <p id="rfc.section.8.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 an entity which describes the status of the request and refers to the new resource, and a Location |
|---|
| 1033 | header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.4</a>). |
|---|
| 1034 | </p> |
|---|
| 1035 | <p id="rfc.section.8.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. |
|---|
| 1036 | However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. |
|---|
| 1037 | </p> |
|---|
| 1038 | </div> |
|---|
| 1039 | <div id="PUT"> |
|---|
| 1040 | <div id="rfc.iref.p.2"></div> |
|---|
| 1041 | <div id="rfc.iref.m.5"></div> |
|---|
| 1042 | <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a href="#PUT">PUT</a></h2> |
|---|
| 1043 | <p id="rfc.section.8.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied Request-URI. If the Request-URI refers to an already |
|---|
| 1044 | existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing |
|---|
| 1045 | resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create |
|---|
| 1046 | the resource with that URI. If a new resource is created at the Request-URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No |
|---|
| 1047 | Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, |
|---|
| 1048 | an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. |
|---|
| 1049 | </p> |
|---|
| 1050 | <p id="rfc.section.8.6.p.2">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. |
|---|
| 1051 | </p> |
|---|
| 1052 | <p id="rfc.section.8.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The |
|---|
| 1053 | URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting |
|---|
| 1054 | process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request |
|---|
| 1055 | identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, |
|---|
| 1056 | it <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. |
|---|
| 1057 | </p> |
|---|
| 1058 | <p id="rfc.section.8.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which |
|---|
| 1059 | is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in |
|---|
| 1060 | several other URIs being defined by the origin server. |
|---|
| 1061 | </p> |
|---|
| 1062 | <p id="rfc.section.8.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> |
|---|
| 1063 | <p id="rfc.section.8.6.p.6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. |
|---|
| 1064 | </p> |
|---|
| 1065 | </div> |
|---|
| 1066 | <div id="DELETE"> |
|---|
| 1067 | <div id="rfc.iref.d.1"></div> |
|---|
| 1068 | <div id="rfc.iref.m.6"></div> |
|---|
| 1069 | <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a href="#DELETE">DELETE</a></h2> |
|---|
| 1070 | <p id="rfc.section.8.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. 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 |
|---|
| 1071 | has been carried out, even if the status code returned from the origin server indicates that the action has been completed |
|---|
| 1072 | 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 |
|---|
| 1073 | location. |
|---|
| 1074 | </p> |
|---|
| 1075 | <p id="rfc.section.8.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, |
|---|
| 1076 | or 204 (No Content) if the action has been enacted but the response does not include an entity. |
|---|
| 1077 | </p> |
|---|
| 1078 | <p id="rfc.section.8.7.p.3">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. |
|---|
| 1079 | </p> |
|---|
| 1080 | </div> |
|---|
| 1081 | <div id="TRACE"> |
|---|
| 1082 | <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a href="#TRACE">TRACE</a></h2> |
|---|
| 1083 | <div id="rfc.iref.t.1"></div> |
|---|
| 1084 | <div id="rfc.iref.m.7"></div> |
|---|
| 1085 | <p id="rfc.section.8.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the |
|---|
| 1086 | request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the |
|---|
| 1087 | origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity. |
|---|
| 1088 | </p> |
|---|
| 1089 | <p id="rfc.section.8.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 |
|---|
| 1090 | or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the |
|---|
| 1091 | client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an |
|---|
| 1092 | infinite loop. |
|---|
| 1093 | </p> |
|---|
| 1094 | <p id="rfc.section.8.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with 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.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached. |
|---|
| 1095 | </p> |
|---|
| 1096 | </div> |
|---|
| 1097 | <div id="CONNECT"> |
|---|
| 1098 | <div id="rfc.iref.c.1"></div> |
|---|
| 1099 | <div id="rfc.iref.m.8"></div> |
|---|
| 1100 | <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a href="#CONNECT">CONNECT</a></h2> |
|---|
| 1101 | <p id="rfc.section.8.9.p.1">This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. |
|---|
| 1102 | SSL tunneling <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). |
|---|
| 1103 | </p> |
|---|
| 1104 | </div> |
|---|
| 1105 | </div> |
|---|
| 1106 | <div id="status.codes"> |
|---|
| 1107 | <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#status.codes">Status Code Definitions</a></h1> |
|---|
| 1108 | <p id="rfc.section.9.p.1">Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required |
|---|
| 1109 | in the response. |
|---|
| 1110 | </p> |
|---|
| 1111 | <div id="status.1xx"> |
|---|
| 1112 | <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a href="#status.1xx">Informational 1xx</a></h2> |
|---|
| 1113 | <p id="rfc.section.9.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is |
|---|
| 1114 | terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any |
|---|
| 1115 | 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. |
|---|
| 1116 | </p> |
|---|
| 1117 | <p id="rfc.section.9.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 |
|---|
| 1118 | (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. |
|---|
| 1119 | </p> |
|---|
| 1120 | <p id="rfc.section.9.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 |
|---|
| 1121 | requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards |
|---|
| 1122 | a request, then it need not forward the corresponding 100 (Continue) response(s).) |
|---|
| 1123 | </p> |
|---|
| 1124 | <div id="status.100"> |
|---|
| 1125 | <div id="rfc.iref.1.1"></div> |
|---|
| 1126 | <div id="rfc.iref.s.2"></div> |
|---|
| 1127 | <h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a href="#status.100">100 Continue</a></h3> |
|---|
| 1128 | <p id="rfc.section.9.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 |
|---|
| 1129 | 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 |
|---|
| 1130 | 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 7.2.3</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> for detailed discussion of the use and handling of this status code. |
|---|
| 1131 | </p> |
|---|
| 1132 | </div> |
|---|
| 1133 | <div id="status.101"> |
|---|
| 1134 | <div id="rfc.iref.1.2"></div> |
|---|
| 1135 | <div id="rfc.iref.s.3"></div> |
|---|
| 1136 | <h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a> <a href="#status.101">101 Switching Protocols</a></h3> |
|---|
| 1137 | <p id="rfc.section.9.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="p5-range.html#header.range" title="Range">Section 6.4</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined |
|---|
| 1138 | by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
|---|
| 1139 | </p> |
|---|
| 1140 | <p id="rfc.section.9.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 |
|---|
| 1141 | older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use |
|---|
| 1142 | such features. |
|---|
| 1143 | </p> |
|---|
| 1144 | </div> |
|---|
| 1145 | </div> |
|---|
| 1146 | <div id="status.2xx"> |
|---|
| 1147 | <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a href="#status.2xx">Successful 2xx</a></h2> |
|---|
| 1148 | <p id="rfc.section.9.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> |
|---|
| 1149 | <div id="status.200"> |
|---|
| 1150 | <div id="rfc.iref.2.1"></div> |
|---|
| 1151 | <div id="rfc.iref.s.4"></div> |
|---|
| 1152 | <h3 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a> <a href="#status.200">200 OK</a></h3> |
|---|
| 1153 | <p id="rfc.section.9.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for |
|---|
| 1154 | example: |
|---|
| 1155 | </p> |
|---|
| 1156 | <dl> |
|---|
| 1157 | <dt>GET</dt> |
|---|
| 1158 | <dd>an entity corresponding to the requested resource is sent in the response;</dd> |
|---|
| 1159 | <dt>HEAD</dt> |
|---|
| 1160 | <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd> |
|---|
| 1161 | <dt>POST</dt> |
|---|
| 1162 | <dd>an entity describing or containing the result of the action;</dd> |
|---|
| 1163 | <dt>TRACE</dt> |
|---|
| 1164 | <dd>an entity containing the request message as received by the end server.</dd> |
|---|
| 1165 | </dl> |
|---|
| 1166 | </div> |
|---|
| 1167 | <div id="status.201"> |
|---|
| 1168 | <div id="rfc.iref.2.2"></div> |
|---|
| 1169 | <div id="rfc.iref.s.5"></div> |
|---|
| 1170 | <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a> <a href="#status.201">201 Created</a></h3> |
|---|
| 1171 | <p id="rfc.section.9.2.2.p.1">The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced |
|---|
| 1172 | by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header |
|---|
| 1173 | field. The response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose |
|---|
| 1174 | the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin |
|---|
| 1175 | 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. |
|---|
| 1176 | </p> |
|---|
| 1177 | <p id="rfc.section.9.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, |
|---|
| 1178 | see <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. |
|---|
| 1179 | </p> |
|---|
| 1180 | </div> |
|---|
| 1181 | <div id="status.202"> |
|---|
| 1182 | <div id="rfc.iref.2.3"></div> |
|---|
| 1183 | <div id="rfc.iref.s.6"></div> |
|---|
| 1184 | <h3 id="rfc.section.9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a> <a href="#status.202">202 Accepted</a></h3> |
|---|
| 1185 | <p id="rfc.section.9.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 |
|---|
| 1186 | be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status |
|---|
| 1187 | code from an asynchronous operation such as this. |
|---|
| 1188 | </p> |
|---|
| 1189 | <p id="rfc.section.9.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 |
|---|
| 1190 | (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the |
|---|
| 1191 | server persist until the process is completed. The entity 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 |
|---|
| 1192 | user can expect the request to be fulfilled. |
|---|
| 1193 | </p> |
|---|
| 1194 | </div> |
|---|
| 1195 | <div id="status.203"> |
|---|
| 1196 | <div id="rfc.iref.2.4"></div> |
|---|
| 1197 | <div id="rfc.iref.s.7"></div> |
|---|
| 1198 | <h3 id="rfc.section.9.2.4"><a href="#rfc.section.9.2.4">9.2.4</a> <a href="#status.203">203 Non-Authoritative Information</a></h3> |
|---|
| 1199 | <p id="rfc.section.9.2.4.p.1">The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered |
|---|
| 1200 | from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might |
|---|
| 1201 | result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only |
|---|
| 1202 | appropriate when the response would otherwise be 200 (OK). |
|---|
| 1203 | </p> |
|---|
| 1204 | </div> |
|---|
| 1205 | <div id="status.204"> |
|---|
| 1206 | <div id="rfc.iref.2.5"></div> |
|---|
| 1207 | <div id="rfc.iref.s.8"></div> |
|---|
| 1208 | <h3 id="rfc.section.9.2.5"><a href="#rfc.section.9.2.5">9.2.5</a> <a href="#status.204">204 No Content</a></h3> |
|---|
| 1209 | <p id="rfc.section.9.2.5.p.1">The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. |
|---|
| 1210 | The response <em class="bcp14">MAY</em> include new or updated metainformation in the form of entity-headers, which if present <em class="bcp14">SHOULD</em> be associated with the requested variant. |
|---|
| 1211 | </p> |
|---|
| 1212 | <p id="rfc.section.9.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input |
|---|
| 1213 | for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation <em class="bcp14">SHOULD</em> be applied to the document currently in the user agent's active view. |
|---|
| 1214 | </p> |
|---|
| 1215 | <p id="rfc.section.9.2.5.p.3">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. |
|---|
| 1216 | </p> |
|---|
| 1217 | </div> |
|---|
| 1218 | <div id="status.205"> |
|---|
| 1219 | <div id="rfc.iref.2.6"></div> |
|---|
| 1220 | <div id="rfc.iref.s.9"></div> |
|---|
| 1221 | <h3 id="rfc.section.9.2.6"><a href="#rfc.section.9.2.6">9.2.6</a> <a href="#status.205">205 Reset Content</a></h3> |
|---|
| 1222 | <p id="rfc.section.9.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 |
|---|
| 1223 | 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 |
|---|
| 1224 | another input action. The response <em class="bcp14">MUST NOT</em> include an entity. |
|---|
| 1225 | </p> |
|---|
| 1226 | </div> |
|---|
| 1227 | <div id="status.206"> |
|---|
| 1228 | <div id="rfc.iref.2.7"></div> |
|---|
| 1229 | <div id="rfc.iref.s.10"></div> |
|---|
| 1230 | <h3 id="rfc.section.9.2.7"><a href="#rfc.section.9.2.7">9.2.7</a> <a href="#status.206">206 Partial Content</a></h3> |
|---|
| 1231 | <p id="rfc.section.9.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined |
|---|
| 1232 | in <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. |
|---|
| 1233 | </p> |
|---|
| 1234 | </div> |
|---|
| 1235 | </div> |
|---|
| 1236 | <div id="status.3xx"> |
|---|
| 1237 | <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a href="#status.3xx">Redirection 3xx</a></h2> |
|---|
| 1238 | <p id="rfc.section.9.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. |
|---|
| 1239 | The action required <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 |
|---|
| 1240 | GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. |
|---|
| 1241 | </p> |
|---|
| 1242 | <ul class="empty"> |
|---|
| 1243 | <li><b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that |
|---|
| 1244 | there might be clients that implement such a fixed limitation. |
|---|
| 1245 | </li> |
|---|
| 1246 | </ul> |
|---|
| 1247 | <div id="status.300"> |
|---|
| 1248 | <div id="rfc.iref.3.1"></div> |
|---|
| 1249 | <div id="rfc.iref.s.11"></div> |
|---|
| 1250 | <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a href="#status.300">300 Multiple Choices</a></h3> |
|---|
| 1251 | <p id="rfc.section.9.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven |
|---|
| 1252 | negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</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>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that |
|---|
| 1253 | location. |
|---|
| 1254 | </p> |
|---|
| 1255 | <p id="rfc.section.9.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose |
|---|
| 1256 | the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending |
|---|
| 1257 | upon the format and the capabilities of the user agent, selection 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. |
|---|
| 1258 | </p> |
|---|
| 1259 | <p id="rfc.section.9.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. This response is cacheable unless indicated otherwise. |
|---|
| 1260 | </p> |
|---|
| 1261 | </div> |
|---|
| 1262 | <div id="status.301"> |
|---|
| 1263 | <div id="rfc.iref.3.2"></div> |
|---|
| 1264 | <div id="rfc.iref.s.12"></div> |
|---|
| 1265 | <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a href="#status.301">301 Moved Permanently</a></h3> |
|---|
| 1266 | <p id="rfc.section.9.3.2.p.1">The requested 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 Request-URI |
|---|
| 1267 | to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. |
|---|
| 1268 | </p> |
|---|
| 1269 | <p id="rfc.section.9.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). |
|---|
| 1270 | </p> |
|---|
| 1271 | <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which |
|---|
| 1272 | the request was issued. |
|---|
| 1273 | </p> |
|---|
| 1274 | <ul class="empty"> |
|---|
| 1275 | <li><b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously |
|---|
| 1276 | change it into a GET request. |
|---|
| 1277 | </li> |
|---|
| 1278 | </ul> |
|---|
| 1279 | </div> |
|---|
| 1280 | <div id="status.302"> |
|---|
| 1281 | <div id="rfc.iref.3.3"></div> |
|---|
| 1282 | <div id="rfc.iref.s.13"></div> |
|---|
| 1283 | <h3 id="rfc.section.9.3.3"><a href="#rfc.section.9.3.3">9.3.3</a> <a href="#status.302">302 Found</a></h3> |
|---|
| 1284 | <p id="rfc.section.9.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the |
|---|
| 1285 | client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires |
|---|
| 1286 | header field. |
|---|
| 1287 | </p> |
|---|
| 1288 | <p id="rfc.section.9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). |
|---|
| 1289 | </p> |
|---|
| 1290 | <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which |
|---|
| 1291 | the request was issued. |
|---|
| 1292 | </p> |
|---|
| 1293 | <ul class="empty"> |
|---|
| 1294 | <li><b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations |
|---|
| 1295 | treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. |
|---|
| 1296 | The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected |
|---|
| 1297 | of the client. |
|---|
| 1298 | </li> |
|---|
| 1299 | </ul> |
|---|
| 1300 | </div> |
|---|
| 1301 | <div id="status.303"> |
|---|
| 1302 | <div id="rfc.iref.3.4"></div> |
|---|
| 1303 | <div id="rfc.iref.s.14"></div> |
|---|
| 1304 | <h3 id="rfc.section.9.3.4"><a href="#rfc.section.9.3.4">9.3.4</a> <a href="#status.303">303 See Other</a></h3> |
|---|
| 1305 | <p id="rfc.section.9.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides |
|---|
| 1306 | an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response, |
|---|
| 1307 | be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested |
|---|
| 1308 | resource. |
|---|
| 1309 | </p> |
|---|
| 1310 | <p id="rfc.section.9.3.4.p.2">The 303 status is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect |
|---|
| 1311 | the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form |
|---|
| 1312 | that can be separately identified, bookmarked, and cached independent of the original request. |
|---|
| 1313 | </p> |
|---|
| 1314 | <p id="rfc.section.9.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 |
|---|
| 1315 | transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such |
|---|
| 1316 | that the follow-on representation may be useful without implying that it adequately represents the previously requested resource. |
|---|
| 1317 | Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful |
|---|
| 1318 | description are outside the scope of HTTP and thus entirely determined by the resource owner(s). |
|---|
| 1319 | </p> |
|---|
| 1320 | <p id="rfc.section.9.3.4.p.4">A 303 response <em class="bcp14">SHOULD NOT</em> be cached unless it is indicated as cacheable by Cache-Control or Expires header fields. Except for responses to a HEAD request, |
|---|
| 1321 | the entity of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI. |
|---|
| 1322 | </p> |
|---|
| 1323 | </div> |
|---|
| 1324 | <div id="status.304"> |
|---|
| 1325 | <div id="rfc.iref.3.5"></div> |
|---|
| 1326 | <div id="rfc.iref.s.15"></div> |
|---|
| 1327 | <h3 id="rfc.section.9.3.5"><a href="#rfc.section.9.3.5">9.3.5</a> <a href="#status.304">304 Not Modified</a></h3> |
|---|
| 1328 | <p id="rfc.section.9.3.5.p.1">The response to the request has not been modified since the conditions indicated by the client's conditional GET request, |
|---|
| 1329 | as defined in <a href="#Part4" id="rfc.xref.Part4.12"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. |
|---|
| 1330 | </p> |
|---|
| 1331 | </div> |
|---|
| 1332 | <div id="status.305"> |
|---|
| 1333 | <div id="rfc.iref.3.6"></div> |
|---|
| 1334 | <div id="rfc.iref.s.16"></div> |
|---|
| 1335 | <h3 id="rfc.section.9.3.6"><a href="#rfc.section.9.3.6">9.3.6</a> <a href="#status.305">305 Use Proxy</a></h3> |
|---|
| 1336 | <p id="rfc.section.9.3.6.p.1">The 305 status was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix A.2</a>), and is now deprecated. |
|---|
| 1337 | </p> |
|---|
| 1338 | </div> |
|---|
| 1339 | <div id="status.306"> |
|---|
| 1340 | <div id="rfc.iref.3.7"></div> |
|---|
| 1341 | <div id="rfc.iref.s.17"></div> |
|---|
| 1342 | <h3 id="rfc.section.9.3.7"><a href="#rfc.section.9.3.7">9.3.7</a> <a href="#status.306">306 (Unused)</a></h3> |
|---|
| 1343 | <p id="rfc.section.9.3.7.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> |
|---|
| 1344 | </div> |
|---|
| 1345 | <div id="status.307"> |
|---|
| 1346 | <div id="rfc.iref.3.8"></div> |
|---|
| 1347 | <div id="rfc.iref.s.18"></div> |
|---|
| 1348 | <h3 id="rfc.section.9.3.8"><a href="#rfc.section.9.3.8">9.3.8</a> <a href="#status.307">307 Temporary Redirect</a></h3> |
|---|
| 1349 | <p id="rfc.section.9.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires |
|---|
| 1350 | header field. |
|---|
| 1351 | </p> |
|---|
| 1352 | <p id="rfc.section.9.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand |
|---|
| 1353 | the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI. |
|---|
| 1354 | </p> |
|---|
| 1355 | <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which |
|---|
| 1356 | the request was issued. |
|---|
| 1357 | </p> |
|---|
| 1358 | </div> |
|---|
| 1359 | </div> |
|---|
| 1360 | <div id="status.4xx"> |
|---|
| 1361 | <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a href="#status.4xx">Client Error 4xx</a></h2> |
|---|
| 1362 | <p id="rfc.section.9.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 |
|---|
| 1363 | request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
|---|
| 1364 | These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user. |
|---|
| 1365 | </p> |
|---|
| 1366 | <p id="rfc.section.9.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes |
|---|
| 1367 | the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send |
|---|
| 1368 | a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted |
|---|
| 1369 | by the HTTP application. |
|---|
| 1370 | </p> |
|---|
| 1371 | <div id="status.400"> |
|---|
| 1372 | <div id="rfc.iref.4.1"></div> |
|---|
| 1373 | <div id="rfc.iref.s.19"></div> |
|---|
| 1374 | <h3 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1</a> <a href="#status.400">400 Bad Request</a></h3> |
|---|
| 1375 | <p id="rfc.section.9.4.1.p.1">The request could not be understood by the server due to malformed syntax. The client <em class="bcp14">SHOULD NOT</em> repeat the request without modifications. |
|---|
| 1376 | </p> |
|---|
| 1377 | </div> |
|---|
| 1378 | <div id="status.401"> |
|---|
| 1379 | <div id="rfc.iref.4.2"></div> |
|---|
| 1380 | <div id="rfc.iref.s.20"></div> |
|---|
| 1381 | <h3 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a> <a href="#status.401">401 Unauthorized</a></h3> |
|---|
| 1382 | <p id="rfc.section.9.4.2.p.1">The request requires user authentication (see <a href="#Part7" id="rfc.xref.Part7.9"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). |
|---|
| 1383 | </p> |
|---|
| 1384 | </div> |
|---|
| 1385 | <div id="status.402"> |
|---|
| 1386 | <div id="rfc.iref.4.3"></div> |
|---|
| 1387 | <div id="rfc.iref.s.21"></div> |
|---|
| 1388 | <h3 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a> <a href="#status.402">402 Payment Required</a></h3> |
|---|
| 1389 | <p id="rfc.section.9.4.3.p.1">This code is reserved for future use.</p> |
|---|
| 1390 | </div> |
|---|
| 1391 | <div id="status.403"> |
|---|
| 1392 | <div id="rfc.iref.4.4"></div> |
|---|
| 1393 | <div id="rfc.iref.s.22"></div> |
|---|
| 1394 | <h3 id="rfc.section.9.4.4"><a href="#rfc.section.9.4.4">9.4.4</a> <a href="#status.403">403 Forbidden</a></h3> |
|---|
| 1395 | <p id="rfc.section.9.4.4.p.1">The server understood the request, but is refusing to fulfill it. Authorization will not help and the request <em class="bcp14">SHOULD NOT</em> be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, |
|---|
| 1396 | it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, |
|---|
| 1397 | the status code 404 (Not Found) can be used instead. |
|---|
| 1398 | </p> |
|---|
| 1399 | </div> |
|---|
| 1400 | <div id="status.404"> |
|---|
| 1401 | <div id="rfc.iref.4.5"></div> |
|---|
| 1402 | <div id="rfc.iref.s.23"></div> |
|---|
| 1403 | <h3 id="rfc.section.9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a> <a href="#status.404">404 Not Found</a></h3> |
|---|
| 1404 | <p id="rfc.section.9.4.5.p.1">The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or |
|---|
| 1405 | 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 |
|---|
| 1406 | and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request |
|---|
| 1407 | has been refused, or when no other response is applicable. |
|---|
| 1408 | </p> |
|---|
| 1409 | </div> |
|---|
| 1410 | <div id="status.405"> |
|---|
| 1411 | <div id="rfc.iref.4.6"></div> |
|---|
| 1412 | <div id="rfc.iref.s.24"></div> |
|---|
| 1413 | <h3 id="rfc.section.9.4.6"><a href="#rfc.section.9.4.6">9.4.6</a> <a href="#status.405">405 Method Not Allowed</a></h3> |
|---|
| 1414 | <p id="rfc.section.9.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. |
|---|
| 1415 | </p> |
|---|
| 1416 | </div> |
|---|
| 1417 | <div id="status.406"> |
|---|
| 1418 | <div id="rfc.iref.4.7"></div> |
|---|
| 1419 | <div id="rfc.iref.s.25"></div> |
|---|
| 1420 | <h3 id="rfc.section.9.4.7"><a href="#rfc.section.9.4.7">9.4.7</a> <a href="#status.406">406 Not Acceptable</a></h3> |
|---|
| 1421 | <p id="rfc.section.9.4.7.p.1">The resource identified by the request is only capable of generating response entities which have content characteristics |
|---|
| 1422 | not acceptable according to the accept headers sent in the request. |
|---|
| 1423 | </p> |
|---|
| 1424 | <p id="rfc.section.9.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent |
|---|
| 1425 | can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. |
|---|
| 1426 | Depending upon the format and the capabilities of the user agent, selection 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. |
|---|
| 1427 | </p> |
|---|
| 1428 | <ul class="empty"> |
|---|
| 1429 | <li><b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. |
|---|
| 1430 | In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of |
|---|
| 1431 | an incoming response to determine if it is acceptable. |
|---|
| 1432 | </li> |
|---|
| 1433 | </ul> |
|---|
| 1434 | <p id="rfc.section.9.4.7.p.3">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. |
|---|
| 1435 | </p> |
|---|
| 1436 | </div> |
|---|
| 1437 | <div id="status.407"> |
|---|
| 1438 | <div id="rfc.iref.4.8"></div> |
|---|
| 1439 | <div id="rfc.iref.s.26"></div> |
|---|
| 1440 | <h3 id="rfc.section.9.4.8"><a href="#rfc.section.9.4.8">9.4.8</a> <a href="#status.407">407 Proxy Authentication Required</a></h3> |
|---|
| 1441 | <p id="rfc.section.9.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy (see <a href="#Part7" id="rfc.xref.Part7.10"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). |
|---|
| 1442 | </p> |
|---|
| 1443 | </div> |
|---|
| 1444 | <div id="status.408"> |
|---|
| 1445 | <div id="rfc.iref.4.9"></div> |
|---|
| 1446 | <div id="rfc.iref.s.27"></div> |
|---|
| 1447 | <h3 id="rfc.section.9.4.9"><a href="#rfc.section.9.4.9">9.4.9</a> <a href="#status.408">408 Request Timeout</a></h3> |
|---|
| 1448 | <p id="rfc.section.9.4.9.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. |
|---|
| 1449 | </p> |
|---|
| 1450 | </div> |
|---|
| 1451 | <div id="status.409"> |
|---|
| 1452 | <div id="rfc.iref.4.10"></div> |
|---|
| 1453 | <div id="rfc.iref.s.28"></div> |
|---|
| 1454 | <h3 id="rfc.section.9.4.10"><a href="#rfc.section.9.4.10">9.4.10</a> <a href="#status.409">409 Conflict</a></h3> |
|---|
| 1455 | <p id="rfc.section.9.4.10.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 |
|---|
| 1456 | situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response |
|---|
| 1457 | body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include |
|---|
| 1458 | enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. |
|---|
| 1459 | </p> |
|---|
| 1460 | <p id="rfc.section.9.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity |
|---|
| 1461 | being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might |
|---|
| 1462 | use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain |
|---|
| 1463 | a list of the differences between the two versions in a format defined by the response Content-Type. |
|---|
| 1464 | </p> |
|---|
| 1465 | </div> |
|---|
| 1466 | <div id="status.410"> |
|---|
| 1467 | <div id="rfc.iref.4.11"></div> |
|---|
| 1468 | <div id="rfc.iref.s.29"></div> |
|---|
| 1469 | <h3 id="rfc.section.9.4.11"><a href="#rfc.section.9.4.11">9.4.11</a> <a href="#status.410">410 Gone</a></h3> |
|---|
| 1470 | <p id="rfc.section.9.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected |
|---|
| 1471 | to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether |
|---|
| 1472 | or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise. |
|---|
| 1473 | </p> |
|---|
| 1474 | <p id="rfc.section.9.4.11.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource |
|---|
| 1475 | is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event |
|---|
| 1476 | is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's |
|---|
| 1477 | site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time |
|---|
| 1478 | -- that is left to the discretion of the server owner. |
|---|
| 1479 | </p> |
|---|
| 1480 | </div> |
|---|
| 1481 | <div id="status.411"> |
|---|
| 1482 | <div id="rfc.iref.4.12"></div> |
|---|
| 1483 | <div id="rfc.iref.s.30"></div> |
|---|
| 1484 | <h3 id="rfc.section.9.4.12"><a href="#rfc.section.9.4.12">9.4.12</a> <a href="#status.411">411 Length Required</a></h3> |
|---|
| 1485 | <p id="rfc.section.9.4.12.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 |
|---|
| 1486 | message. |
|---|
| 1487 | </p> |
|---|
| 1488 | </div> |
|---|
| 1489 | <div id="status.412"> |
|---|
| 1490 | <div id="rfc.iref.4.13"></div> |
|---|
| 1491 | <div id="rfc.iref.s.31"></div> |
|---|
| 1492 | <h3 id="rfc.section.9.4.13"><a href="#rfc.section.9.4.13">9.4.13</a> <a href="#status.412">412 Precondition Failed</a></h3> |
|---|
| 1493 | <p id="rfc.section.9.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as |
|---|
| 1494 | defined in <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. |
|---|
| 1495 | </p> |
|---|
| 1496 | </div> |
|---|
| 1497 | <div id="status.413"> |
|---|
| 1498 | <div id="rfc.iref.4.14"></div> |
|---|
| 1499 | <div id="rfc.iref.s.32"></div> |
|---|
| 1500 | <h3 id="rfc.section.9.4.14"><a href="#rfc.section.9.4.14">9.4.14</a> <a href="#status.413">413 Request Entity Too Large</a></h3> |
|---|
| 1501 | <p id="rfc.section.9.4.14.p.1">The server is refusing to process a request because the request entity is larger than the server is willing or able to process. |
|---|
| 1502 | The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. |
|---|
| 1503 | </p> |
|---|
| 1504 | <p id="rfc.section.9.4.14.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. |
|---|
| 1505 | </p> |
|---|
| 1506 | </div> |
|---|
| 1507 | <div id="status.414"> |
|---|
| 1508 | <div id="rfc.iref.4.15"></div> |
|---|
| 1509 | <div id="rfc.iref.s.33"></div> |
|---|
| 1510 | <h3 id="rfc.section.9.4.15"><a href="#rfc.section.9.4.15">9.4.15</a> <a href="#status.414">414 Request-URI Too Long</a></h3> |
|---|
| 1511 | <p id="rfc.section.9.4.15.p.1">The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This |
|---|
| 1512 | rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query |
|---|
| 1513 | information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points |
|---|
| 1514 | to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some |
|---|
| 1515 | servers using fixed-length buffers for reading or manipulating the Request-URI. |
|---|
| 1516 | </p> |
|---|
| 1517 | </div> |
|---|
| 1518 | <div id="status.415"> |
|---|
| 1519 | <div id="rfc.iref.4.16"></div> |
|---|
| 1520 | <div id="rfc.iref.s.34"></div> |
|---|
| 1521 | <h3 id="rfc.section.9.4.16"><a href="#rfc.section.9.4.16">9.4.16</a> <a href="#status.415">415 Unsupported Media Type</a></h3> |
|---|
| 1522 | <p id="rfc.section.9.4.16.p.1">The server is refusing to service the request because the entity of the request is in a format not supported by the requested |
|---|
| 1523 | resource for the requested method. |
|---|
| 1524 | </p> |
|---|
| 1525 | </div> |
|---|
| 1526 | <div id="status.416"> |
|---|
| 1527 | <div id="rfc.iref.4.17"></div> |
|---|
| 1528 | <div id="rfc.iref.s.35"></div> |
|---|
| 1529 | <h3 id="rfc.section.9.4.17"><a href="#rfc.section.9.4.17">9.4.17</a> <a href="#status.416">416 Requested Range Not Satisfiable</a></h3> |
|---|
| 1530 | <p id="rfc.section.9.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 6.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. |
|---|
| 1531 | </p> |
|---|
| 1532 | </div> |
|---|
| 1533 | <div id="status.417"> |
|---|
| 1534 | <div id="rfc.iref.4.18"></div> |
|---|
| 1535 | <div id="rfc.iref.s.36"></div> |
|---|
| 1536 | <h3 id="rfc.section.9.4.18"><a href="#rfc.section.9.4.18">9.4.18</a> <a href="#status.417">417 Expectation Failed</a></h3> |
|---|
| 1537 | <p id="rfc.section.9.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could |
|---|
| 1538 | not be met by the next-hop server. |
|---|
| 1539 | </p> |
|---|
| 1540 | </div> |
|---|
| 1541 | </div> |
|---|
| 1542 | <div id="status.5xx"> |
|---|
| 1543 | <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a href="#status.5xx">Server Error 5xx</a></h2> |
|---|
| 1544 | <p id="rfc.section.9.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 |
|---|
| 1545 | of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. |
|---|
| 1546 | User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method. |
|---|
| 1547 | </p> |
|---|
| 1548 | <div id="status.500"> |
|---|
| 1549 | <div id="rfc.iref.5.1"></div> |
|---|
| 1550 | <div id="rfc.iref.s.37"></div> |
|---|
| 1551 | <h3 id="rfc.section.9.5.1"><a href="#rfc.section.9.5.1">9.5.1</a> <a href="#status.500">500 Internal Server Error</a></h3> |
|---|
| 1552 | <p id="rfc.section.9.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> |
|---|
| 1553 | </div> |
|---|
| 1554 | <div id="status.501"> |
|---|
| 1555 | <div id="rfc.iref.5.2"></div> |
|---|
| 1556 | <div id="rfc.iref.s.38"></div> |
|---|
| 1557 | <h3 id="rfc.section.9.5.2"><a href="#rfc.section.9.5.2">9.5.2</a> <a href="#status.501">501 Not Implemented</a></h3> |
|---|
| 1558 | <p id="rfc.section.9.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server |
|---|
| 1559 | does not recognize the request method and is not capable of supporting it for any resource. |
|---|
| 1560 | </p> |
|---|
| 1561 | </div> |
|---|
| 1562 | <div id="status.502"> |
|---|
| 1563 | <div id="rfc.iref.5.3"></div> |
|---|
| 1564 | <div id="rfc.iref.s.39"></div> |
|---|
| 1565 | <h3 id="rfc.section.9.5.3"><a href="#rfc.section.9.5.3">9.5.3</a> <a href="#status.502">502 Bad Gateway</a></h3> |
|---|
| 1566 | <p id="rfc.section.9.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 |
|---|
| 1567 | to fulfill the request. |
|---|
| 1568 | </p> |
|---|
| 1569 | </div> |
|---|
| 1570 | <div id="status.503"> |
|---|
| 1571 | <div id="rfc.iref.5.4"></div> |
|---|
| 1572 | <div id="rfc.iref.s.40"></div> |
|---|
| 1573 | <h3 id="rfc.section.9.5.4"><a href="#rfc.section.9.5.4">9.5.4</a> <a href="#status.503">503 Service Unavailable</a></h3> |
|---|
| 1574 | <p id="rfc.section.9.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication |
|---|
| 1575 | is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. |
|---|
| 1576 | </p> |
|---|
| 1577 | <ul class="empty"> |
|---|
| 1578 | <li><b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish |
|---|
| 1579 | to simply refuse the connection. |
|---|
| 1580 | </li> |
|---|
| 1581 | </ul> |
|---|
| 1582 | </div> |
|---|
| 1583 | <div id="status.504"> |
|---|
| 1584 | <div id="rfc.iref.5.5"></div> |
|---|
| 1585 | <div id="rfc.iref.s.41"></div> |
|---|
| 1586 | <h3 id="rfc.section.9.5.5"><a href="#rfc.section.9.5.5">9.5.5</a> <a href="#status.504">504 Gateway Timeout</a></h3> |
|---|
| 1587 | <p id="rfc.section.9.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 |
|---|
| 1588 | URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. |
|---|
| 1589 | </p> |
|---|
| 1590 | <ul class="empty"> |
|---|
| 1591 | <li><b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. |
|---|
| 1592 | </li> |
|---|
| 1593 | </ul> |
|---|
| 1594 | </div> |
|---|
| 1595 | <div id="status.505"> |
|---|
| 1596 | <div id="rfc.iref.5.6"></div> |
|---|
| 1597 | <div id="rfc.iref.s.42"></div> |
|---|
| 1598 | <h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a> <a href="#status.505">505 HTTP Version Not Supported</a></h3> |
|---|
| 1599 | <p id="rfc.section.9.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 |
|---|
| 1600 | is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described |
|---|
| 1601 | in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.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>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server. |
|---|
| 1602 | </p> |
|---|
| 1603 | </div> |
|---|
| 1604 | </div> |
|---|
| 1605 | </div> |
|---|
| 1606 | <div id="header.fields"> |
|---|
| 1607 | <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a href="#header.fields">Header Field Definitions</a></h1> |
|---|
| 1608 | <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> |
|---|
| 1609 | <p id="rfc.section.10.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who |
|---|
| 1610 | receives the entity. |
|---|
| 1611 | </p> |
|---|
| 1612 | <div id="header.allow"> |
|---|
| 1613 | <div id="rfc.iref.a.1"></div> |
|---|
| 1614 | <div id="rfc.iref.h.2"></div> |
|---|
| 1615 | <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a href="#header.allow">Allow</a></h2> |
|---|
| 1616 | <p id="rfc.section.10.1.p.1">The Allow response-header field lists the set of methods advertised as supported by the resource identified by the Request-URI. |
|---|
| 1617 | The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header |
|---|
| 1618 | field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. |
|---|
| 1619 | </p> |
|---|
| 1620 | <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" #<a href="#method" class="smpl">Method</a> |
|---|
| 1621 | </pre><p id="rfc.section.10.1.p.3">Example of use:</p> |
|---|
| 1622 | <div id="rfc.figure.u.14"></div><pre class="text"> Allow: GET, HEAD, PUT |
|---|
| 1623 | </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> |
|---|
| 1624 | <p id="rfc.section.10.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other |
|---|
| 1625 | means of communicating with the origin server. |
|---|
| 1626 | </p> |
|---|
| 1627 | </div> |
|---|
| 1628 | <div id="header.expect"> |
|---|
| 1629 | <div id="rfc.iref.e.1"></div> |
|---|
| 1630 | <div id="rfc.iref.h.3"></div> |
|---|
| 1631 | <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a href="#header.expect">Expect</a></h2> |
|---|
| 1632 | <p id="rfc.section.10.2.p.1">The Expect request-header field is used to indicate that particular server behaviors are required by the client.</p> |
|---|
| 1633 | <div id="rfc.figure.u.15"></div><pre class="inline"><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> <a href="#header.expect" class="smpl">Expect</a> = "Expect" ":" 1#<a href="#header.expect" class="smpl">expectation</a> |
|---|
| 1634 | |
|---|
| 1635 | <a href="#header.expect" class="smpl">expectation</a> = "100-continue" | <a href="#header.expect" class="smpl">expectation-extension</a> |
|---|
| 1636 | <a href="#header.expect" class="smpl">expectation-extension</a> = <a href="#notation" class="smpl">token</a> [ "=" ( <a href="#notation" class="smpl">token</a> | <a href="#notation" class="smpl">quoted-string</a> ) |
|---|
| 1637 | *<a href="#header.expect" class="smpl">expect-params</a> ] |
|---|
| 1638 | <a href="#header.expect" class="smpl">expect-params</a> = ";" <a href="#notation" class="smpl">token</a> [ "=" ( <a href="#notation" class="smpl">token</a> | <a href="#notation" class="smpl">quoted-string</a> ) ] |
|---|
| 1639 | </pre><p id="rfc.section.10.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with |
|---|
| 1640 | the request, some other 4xx status. |
|---|
| 1641 | </p> |
|---|
| 1642 | <p id="rfc.section.10.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing |
|---|
| 1643 | an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status. |
|---|
| 1644 | </p> |
|---|
| 1645 | <p id="rfc.section.10.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive |
|---|
| 1646 | for quoted-string expectation-extensions. |
|---|
| 1647 | </p> |
|---|
| 1648 | <p id="rfc.section.10.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect |
|---|
| 1649 | request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. |
|---|
| 1650 | </p> |
|---|
| 1651 | <p id="rfc.section.10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> |
|---|
| 1652 | <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</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> for the use of the 100 (Continue) status. |
|---|
| 1653 | </p> |
|---|
| 1654 | </div> |
|---|
| 1655 | <div id="header.from"> |
|---|
| 1656 | <div id="rfc.iref.f.1"></div> |
|---|
| 1657 | <div id="rfc.iref.h.4"></div> |
|---|
| 1658 | <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a href="#header.from">From</a></h2> |
|---|
| 1659 | <p id="rfc.section.10.3.p.1">The From request-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="https://tools.ietf.org/html/rfc2822#section-3.4">Section 3.4</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.1"><cite title="Internet Message Format">[RFC2822]</cite></a>: |
|---|
| 1660 | </p> |
|---|
| 1661 | <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.14"></span> <a href="#header.from" class="smpl">From</a> = "From" ":" <a href="#header.from" class="smpl">mailbox</a> |
|---|
| 1662 | |
|---|
| 1663 | <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC2822" id="rfc.xref.RFC2822.2"><cite title="Internet Message Format">[RFC2822]</cite></a>, <a href="https://tools.ietf.org/html/rfc2822#section-3.4">Section 3.4</a>> |
|---|
| 1664 | </pre><p id="rfc.section.10.3.p.3">An example is:</p> |
|---|
| 1665 | <div id="rfc.figure.u.17"></div><pre class="text"> From: webmaster@example.org |
|---|
| 1666 | </pre><p id="rfc.section.10.3.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 |
|---|
| 1667 | 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 so that the person responsible for running the robot can be contacted if problems occur on the receiving |
|---|
| 1668 | end. |
|---|
| 1669 | </p> |
|---|
| 1670 | <p id="rfc.section.10.3.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 |
|---|
| 1671 | issuer's address <em class="bcp14">SHOULD</em> be used. |
|---|
| 1672 | </p> |
|---|
| 1673 | <p id="rfc.section.10.3.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 |
|---|
| 1674 | security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at |
|---|
| 1675 | any time prior to a request. |
|---|
| 1676 | </p> |
|---|
| 1677 | </div> |
|---|
| 1678 | <div id="header.location"> |
|---|
| 1679 | <div id="rfc.iref.l.1"></div> |
|---|
| 1680 | <div id="rfc.iref.h.5"></div> |
|---|
| 1681 | <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a href="#header.location">Location</a></h2> |
|---|
| 1682 | <p id="rfc.section.10.4.p.1">The Location response-header field is used for the identification of a new resource or to redirect the recipient to a location |
|---|
| 1683 | other than the Request-URI for completion of the request. For 201 (Created) responses, the Location is that of the new resource |
|---|
| 1684 | which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute |
|---|
| 1685 | URI. |
|---|
| 1686 | </p> |
|---|
| 1687 | <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.15"></span> <a href="#header.location" class="smpl">Location</a> = "Location" ":" <a href="#abnf.dependencies" class="smpl">absoluteURI</a> [ "#" <a href="#abnf.dependencies" class="smpl">fragment</a> ] |
|---|
| 1688 | </pre><p id="rfc.section.10.4.p.3">An example is:</p> |
|---|
| 1689 | <div id="rfc.figure.u.19"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html |
|---|
| 1690 | </pre><p id="rfc.section.10.4.p.5"></p> |
|---|
| 1691 | <ul class="empty"> |
|---|
| 1692 | <li><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.11"><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 original location of the entity enclosed in the response. |
|---|
| 1693 | It is therefore possible for a response to contain header fields for both Location and Content-Location. |
|---|
| 1694 | </li> |
|---|
| 1695 | </ul> |
|---|
| 1696 | <p id="rfc.section.10.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p> |
|---|
| 1697 | <ul> |
|---|
| 1698 | <li>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</li> |
|---|
| 1699 | <li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment |
|---|
| 1700 | characteristics. |
|---|
| 1701 | </li> |
|---|
| 1702 | <li>With 305 Use Proxy.</li> |
|---|
| 1703 | </ul> |
|---|
| 1704 | </div> |
|---|
| 1705 | <div id="header.max-forwards"> |
|---|
| 1706 | <div id="rfc.iref.m.9"></div> |
|---|
| 1707 | <div id="rfc.iref.h.6"></div> |
|---|
| 1708 | <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a href="#header.max-forwards">Max-Forwards</a></h2> |
|---|
| 1709 | <p id="rfc.section.10.5.p.1">The Max-Forwards request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 8.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 8.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be |
|---|
| 1710 | useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. |
|---|
| 1711 | </p> |
|---|
| 1712 | <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = "Max-Forwards" ":" 1*<a href="#notation" class="smpl">DIGIT</a> |
|---|
| 1713 | </pre><p id="rfc.section.10.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p> |
|---|
| 1714 | <p id="rfc.section.10.5.p.4">Each proxy or gateway 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). |
|---|
| 1715 | </p> |
|---|
| 1716 | <p id="rfc.section.10.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly |
|---|
| 1717 | referred to as part of that method definition. |
|---|
| 1718 | </p> |
|---|
| 1719 | </div> |
|---|
| 1720 | <div id="header.referer"> |
|---|
| 1721 | <div id="rfc.iref.r.1"></div> |
|---|
| 1722 | <div id="rfc.iref.h.7"></div> |
|---|
| 1723 | <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a href="#header.referer">Referer</a></h2> |
|---|
| 1724 | <p id="rfc.section.10.6.p.1">The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource |
|---|
| 1725 | from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header |
|---|
| 1726 | allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows |
|---|
| 1727 | obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. |
|---|
| 1728 | </p> |
|---|
| 1729 | <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#header.referer" class="smpl">Referer</a> = "Referer" ":" ( <a href="#abnf.dependencies" class="smpl">absoluteURI</a> | <a href="#abnf.dependencies" class="smpl">relativeURI</a> ) |
|---|
| 1730 | </pre><p id="rfc.section.10.6.p.3">Example:</p> |
|---|
| 1731 | <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html |
|---|
| 1732 | </pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the 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. |
|---|
| 1733 | </p> |
|---|
| 1734 | </div> |
|---|
| 1735 | <div id="header.retry-after"> |
|---|
| 1736 | <div id="rfc.iref.r.2"></div> |
|---|
| 1737 | <div id="rfc.iref.h.8"></div> |
|---|
| 1738 | <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a href="#header.retry-after">Retry-After</a></h2> |
|---|
| 1739 | <p id="rfc.section.10.7.p.1">The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service |
|---|
| 1740 | is expected 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 wait before issuing |
|---|
| 1741 | the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after |
|---|
| 1742 | the time of the response. |
|---|
| 1743 | </p> |
|---|
| 1744 | <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.18"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = "Retry-After" ":" ( <a href="#abnf.dependencies" class="smpl">HTTP-date</a> | <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> ) |
|---|
| 1745 | </pre><div id="rule.delta-seconds"> |
|---|
| 1746 | <p id="rfc.section.10.7.p.3"> Time spans are non-negative decimal integers, representing time in seconds.</p> |
|---|
| 1747 | </div> |
|---|
| 1748 | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.19"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> |
|---|
| 1749 | </pre><p id="rfc.section.10.7.p.5">Two examples of its use are</p> |
|---|
| 1750 | <div id="rfc.figure.u.25"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
|---|
| 1751 | Retry-After: 120 |
|---|
| 1752 | </pre><p id="rfc.section.10.7.p.7">In the latter example, the delay is 2 minutes.</p> |
|---|
| 1753 | </div> |
|---|
| 1754 | <div id="header.server"> |
|---|
| 1755 | <div id="rfc.iref.s.43"></div> |
|---|
| 1756 | <div id="rfc.iref.h.9"></div> |
|---|
| 1757 | <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a href="#header.server">Server</a></h2> |
|---|
| 1758 | <p id="rfc.section.10.8.p.1">The Server response-header field contains information about the software used by the origin server to handle the request. |
|---|
| 1759 | The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance |
|---|
| 1760 | for identifying the application. |
|---|
| 1761 | </p> |
|---|
| 1762 | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.20"></span> <a href="#header.server" class="smpl">Server</a> = "Server" ":" 1*( <a href="#abnf.dependencies" class="smpl">product</a> | <a href="#notation" class="smpl">comment</a> ) |
|---|
| 1763 | </pre><p id="rfc.section.10.8.p.3">Example:</p> |
|---|
| 1764 | <div id="rfc.figure.u.27"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 |
|---|
| 1765 | </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. 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.9</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>). |
|---|
| 1766 | </p> |
|---|
| 1767 | <ul class="empty"> |
|---|
| 1768 | <li><b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks |
|---|
| 1769 | against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable |
|---|
| 1770 | option. |
|---|
| 1771 | </li> |
|---|
| 1772 | </ul> |
|---|
| 1773 | </div> |
|---|
| 1774 | <div id="header.user-agent"> |
|---|
| 1775 | <div id="rfc.iref.u.1"></div> |
|---|
| 1776 | <div id="rfc.iref.h.10"></div> |
|---|
| 1777 | <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a href="#header.user-agent">User-Agent</a></h2> |
|---|
| 1778 | <p id="rfc.section.10.9.p.1">The User-Agent request-header field contains information about the user agent originating the request. This is for statistical |
|---|
| 1779 | purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses |
|---|
| 1780 | to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the |
|---|
| 1781 | product tokens are listed in order of their significance for identifying the application. |
|---|
| 1782 | </p> |
|---|
| 1783 | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = "User-Agent" ":" 1*( <a href="#abnf.dependencies" class="smpl">product</a> | <a href="#notation" class="smpl">comment</a> ) |
|---|
| 1784 | </pre><p id="rfc.section.10.9.p.3">Example:</p> |
|---|
| 1785 | <div id="rfc.figure.u.29"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
|---|
| 1786 | </pre></div> |
|---|
| 1787 | </div> |
|---|
| 1788 | <div id="IANA.considerations"> |
|---|
| 1789 | <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a href="#IANA.considerations">IANA Considerations</a></h1> |
|---|
| 1790 | <div id="method.registration"> |
|---|
| 1791 | <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a href="#method.registration">Method Registry</a></h2> |
|---|
| 1792 | <p id="rfc.section.11.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section 3.1</a> of this document. |
|---|
| 1793 | </p> |
|---|
| 1794 | <p id="rfc.section.11.1.p.2">The HTTP Method Registry located at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> should be populated with the registrations below: |
|---|
| 1795 | </p> |
|---|
| 1796 | <div id="rfc.table.1"> |
|---|
| 1797 | <div id="iana.method.registration.table"></div> |
|---|
| 1798 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
|---|
| 1799 | <thead> |
|---|
| 1800 | <tr> |
|---|
| 1801 | <th>Method</th> |
|---|
| 1802 | <th>Safe</th> |
|---|
| 1803 | <th>Reference</th> |
|---|
| 1804 | </tr> |
|---|
| 1805 | </thead> |
|---|
| 1806 | <tbody> |
|---|
| 1807 | <tr> |
|---|
| 1808 | <td class="left">CONNECT</td> |
|---|
| 1809 | <td class="left">no</td> |
|---|
| 1810 | <td class="left"><a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 8.9</a> |
|---|
| 1811 | </td> |
|---|
| 1812 | </tr> |
|---|
| 1813 | <tr> |
|---|
| 1814 | <td class="left">DELETE</td> |
|---|
| 1815 | <td class="left">no</td> |
|---|
| 1816 | <td class="left"><a href="#DELETE" id="rfc.xref.DELETE.2" title="DELETE">Section 8.7</a> |
|---|
| 1817 | </td> |
|---|
| 1818 | </tr> |
|---|
| 1819 | <tr> |
|---|
| 1820 | <td class="left">GET</td> |
|---|
| 1821 | <td class="left">yes</td> |
|---|
| 1822 | <td class="left"><a href="#GET" id="rfc.xref.GET.2" title="GET">Section 8.3</a> |
|---|
| 1823 | </td> |
|---|
| 1824 | </tr> |
|---|
| 1825 | <tr> |
|---|
| 1826 | <td class="left">HEAD</td> |
|---|
| 1827 | <td class="left">yes</td> |
|---|
| 1828 | <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section 8.4</a> |
|---|
| 1829 | </td> |
|---|
| 1830 | </tr> |
|---|
| 1831 | <tr> |
|---|
| 1832 | <td class="left">OPTIONS</td> |
|---|
| 1833 | <td class="left">yes</td> |
|---|
| 1834 | <td class="left"><a href="#OPTIONS" id="rfc.xref.OPTIONS.3" title="OPTIONS">Section 8.2</a> |
|---|
| 1835 | </td> |
|---|
| 1836 | </tr> |
|---|
| 1837 | <tr> |
|---|
| 1838 | <td class="left">POST</td> |
|---|
| 1839 | <td class="left">no</td> |
|---|
| 1840 | <td class="left"><a href="#POST" id="rfc.xref.POST.2" title="POST">Section 8.5</a> |
|---|
| 1841 | </td> |
|---|
| 1842 | </tr> |
|---|
| 1843 | <tr> |
|---|
| 1844 | <td class="left">PUT</td> |
|---|
| 1845 | <td class="left">no</td> |
|---|
| 1846 | <td class="left"><a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 8.6</a> |
|---|
| 1847 | </td> |
|---|
| 1848 | </tr> |
|---|
| 1849 | <tr> |
|---|
| 1850 | <td class="left">TRACE</td> |
|---|
| 1851 | <td class="left">yes</td> |
|---|
| 1852 | <td class="left"><a href="#TRACE" id="rfc.xref.TRACE.3" title="TRACE">Section 8.8</a> |
|---|
| 1853 | </td> |
|---|
| 1854 | </tr> |
|---|
| 1855 | </tbody> |
|---|
| 1856 | </table> |
|---|
| 1857 | </div> |
|---|
| 1858 | </div> |
|---|
| 1859 | <div id="status.code.registration"> |
|---|
| 1860 | <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a href="#status.code.registration">Status Code Registry</a></h2> |
|---|
| 1861 | <p id="rfc.section.11.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="https://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> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 5.1</a> of this document. |
|---|
| 1862 | </p> |
|---|
| 1863 | <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>> should be updated with the registrations below: |
|---|
| 1864 | </p> |
|---|
| 1865 | <div id="rfc.table.2"> |
|---|
| 1866 | <div id="iana.status.code.registration.table"></div> |
|---|
| 1867 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
|---|
| 1868 | <thead> |
|---|
| 1869 | <tr> |
|---|
| 1870 | <th>Value</th> |
|---|
| 1871 | <th>Description</th> |
|---|
| 1872 | <th>Reference</th> |
|---|
| 1873 | </tr> |
|---|
| 1874 | </thead> |
|---|
| 1875 | <tbody> |
|---|
| 1876 | <tr> |
|---|
| 1877 | <td class="left">100</td> |
|---|
| 1878 | <td class="left">Continue</td> |
|---|
| 1879 | <td class="left"><a href="#status.100" id="rfc.xref.status.100.2" title="100 Continue">Section 9.1.1</a> |
|---|
| 1880 | </td> |
|---|
| 1881 | </tr> |
|---|
| 1882 | <tr> |
|---|
| 1883 | <td class="left">101</td> |
|---|
| 1884 | <td class="left">Switching Protocols</td> |
|---|
| 1885 | <td class="left"><a href="#status.101" id="rfc.xref.status.101.2" title="101 Switching Protocols">Section 9.1.2</a> |
|---|
| 1886 | </td> |
|---|
| 1887 | </tr> |
|---|
| 1888 | <tr> |
|---|
| 1889 | <td class="left">200</td> |
|---|
| 1890 | <td class="left">OK</td> |
|---|
| 1891 | <td class="left"><a href="#status.200" id="rfc.xref.status.200.2" title="200 OK">Section 9.2.1</a> |
|---|
| 1892 | </td> |
|---|
| 1893 | </tr> |
|---|
| 1894 | <tr> |
|---|
| 1895 | <td class="left">201</td> |
|---|
| 1896 | <td class="left">Created</td> |
|---|
| 1897 | <td class="left"><a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 9.2.2</a> |
|---|
| 1898 | </td> |
|---|
| 1899 | </tr> |
|---|
| 1900 | <tr> |
|---|
| 1901 | <td class="left">202</td> |
|---|
| 1902 | <td class="left">Accepted</td> |
|---|
| 1903 | <td class="left"><a href="#status.202" id="rfc.xref.status.202.2" title="202 Accepted">Section 9.2.3</a> |
|---|
| 1904 | </td> |
|---|
| 1905 | </tr> |
|---|
| 1906 | <tr> |
|---|
| 1907 | <td class="left">203</td> |
|---|
| 1908 | <td class="left">Non-Authoritative Information</td> |
|---|
| 1909 | <td class="left"><a href="#status.203" id="rfc.xref.status.203.2" title="203 Non-Authoritative Information">Section 9.2.4</a> |
|---|
| 1910 | </td> |
|---|
| 1911 | </tr> |
|---|
| 1912 | <tr> |
|---|
| 1913 | <td class="left">204</td> |
|---|
| 1914 | <td class="left">No Content</td> |
|---|
| 1915 | <td class="left"><a href="#status.204" id="rfc.xref.status.204.2" title="204 No Content">Section 9.2.5</a> |
|---|
| 1916 | </td> |
|---|
| 1917 | </tr> |
|---|
| 1918 | <tr> |
|---|
| 1919 | <td class="left">205</td> |
|---|
| 1920 | <td class="left">Reset Content</td> |
|---|
| 1921 | <td class="left"><a href="#status.205" id="rfc.xref.status.205.2" title="205 Reset Content">Section 9.2.6</a> |
|---|
| 1922 | </td> |
|---|
| 1923 | </tr> |
|---|
| 1924 | <tr> |
|---|
| 1925 | <td class="left">206</td> |
|---|
| 1926 | <td class="left">Partial Content</td> |
|---|
| 1927 | <td class="left"><a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 9.2.7</a> |
|---|
| 1928 | </td> |
|---|
| 1929 | </tr> |
|---|
| 1930 | <tr> |
|---|
| 1931 | <td class="left">300</td> |
|---|
| 1932 | <td class="left">Multiple Choices</td> |
|---|
| 1933 | <td class="left"><a href="#status.300" id="rfc.xref.status.300.2" title="300 Multiple Choices">Section 9.3.1</a> |
|---|
| 1934 | </td> |
|---|
| 1935 | </tr> |
|---|
| 1936 | <tr> |
|---|
| 1937 | <td class="left">301</td> |
|---|
| 1938 | <td class="left">Moved Permanently</td> |
|---|
| 1939 | <td class="left"><a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">Section 9.3.2</a> |
|---|
| 1940 | </td> |
|---|
| 1941 | </tr> |
|---|
| 1942 | <tr> |
|---|
| 1943 | <td class="left">302</td> |
|---|
| 1944 | <td class="left">Found</td> |
|---|
| 1945 | <td class="left"><a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">Section 9.3.3</a> |
|---|
| 1946 | </td> |
|---|
| 1947 | </tr> |
|---|
| 1948 | <tr> |
|---|
| 1949 | <td class="left">303</td> |
|---|
| 1950 | <td class="left">See Other</td> |
|---|
| 1951 | <td class="left"><a href="#status.303" id="rfc.xref.status.303.2" title="303 See Other">Section 9.3.4</a> |
|---|
| 1952 | </td> |
|---|
| 1953 | </tr> |
|---|
| 1954 | <tr> |
|---|
| 1955 | <td class="left">304</td> |
|---|
| 1956 | <td class="left">Not Modified</td> |
|---|
| 1957 | <td class="left"><a href="#status.304" id="rfc.xref.status.304.2" title="304 Not Modified">Section 9.3.5</a> |
|---|
| 1958 | </td> |
|---|
| 1959 | </tr> |
|---|
| 1960 | <tr> |
|---|
| 1961 | <td class="left">305</td> |
|---|
| 1962 | <td class="left">Use Proxy</td> |
|---|
| 1963 | <td class="left"><a href="#status.305" id="rfc.xref.status.305.2" title="305 Use Proxy">Section 9.3.6</a> |
|---|
| 1964 | </td> |
|---|
| 1965 | </tr> |
|---|
| 1966 | <tr> |
|---|
| 1967 | <td class="left">306</td> |
|---|
| 1968 | <td class="left">(Unused)</td> |
|---|
| 1969 | <td class="left"><a href="#status.306" id="rfc.xref.status.306.1" title="306 (Unused)">Section 9.3.7</a> |
|---|
| 1970 | </td> |
|---|
| 1971 | </tr> |
|---|
| 1972 | <tr> |
|---|
| 1973 | <td class="left">307</td> |
|---|
| 1974 | <td class="left">Temporary Redirect</td> |
|---|
| 1975 | <td class="left"><a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">Section 9.3.8</a> |
|---|
| 1976 | </td> |
|---|
| 1977 | </tr> |
|---|
| 1978 | <tr> |
|---|
| 1979 | <td class="left">400</td> |
|---|
| 1980 | <td class="left">Bad Request</td> |
|---|
| 1981 | <td class="left"><a href="#status.400" id="rfc.xref.status.400.2" title="400 Bad Request">Section 9.4.1</a> |
|---|
| 1982 | </td> |
|---|
| 1983 | </tr> |
|---|
| 1984 | <tr> |
|---|
| 1985 | <td class="left">401</td> |
|---|
| 1986 | <td class="left">Unauthorized</td> |
|---|
| 1987 | <td class="left"><a href="#status.401" id="rfc.xref.status.401.2" title="401 Unauthorized">Section 9.4.2</a> |
|---|
| 1988 | </td> |
|---|
| 1989 | </tr> |
|---|
| 1990 | <tr> |
|---|
| 1991 | <td class="left">402</td> |
|---|
| 1992 | <td class="left">Payment Required</td> |
|---|
| 1993 | <td class="left"><a href="#status.402" id="rfc.xref.status.402.2" title="402 Payment Required">Section 9.4.3</a> |
|---|
| 1994 | </td> |
|---|
| 1995 | </tr> |
|---|
| 1996 | <tr> |
|---|
| 1997 | <td class="left">403</td> |
|---|
| 1998 | <td class="left">Forbidden</td> |
|---|
| 1999 | <td class="left"><a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">Section 9.4.4</a> |
|---|
| 2000 | </td> |
|---|
| 2001 | </tr> |
|---|
| 2002 | <tr> |
|---|
| 2003 | <td class="left">404</td> |
|---|
| 2004 | <td class="left">Not Found</td> |
|---|
| 2005 | <td class="left"><a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">Section 9.4.5</a> |
|---|
| 2006 | </td> |
|---|
| 2007 | </tr> |
|---|
| 2008 | <tr> |
|---|
| 2009 | <td class="left">405</td> |
|---|
| 2010 | <td class="left">Method Not Allowed</td> |
|---|
| 2011 | <td class="left"><a href="#status.405" id="rfc.xref.status.405.2" title="405 Method Not Allowed">Section 9.4.6</a> |
|---|
| 2012 | </td> |
|---|
| 2013 | </tr> |
|---|
| 2014 | <tr> |
|---|
| 2015 | <td class="left">406</td> |
|---|
| 2016 | <td class="left">Not Acceptable</td> |
|---|
| 2017 | <td class="left"><a href="#status.406" id="rfc.xref.status.406.2" title="406 Not Acceptable">Section 9.4.7</a> |
|---|
| 2018 | </td> |
|---|
| 2019 | </tr> |
|---|
| 2020 | <tr> |
|---|
| 2021 | <td class="left">407</td> |
|---|
| 2022 | <td class="left">Proxy Authentication Required</td> |
|---|
| 2023 | <td class="left"><a href="#status.407" id="rfc.xref.status.407.2" title="407 Proxy Authentication Required">Section 9.4.8</a> |
|---|
| 2024 | </td> |
|---|
| 2025 | </tr> |
|---|
| 2026 | <tr> |
|---|
| 2027 | <td class="left">408</td> |
|---|
| 2028 | <td class="left">Request Timeout</td> |
|---|
| 2029 | <td class="left"><a href="#status.408" id="rfc.xref.status.408.2" title="408 Request Timeout">Section 9.4.9</a> |
|---|
| 2030 | </td> |
|---|
| 2031 | </tr> |
|---|
| 2032 | <tr> |
|---|
| 2033 | <td class="left">409</td> |
|---|
| 2034 | <td class="left">Conflict</td> |
|---|
| 2035 | <td class="left"><a href="#status.409" id="rfc.xref.status.409.2" title="409 Conflict">Section 9.4.10</a> |
|---|
| 2036 | </td> |
|---|
| 2037 | </tr> |
|---|
| 2038 | <tr> |
|---|
| 2039 | <td class="left">410</td> |
|---|
| 2040 | <td class="left">Gone</td> |
|---|
| 2041 | <td class="left"><a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">Section 9.4.11</a> |
|---|
| 2042 | </td> |
|---|
| 2043 | </tr> |
|---|
| 2044 | <tr> |
|---|
| 2045 | <td class="left">411</td> |
|---|
| 2046 | <td class="left">Length Required</td> |
|---|
| 2047 | <td class="left"><a href="#status.411" id="rfc.xref.status.411.2" title="411 Length Required">Section 9.4.12</a> |
|---|
| 2048 | </td> |
|---|
| 2049 | </tr> |
|---|
| 2050 | <tr> |
|---|
| 2051 | <td class="left">412</td> |
|---|
| 2052 | <td class="left">Precondition Failed</td> |
|---|
| 2053 | <td class="left"><a href="#status.412" id="rfc.xref.status.412.2" title="412 Precondition Failed">Section 9.4.13</a> |
|---|
| 2054 | </td> |
|---|
| 2055 | </tr> |
|---|
| 2056 | <tr> |
|---|
| 2057 | <td class="left">413</td> |
|---|
| 2058 | <td class="left">Request Entity Too Large</td> |
|---|
| 2059 | <td class="left"><a href="#status.413" id="rfc.xref.status.413.2" title="413 Request Entity Too Large">Section 9.4.14</a> |
|---|
| 2060 | </td> |
|---|
| 2061 | </tr> |
|---|
| 2062 | <tr> |
|---|
| 2063 | <td class="left">414</td> |
|---|
| 2064 | <td class="left">Request-URI Too Long</td> |
|---|
| 2065 | <td class="left"><a href="#status.414" id="rfc.xref.status.414.2" title="414 Request-URI Too Long">Section 9.4.15</a> |
|---|
| 2066 | </td> |
|---|
| 2067 | </tr> |
|---|
| 2068 | <tr> |
|---|
| 2069 | <td class="left">415</td> |
|---|
| 2070 | <td class="left">Unsupported Media Type</td> |
|---|
| 2071 | <td class="left"><a href="#status.415" id="rfc.xref.status.415.2" title="415 Unsupported Media Type">Section 9.4.16</a> |
|---|
| 2072 | </td> |
|---|
| 2073 | </tr> |
|---|
| 2074 | <tr> |
|---|
| 2075 | <td class="left">416</td> |
|---|
| 2076 | <td class="left">Requested Range Not Satisfiable</td> |
|---|
| 2077 | <td class="left"><a href="#status.416" id="rfc.xref.status.416.2" title="416 Requested Range Not Satisfiable">Section 9.4.17</a> |
|---|
| 2078 | </td> |
|---|
| 2079 | </tr> |
|---|
| 2080 | <tr> |
|---|
| 2081 | <td class="left">417</td> |
|---|
| 2082 | <td class="left">Expectation Failed</td> |
|---|
| 2083 | <td class="left"><a href="#status.417" id="rfc.xref.status.417.2" title="417 Expectation Failed">Section 9.4.18</a> |
|---|
| 2084 | </td> |
|---|
| 2085 | </tr> |
|---|
| 2086 | <tr> |
|---|
| 2087 | <td class="left">500</td> |
|---|
| 2088 | <td class="left">Internal Server Error</td> |
|---|
| 2089 | <td class="left"><a href="#status.500" id="rfc.xref.status.500.2" title="500 Internal Server Error">Section 9.5.1</a> |
|---|
| 2090 | </td> |
|---|
| 2091 | </tr> |
|---|
| 2092 | <tr> |
|---|
| 2093 | <td class="left">501</td> |
|---|
| 2094 | <td class="left">Not Implemented</td> |
|---|
| 2095 | <td class="left"><a href="#status.501" id="rfc.xref.status.501.2" title="501 Not Implemented">Section 9.5.2</a> |
|---|
| 2096 | </td> |
|---|
| 2097 | </tr> |
|---|
| 2098 | <tr> |
|---|
| 2099 | <td class="left">502</td> |
|---|
| 2100 | <td class="left">Bad Gateway</td> |
|---|
| 2101 | <td class="left"><a href="#status.502" id="rfc.xref.status.502.2" title="502 Bad Gateway">Section 9.5.3</a> |
|---|
| 2102 | </td> |
|---|
| 2103 | </tr> |
|---|
| 2104 | <tr> |
|---|
| 2105 | <td class="left">503</td> |
|---|
| 2106 | <td class="left">Service Unavailable</td> |
|---|
| 2107 | <td class="left"><a href="#status.503" id="rfc.xref.status.503.2" title="503 Service Unavailable">Section 9.5.4</a> |
|---|
| 2108 | </td> |
|---|
| 2109 | </tr> |
|---|
| 2110 | <tr> |
|---|
| 2111 | <td class="left">504</td> |
|---|
| 2112 | <td class="left">Gateway Timeout</td> |
|---|
| 2113 | <td class="left"><a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 9.5.5</a> |
|---|
| 2114 | </td> |
|---|
| 2115 | </tr> |
|---|
| 2116 | <tr> |
|---|
| 2117 | <td class="left">505</td> |
|---|
| 2118 | <td class="left">HTTP Version Not Supported</td> |
|---|
| 2119 | <td class="left"><a href="#status.505" id="rfc.xref.status.505.2" title="505 HTTP Version Not Supported">Section 9.5.6</a> |
|---|
| 2120 | </td> |
|---|
| 2121 | </tr> |
|---|
| 2122 | </tbody> |
|---|
| 2123 | </table> |
|---|
| 2124 | </div> |
|---|
| 2125 | </div> |
|---|
| 2126 | <div id="message.header.registration"> |
|---|
| 2127 | <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a href="#message.header.registration">Message Header Registration</a></h2> |
|---|
| 2128 | <p id="rfc.section.11.3.p.1">The Message Header 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>> should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): |
|---|
| 2129 | </p> |
|---|
| 2130 | <div id="rfc.table.3"> |
|---|
| 2131 | <div id="iana.header.registration.table"></div> |
|---|
| 2132 | <table class="tt full left" cellpadding="3" cellspacing="0"> |
|---|
| 2133 | <thead> |
|---|
| 2134 | <tr> |
|---|
| 2135 | <th>Header Field Name</th> |
|---|
| 2136 | <th>Protocol</th> |
|---|
| 2137 | <th>Status</th> |
|---|
| 2138 | <th>Reference</th> |
|---|
| 2139 | </tr> |
|---|
| 2140 | </thead> |
|---|
| 2141 | <tbody> |
|---|
| 2142 | <tr> |
|---|
| 2143 | <td class="left">Allow</td> |
|---|
| 2144 | <td class="left">http</td> |
|---|
| 2145 | <td class="left">standard</td> |
|---|
| 2146 | <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 10.1</a> |
|---|
| 2147 | </td> |
|---|
| 2148 | </tr> |
|---|
| 2149 | <tr> |
|---|
| 2150 | <td class="left">Expect</td> |
|---|
| 2151 | <td class="left">http</td> |
|---|
| 2152 | <td class="left">standard</td> |
|---|
| 2153 | <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 10.2</a> |
|---|
| 2154 | </td> |
|---|
| 2155 | </tr> |
|---|
| 2156 | <tr> |
|---|
| 2157 | <td class="left">From</td> |
|---|
| 2158 | <td class="left">http</td> |
|---|
| 2159 | <td class="left">standard</td> |
|---|
| 2160 | <td class="left"><a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 10.3</a> |
|---|
| 2161 | </td> |
|---|
| 2162 | </tr> |
|---|
| 2163 | <tr> |
|---|
| 2164 | <td class="left">Location</td> |
|---|
| 2165 | <td class="left">http</td> |
|---|
| 2166 | <td class="left">standard</td> |
|---|
| 2167 | <td class="left"><a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.4</a> |
|---|
| 2168 | </td> |
|---|
| 2169 | </tr> |
|---|
| 2170 | <tr> |
|---|
| 2171 | <td class="left">Max-Forwards</td> |
|---|
| 2172 | <td class="left">http</td> |
|---|
| 2173 | <td class="left">standard</td> |
|---|
| 2174 | <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 10.5</a> |
|---|
| 2175 | </td> |
|---|
| 2176 | </tr> |
|---|
| 2177 | <tr> |
|---|
| 2178 | <td class="left">Referer</td> |
|---|
| 2179 | <td class="left">http</td> |
|---|
| 2180 | <td class="left">standard</td> |
|---|
| 2181 | <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 10.6</a> |
|---|
| 2182 | </td> |
|---|
| 2183 | </tr> |
|---|
| 2184 | <tr> |
|---|
| 2185 | <td class="left">Retry-After</td> |
|---|
| 2186 | <td class="left">http</td> |
|---|
| 2187 | <td class="left">standard</td> |
|---|
| 2188 | <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 10.7</a> |
|---|
| 2189 | </td> |
|---|
| 2190 | </tr> |
|---|
| 2191 | <tr> |
|---|
| 2192 | <td class="left">Server</td> |
|---|
| 2193 | <td class="left">http</td> |
|---|
| 2194 | <td class="left">standard</td> |
|---|
| 2195 | <td class="left"><a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.8</a> |
|---|
| 2196 | </td> |
|---|
| 2197 | </tr> |
|---|
| 2198 | <tr> |
|---|
| 2199 | <td class="left">User-Agent</td> |
|---|
| 2200 | <td class="left">http</td> |
|---|
| 2201 | <td class="left">standard</td> |
|---|
| 2202 | <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.9</a> |
|---|
| 2203 | </td> |
|---|
| 2204 | </tr> |
|---|
| 2205 | </tbody> |
|---|
| 2206 | </table> |
|---|
| 2207 | </div> |
|---|
| 2208 | <p id="rfc.section.11.3.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> |
|---|
| 2209 | </div> |
|---|
| 2210 | </div> |
|---|
| 2211 | <div id="security.considerations"> |
|---|
| 2212 | <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a href="#security.considerations">Security Considerations</a></h1> |
|---|
| 2213 | <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 |
|---|
| 2214 | as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does |
|---|
| 2215 | make some suggestions for reducing security risks. |
|---|
| 2216 | </p> |
|---|
| 2217 | <div id="security.sensitive"> |
|---|
| 2218 | <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> <a href="#security.sensitive">Transfer of Sensitive Information</a></h2> |
|---|
| 2219 | <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 |
|---|
| 2220 | a priori method of determining the sensitivity of any particular piece of information within the context of any given request. |
|---|
| 2221 | 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 |
|---|
| 2222 | special mention in this context: Server, Via, Referer and From. |
|---|
| 2223 | </p> |
|---|
| 2224 | <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 |
|---|
| 2225 | against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. |
|---|
| 2226 | </p> |
|---|
| 2227 | <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, |
|---|
| 2228 | they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. |
|---|
| 2229 | </p> |
|---|
| 2230 | <p id="rfc.section.12.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power |
|---|
| 2231 | can be abused if user details are not separated from the information contained in the Referer. Even when the personal information |
|---|
| 2232 | has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. |
|---|
| 2233 | </p> |
|---|
| 2234 | <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 |
|---|
| 2235 | 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. |
|---|
| 2236 | </p> |
|---|
| 2237 | <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 |
|---|
| 2238 | of From and Referer information. |
|---|
| 2239 | </p> |
|---|
| 2240 | <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.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which |
|---|
| 2241 | might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently |
|---|
| 2242 | has no better mechanism. |
|---|
| 2243 | </p> |
|---|
| 2244 | </div> |
|---|
| 2245 | <div id="encoding.sensitive.information.in.uris"> |
|---|
| 2246 | <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> |
|---|
| 2247 | <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 |
|---|
| 2248 | recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could |
|---|
| 2249 | have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From |
|---|
| 2250 | information. |
|---|
| 2251 | </p> |
|---|
| 2252 | <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. |
|---|
| 2253 | </p> |
|---|
| 2254 | <p id="rfc.section.12.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded |
|---|
| 2255 | in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might |
|---|
| 2256 | be visible to third parties. Such services can use POST-based form submission instead. |
|---|
| 2257 | </p> |
|---|
| 2258 | </div> |
|---|
| 2259 | <div id="location.spoofing"> |
|---|
| 2260 | <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a href="#location.spoofing">Location Headers and Spoofing</a></h2> |
|---|
| 2261 | <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 headers in responses that are generated under control of said organizations |
|---|
| 2262 | to make sure that they do not attempt to invalidate resources over which they have no authority. |
|---|
| 2263 | </p> |
|---|
| 2264 | </div> |
|---|
| 2265 | </div> |
|---|
| 2266 | <div id="ack"> |
|---|
| 2267 | <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a href="#ack">Acknowledgments</a></h1> |
|---|
| 2268 | </div> |
|---|
| 2269 | <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References |
|---|
| 2270 | </h1> |
|---|
| 2271 | <h2 id="rfc.references.1"><a href="#rfc.section.14.1" id="rfc.section.14.1">14.1</a> Normative References |
|---|
| 2272 | </h2> |
|---|
| 2273 | <table> |
|---|
| 2274 | <tr> |
|---|
| 2275 | <td class="reference"><b id="Part1">[Part1]</b></td> |
|---|
| 2276 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-04">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-04 (work in progress), August 2008. |
|---|
| 2277 | </td> |
|---|
| 2278 | </tr> |
|---|
| 2279 | <tr> |
|---|
| 2280 | <td class="reference"><b id="Part3">[Part3]</b></td> |
|---|
| 2281 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-04">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-04 (work in progress), August 2008. |
|---|
| 2282 | </td> |
|---|
| 2283 | </tr> |
|---|
| 2284 | <tr> |
|---|
| 2285 | <td class="reference"><b id="Part4">[Part4]</b></td> |
|---|
| 2286 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-04">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-04 (work in progress), August 2008. |
|---|
| 2287 | </td> |
|---|
| 2288 | </tr> |
|---|
| 2289 | <tr> |
|---|
| 2290 | <td class="reference"><b id="Part5">[Part5]</b></td> |
|---|
| 2291 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p5-range-04">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-04 (work in progress), August 2008. |
|---|
| 2292 | </td> |
|---|
| 2293 | </tr> |
|---|
| 2294 | <tr> |
|---|
| 2295 | <td class="reference"><b id="Part6">[Part6]</b></td> |
|---|
| 2296 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-04">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-04 (work in progress), August 2008. |
|---|
| 2297 | </td> |
|---|
| 2298 | </tr> |
|---|
| 2299 | <tr> |
|---|
| 2300 | <td class="reference"><b id="Part7">[Part7]</b></td> |
|---|
| 2301 | <td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">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="https://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-04">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-04 (work in progress), August 2008. |
|---|
| 2302 | </td> |
|---|
| 2303 | </tr> |
|---|
| 2304 | <tr> |
|---|
| 2305 | <td class="reference"><b id="RFC2119">[RFC2119]</b></td> |
|---|
| 2306 | <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. |
|---|
| 2307 | </td> |
|---|
| 2308 | </tr> |
|---|
| 2309 | </table> |
|---|
| 2310 | <h2 id="rfc.references.2"><a href="#rfc.section.14.2" id="rfc.section.14.2">14.2</a> Informative References |
|---|
| 2311 | </h2> |
|---|
| 2312 | <table> |
|---|
| 2313 | <tr> |
|---|
| 2314 | <td class="reference"><b id="RFC1945">[RFC1945]</b></td> |
|---|
| 2315 | <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="https://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. |
|---|
| 2316 | </td> |
|---|
| 2317 | </tr> |
|---|
| 2318 | <tr> |
|---|
| 2319 | <td class="reference"><b id="RFC2068">[RFC2068]</b></td> |
|---|
| 2320 | <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="https://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. |
|---|
| 2321 | </td> |
|---|
| 2322 | </tr> |
|---|
| 2323 | <tr> |
|---|
| 2324 | <td class="reference"><b id="RFC2616">[RFC2616]</b></td> |
|---|
| 2325 | <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="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. |
|---|
| 2326 | </td> |
|---|
| 2327 | </tr> |
|---|
| 2328 | <tr> |
|---|
| 2329 | <td class="reference"><b id="RFC2817">[RFC2817]</b></td> |
|---|
| 2330 | <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="https://tools.ietf.org/html/rfc2817">Upgrading to TLS Within HTTP/1.1</a>”, RFC 2817, May 2000. |
|---|
| 2331 | </td> |
|---|
| 2332 | </tr> |
|---|
| 2333 | <tr> |
|---|
| 2334 | <td class="reference"><b id="RFC2822">[RFC2822]</b></td> |
|---|
| 2335 | <td class="top">Resnick, P., “<a href="https://tools.ietf.org/html/rfc2822">Internet Message Format</a>”, RFC 2822, April 2001. |
|---|
| 2336 | </td> |
|---|
| 2337 | </tr> |
|---|
| 2338 | <tr> |
|---|
| 2339 | <td class="reference"><b id="RFC3864">[RFC3864]</b></td> |
|---|
| 2340 | <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="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. |
|---|
| 2341 | </td> |
|---|
| 2342 | </tr> |
|---|
| 2343 | <tr> |
|---|
| 2344 | <td class="reference"><b id="RFC5226">[RFC5226]</b></td> |
|---|
| 2345 | <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="https://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 5226, May 2008. |
|---|
| 2346 | </td> |
|---|
| 2347 | </tr> |
|---|
| 2348 | </table> |
|---|
| 2349 | <div id="compatibility"> |
|---|
| 2350 | <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a href="#compatibility">Compatibility with Previous Versions</a></h1> |
|---|
| 2351 | <div id="changes.from.rfc.2068"> |
|---|
| 2352 | <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> |
|---|
| 2353 | <p id="rfc.section.A.1.p.1">Clarified which error code should be used for inbound server failures (e.g. DNS failures). (<a href="#status.504" id="rfc.xref.status.504.3" title="504 Gateway Timeout">Section 9.5.5</a>). |
|---|
| 2354 | </p> |
|---|
| 2355 | <p id="rfc.section.A.1.p.2">201 (Created) had a race that required an Etag be sent when a resource is first created. (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section 9.2.2</a>). |
|---|
| 2356 | </p> |
|---|
| 2357 | <p id="rfc.section.A.1.p.3">Rewrite of message transmission requirements to make it much harder for implementors to get it wrong, as the consequences |
|---|
| 2358 | of errors here can have significant impact on the Internet, and to deal with the following problems: |
|---|
| 2359 | </p> |
|---|
| 2360 | <ol> |
|---|
| 2361 | <li>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where this was incorrectly placing a requirement on the behavior of |
|---|
| 2362 | an implementation of a future version of HTTP/1.x |
|---|
| 2363 | </li> |
|---|
| 2364 | <li>Made it clear that user-agents should retry requests, not "clients" in general.</li> |
|---|
| 2365 | <li>Converted requirements for clients to ignore unexpected 100 (Continue) responses, and for proxies to forward 100 responses, |
|---|
| 2366 | into a general requirement for 1xx responses. |
|---|
| 2367 | </li> |
|---|
| 2368 | <li>Modified some TCP-specific language, to make it clearer that non-TCP transports are possible for HTTP.</li> |
|---|
| 2369 | <li>Require that the origin server <em class="bcp14">MUST NOT</em> wait for the request body before it sends a required 100 (Continue) response. |
|---|
| 2370 | </li> |
|---|
| 2371 | <li>Allow, rather than require, a server to omit 100 (Continue) if it has already seen some of the request body.</li> |
|---|
| 2372 | <li>Allow servers to defend against denial-of-service attacks and broken clients.</li> |
|---|
| 2373 | </ol> |
|---|
| 2374 | <p id="rfc.section.A.1.p.4">This change adds the Expect header and 417 status code.</p> |
|---|
| 2375 | <p id="rfc.section.A.1.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.3" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.3" title="410 Gone">9.4.11</a>) |
|---|
| 2376 | </p> |
|---|
| 2377 | <p id="rfc.section.A.1.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="https://tools.ietf.org/html/rfc2068#section-19.6.1">Section 19.6.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. |
|---|
| 2378 | </p> |
|---|
| 2379 | </div> |
|---|
| 2380 | <div id="changes.from.rfc.2616"> |
|---|
| 2381 | <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> |
|---|
| 2382 | <p id="rfc.section.A.2.p.1">This document takes over the Status Code Registry, previously defined in <a href="https://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 5.1</a>) |
|---|
| 2383 | </p> |
|---|
| 2384 | <p id="rfc.section.A.2.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.3" title="POST">Section 8.5</a>) |
|---|
| 2385 | </p> |
|---|
| 2386 | <p id="rfc.section.A.2.p.3">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the |
|---|
| 2387 | user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">9.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">9.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">9.3.8</a>) |
|---|
| 2388 | </p> |
|---|
| 2389 | <p id="rfc.section.A.2.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource |
|---|
| 2390 | must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient |
|---|
| 2391 | 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 9.3.6</a>) |
|---|
| 2392 | </p> |
|---|
| 2393 | <p id="rfc.section.A.2.p.5">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement |
|---|
| 2394 | on the contents of the Allow header and remove requirement on clients to always trust the header value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 10.1</a>) |
|---|
| 2395 | </p> |
|---|
| 2396 | <p id="rfc.section.A.2.p.6">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications |
|---|
| 2397 | as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 10.4</a>) |
|---|
| 2398 | </p> |
|---|
| 2399 | <p id="rfc.section.A.2.p.7">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly |
|---|
| 2400 | in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.8</a>) |
|---|
| 2401 | </p> |
|---|
| 2402 | </div> |
|---|
| 2403 | </div> |
|---|
| 2404 | <div id="change.log"> |
|---|
| 2405 | <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> |
|---|
| 2406 | <div> |
|---|
| 2407 | <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 |
|---|
| 2408 | </h2> |
|---|
| 2409 | <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. |
|---|
| 2410 | </p> |
|---|
| 2411 | </div> |
|---|
| 2412 | <div> |
|---|
| 2413 | <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p2-semantics-00 |
|---|
| 2414 | </h2> |
|---|
| 2415 | <p id="rfc.section.B.2.p.1">Closed issues: </p> |
|---|
| 2416 | <ul> |
|---|
| 2417 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/5">http://www3.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>>) |
|---|
| 2418 | </li> |
|---|
| 2419 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/6">http://www3.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>>) |
|---|
| 2420 | </li> |
|---|
| 2421 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/10">http://www3.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>>) |
|---|
| 2422 | </li> |
|---|
| 2423 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17">http://www3.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>>) |
|---|
| 2424 | </li> |
|---|
| 2425 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35</a>>: "Normative and Informative references" |
|---|
| 2426 | </li> |
|---|
| 2427 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42</a>>: "RFC2606 Compliance" |
|---|
| 2428 | </li> |
|---|
| 2429 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65</a>>: "Informative references" |
|---|
| 2430 | </li> |
|---|
| 2431 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84</a>>: "Redundant cross-references" |
|---|
| 2432 | </li> |
|---|
| 2433 | </ul> |
|---|
| 2434 | <p id="rfc.section.B.2.p.2">Other changes: </p> |
|---|
| 2435 | <ul> |
|---|
| 2436 | <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> |
|---|
| 2437 | </li> |
|---|
| 2438 | </ul> |
|---|
| 2439 | </div> |
|---|
| 2440 | <div> |
|---|
| 2441 | <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> Since draft-ietf-httpbis-p2-semantics-01 |
|---|
| 2442 | </h2> |
|---|
| 2443 | <p id="rfc.section.B.3.p.1">Closed issues: </p> |
|---|
| 2444 | <ul> |
|---|
| 2445 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21</a>>: "PUT side effects" |
|---|
| 2446 | </li> |
|---|
| 2447 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91</a>>: "Duplicate Host header requirements" |
|---|
| 2448 | </li> |
|---|
| 2449 | </ul> |
|---|
| 2450 | <p id="rfc.section.B.3.p.2">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
|---|
| 2451 | </p> |
|---|
| 2452 | <ul> |
|---|
| 2453 | <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li> |
|---|
| 2454 | <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> |
|---|
| 2455 | <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li> |
|---|
| 2456 | </ul> |
|---|
| 2457 | </div> |
|---|
| 2458 | <div id="changes.since.02"> |
|---|
| 2459 | <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> <a href="#changes.since.02">Since draft-ietf-httpbis-p2-semantics-02</a></h2> |
|---|
| 2460 | <p id="rfc.section.B.4.p.1">Closed issues: </p> |
|---|
| 2461 | <ul> |
|---|
| 2462 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24</a>>: "Requiring Allow in 405 responses" |
|---|
| 2463 | </li> |
|---|
| 2464 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59</a>>: "Status Code Registry" |
|---|
| 2465 | </li> |
|---|
| 2466 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61</a>>: "Redirection vs. Location" |
|---|
| 2467 | </li> |
|---|
| 2468 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70</a>>: "Cacheability of 303 response" |
|---|
| 2469 | </li> |
|---|
| 2470 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76</a>>: "305 Use Proxy" |
|---|
| 2471 | </li> |
|---|
| 2472 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header" |
|---|
| 2473 | </li> |
|---|
| 2474 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112</a>>: "PUT - 'store under' vs 'store at'" |
|---|
| 2475 | </li> |
|---|
| 2476 | </ul> |
|---|
| 2477 | <p id="rfc.section.B.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): |
|---|
| 2478 | </p> |
|---|
| 2479 | <ul> |
|---|
| 2480 | <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li> |
|---|
| 2481 | </ul> |
|---|
| 2482 | <p id="rfc.section.B.4.p.3">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): |
|---|
| 2483 | </p> |
|---|
| 2484 | <ul> |
|---|
| 2485 | <li>Replace string literals when the string really is case-sensitive (method).</li> |
|---|
| 2486 | </ul> |
|---|
| 2487 | </div> |
|---|
| 2488 | <div id="changes.since.03"> |
|---|
| 2489 | <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a> <a href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></h2> |
|---|
| 2490 | <p id="rfc.section.B.5.p.1">Closed issues: </p> |
|---|
| 2491 | <ul> |
|---|
| 2492 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98</a>>: "OPTIONS request bodies" |
|---|
| 2493 | </li> |
|---|
| 2494 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/119">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/119</a>>: "Description of CONNECT should refer to RFC2817" |
|---|
| 2495 | </li> |
|---|
| 2496 | <li><<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/125">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/125</a>>: "Location Content-Location reference request/response mixup" |
|---|
| 2497 | </li> |
|---|
| 2498 | </ul> |
|---|
| 2499 | <p id="rfc.section.B.5.p.2">Ongoing work on Method Registry (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72</a>>): |
|---|
| 2500 | </p> |
|---|
| 2501 | <ul> |
|---|
| 2502 | <li>Added initial proposal for registration process, plus initial content (non-HTTP/1.1 methods to be added by a separate specification).</li> |
|---|
| 2503 | </ul> |
|---|
| 2504 | </div> |
|---|
| 2505 | </div> |
|---|
| 2506 | <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> |
|---|
| 2507 | <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> |
|---|
| 2508 | </p> |
|---|
| 2509 | <div class="print2col"> |
|---|
| 2510 | <ul class="ind"> |
|---|
| 2511 | <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> |
|---|
| 2512 | <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5</a>, <a href="#rfc.iref.1.1"><b>9.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> |
|---|
| 2513 | <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">5</a>, <a href="#rfc.iref.1.2"><b>9.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> |
|---|
| 2514 | </ul> |
|---|
| 2515 | </li> |
|---|
| 2516 | <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> |
|---|
| 2517 | <li>200 OK (status code) <a href="#rfc.xref.status.200.1">5</a>, <a href="#rfc.iref.2.1"><b>9.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> |
|---|
| 2518 | <li>201 Created (status code) <a href="#rfc.xref.status.201.1">5</a>, <a href="#rfc.iref.2.2"><b>9.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a>, <a href="#rfc.xref.status.201.3">A.1</a></li> |
|---|
| 2519 | <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">5</a>, <a href="#rfc.iref.2.3"><b>9.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> |
|---|
| 2520 | <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">5</a>, <a href="#rfc.iref.2.4"><b>9.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a></li> |
|---|
| 2521 | <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">5</a>, <a href="#rfc.iref.2.5"><b>9.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> |
|---|
| 2522 | <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">5</a>, <a href="#rfc.iref.2.6"><b>9.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> |
|---|
| 2523 | <li>206 Partial Content (status code) <a href="#rfc.xref.status.206.1">5</a>, <a href="#rfc.iref.2.7"><b>9.2.7</b></a>, <a href="#rfc.xref.status.206.2">11.2</a></li> |
|---|
| 2524 | </ul> |
|---|
| 2525 | </li> |
|---|
| 2526 | <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> |
|---|
| 2527 | <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">5</a>, <a href="#rfc.iref.3.1"><b>9.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> |
|---|
| 2528 | <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">5</a>, <a href="#rfc.iref.3.2"><b>9.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A.2</a></li> |
|---|
| 2529 | <li>302 Found (status code) <a href="#rfc.xref.status.302.1">5</a>, <a href="#rfc.iref.3.3"><b>9.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A.2</a></li> |
|---|
| 2530 | <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">5</a>, <a href="#rfc.iref.3.4"><b>9.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> |
|---|
| 2531 | <li>304 Not Modified (status code) <a href="#rfc.xref.status.304.1">5</a>, <a href="#rfc.iref.3.5"><b>9.3.5</b></a>, <a href="#rfc.xref.status.304.2">11.2</a></li> |
|---|
| 2532 | <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">5</a>, <a href="#rfc.iref.3.6"><b>9.3.6</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A.2</a></li> |
|---|
| 2533 | <li>306 (Unused) (status code) <a href="#rfc.iref.3.7"><b>9.3.7</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> |
|---|
| 2534 | <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">5</a>, <a href="#rfc.iref.3.8"><b>9.3.8</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A.2</a></li> |
|---|
| 2535 | </ul> |
|---|
| 2536 | </li> |
|---|
| 2537 | <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> |
|---|
| 2538 | <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">5</a>, <a href="#rfc.iref.4.1"><b>9.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> |
|---|
| 2539 | <li>401 Unauthorized (status code) <a href="#rfc.xref.status.401.1">5</a>, <a href="#rfc.iref.4.2"><b>9.4.2</b></a>, <a href="#rfc.xref.status.401.2">11.2</a></li> |
|---|
| 2540 | <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">5</a>, <a href="#rfc.iref.4.3"><b>9.4.3</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> |
|---|
| 2541 | <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">5</a>, <a href="#rfc.iref.4.4"><b>9.4.4</b></a>, <a href="#rfc.xref.status.403.2">11.2</a>, <a href="#rfc.xref.status.403.3">A.1</a></li> |
|---|
| 2542 | <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">5</a>, <a href="#rfc.iref.4.5"><b>9.4.5</b></a>, <a href="#rfc.xref.status.404.2">11.2</a>, <a href="#rfc.xref.status.404.3">A.1</a></li> |
|---|
| 2543 | <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">5</a>, <a href="#rfc.iref.4.6"><b>9.4.6</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> |
|---|
| 2544 | <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">5</a>, <a href="#rfc.iref.4.7"><b>9.4.7</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> |
|---|
| 2545 | <li>407 Proxy Authentication Required (status code) <a href="#rfc.xref.status.407.1">5</a>, <a href="#rfc.iref.4.8"><b>9.4.8</b></a>, <a href="#rfc.xref.status.407.2">11.2</a></li> |
|---|
| 2546 | <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">5</a>, <a href="#rfc.iref.4.9"><b>9.4.9</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> |
|---|
| 2547 | <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">5</a>, <a href="#rfc.iref.4.10"><b>9.4.10</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> |
|---|
| 2548 | <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">5</a>, <a href="#rfc.iref.4.11"><b>9.4.11</b></a>, <a href="#rfc.xref.status.410.2">11.2</a>, <a href="#rfc.xref.status.410.3">A.1</a></li> |
|---|
| 2549 | <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">5</a>, <a href="#rfc.iref.4.12"><b>9.4.12</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> |
|---|
| 2550 | <li>412 Precondition Failed (status code) <a href="#rfc.xref.status.412.1">5</a>, <a href="#rfc.iref.4.13"><b>9.4.13</b></a>, <a href="#rfc.xref.status.412.2">11.2</a></li> |
|---|
| 2551 | <li>413 Request Entity Too Large (status code) <a href="#rfc.xref.status.413.1">5</a>, <a href="#rfc.iref.4.14"><b>9.4.14</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> |
|---|
| 2552 | <li>414 Request-URI Too Long (status code) <a href="#rfc.xref.status.414.1">5</a>, <a href="#rfc.iref.4.15"><b>9.4.15</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> |
|---|
| 2553 | <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">5</a>, <a href="#rfc.iref.4.16"><b>9.4.16</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> |
|---|
| 2554 | <li>416 Requested Range Not Satisfiable (status code) <a href="#rfc.xref.status.416.1">5</a>, <a href="#rfc.iref.4.17"><b>9.4.17</b></a>, <a href="#rfc.xref.status.416.2">11.2</a></li> |
|---|
| 2555 | <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">5</a>, <a href="#rfc.iref.4.18"><b>9.4.18</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> |
|---|
| 2556 | </ul> |
|---|
| 2557 | </li> |
|---|
| 2558 | <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> |
|---|
| 2559 | <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">5</a>, <a href="#rfc.iref.5.1"><b>9.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> |
|---|
| 2560 | <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">5</a>, <a href="#rfc.iref.5.2"><b>9.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> |
|---|
| 2561 | <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">5</a>, <a href="#rfc.iref.5.3"><b>9.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> |
|---|
| 2562 | <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">5</a>, <a href="#rfc.iref.5.4"><b>9.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> |
|---|
| 2563 | <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">5</a>, <a href="#rfc.iref.5.5"><b>9.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a>, <a href="#rfc.xref.status.504.3">A.1</a></li> |
|---|
| 2564 | <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">5</a>, <a href="#rfc.iref.5.6"><b>9.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> |
|---|
| 2565 | </ul> |
|---|
| 2566 | </li> |
|---|
| 2567 | <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> |
|---|
| 2568 | <li>Allow header <a href="#rfc.xref.header.allow.1">3</a>, <a href="#rfc.xref.header.allow.2">6</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.2</a></li> |
|---|
| 2569 | </ul> |
|---|
| 2570 | </li> |
|---|
| 2571 | <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> |
|---|
| 2572 | <li>CONNECT method <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c.1"><b>8.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a></li> |
|---|
| 2573 | </ul> |
|---|
| 2574 | </li> |
|---|
| 2575 | <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> |
|---|
| 2576 | <li>DELETE method <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>8.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> |
|---|
| 2577 | </ul> |
|---|
| 2578 | </li> |
|---|
| 2579 | <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> |
|---|
| 2580 | <li>Expect header <a href="#rfc.xref.header.expect.1">4</a>, <a href="#rfc.xref.header.expect.2">9.4.18</a>, <a href="#rfc.iref.e.1"><b>10.2</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a></li> |
|---|
| 2581 | </ul> |
|---|
| 2582 | </li> |
|---|
| 2583 | <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> |
|---|
| 2584 | <li>From header <a href="#rfc.xref.header.from.1">4</a>, <a href="#rfc.iref.f.1"><b>10.3</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> |
|---|
| 2585 | </ul> |
|---|
| 2586 | </li> |
|---|
| 2587 | <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> |
|---|
| 2588 | <li>GET method <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.8"><b>8.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> |
|---|
| 2589 | <li><tt>Grammar</tt> |
|---|
| 2590 | <ul> |
|---|
| 2591 | <li><tt>Allow</tt> <a href="#rfc.iref.g.9"><b>10.1</b></a></li> |
|---|
| 2592 | <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.19"><b>10.7</b></a></li> |
|---|
| 2593 | <li><tt>Expect</tt> <a href="#rfc.iref.g.10"><b>10.2</b></a></li> |
|---|
| 2594 | <li><tt>expect-params</tt> <a href="#rfc.iref.g.13"><b>10.2</b></a></li> |
|---|
| 2595 | <li><tt>expectation</tt> <a href="#rfc.iref.g.11"><b>10.2</b></a></li> |
|---|
| 2596 | <li><tt>expectation-extension</tt> <a href="#rfc.iref.g.12"><b>10.2</b></a></li> |
|---|
| 2597 | <li><tt>extension-code</tt> <a href="#rfc.iref.g.5"><b>5</b></a></li> |
|---|
| 2598 | <li><tt>extension-method</tt> <a href="#rfc.iref.g.2"><b>3</b></a></li> |
|---|
| 2599 | <li><tt>From</tt> <a href="#rfc.iref.g.14"><b>10.3</b></a></li> |
|---|
| 2600 | <li><tt>Location</tt> <a href="#rfc.iref.g.15"><b>10.4</b></a></li> |
|---|
| 2601 | <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.16"><b>10.5</b></a></li> |
|---|
| 2602 | <li><tt>Method</tt> <a href="#rfc.iref.g.1"><b>3</b></a></li> |
|---|
| 2603 | <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.6"><b>5</b></a></li> |
|---|
| 2604 | <li><tt>Referer</tt> <a href="#rfc.iref.g.17"><b>10.6</b></a></li> |
|---|
| 2605 | <li><tt>request-header</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> |
|---|
| 2606 | <li><tt>response-header</tt> <a href="#rfc.iref.g.7"><b>6</b></a></li> |
|---|
| 2607 | <li><tt>Retry-After</tt> <a href="#rfc.iref.g.18"><b>10.7</b></a></li> |
|---|
| 2608 | <li><tt>Server</tt> <a href="#rfc.iref.g.20"><b>10.8</b></a></li> |
|---|
| 2609 | <li><tt>Status-Code</tt> <a href="#rfc.iref.g.4"><b>5</b></a></li> |
|---|
| 2610 | <li><tt>User-Agent</tt> <a href="#rfc.iref.g.21"><b>10.9</b></a></li> |
|---|
| 2611 | </ul> |
|---|
| 2612 | </li> |
|---|
| 2613 | </ul> |
|---|
| 2614 | </li> |
|---|
| 2615 | <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> |
|---|
| 2616 | <li>HEAD method <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>8.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> |
|---|
| 2617 | <li>Headers |
|---|
| 2618 | <ul> |
|---|
| 2619 | <li>Allow <a href="#rfc.xref.header.allow.1">3</a>, <a href="#rfc.xref.header.allow.2">6</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.2</a></li> |
|---|
| 2620 | <li>Expect <a href="#rfc.xref.header.expect.1">4</a>, <a href="#rfc.xref.header.expect.2">9.4.18</a>, <a href="#rfc.iref.h.3"><b>10.2</b></a>, <a href="#rfc.xref.header.expect.3">11.3</a></li> |
|---|
| 2621 | <li>From <a href="#rfc.xref.header.from.1">4</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a>, <a href="#rfc.xref.header.from.2">11.3</a></li> |
|---|
| 2622 | <li>Location <a href="#rfc.xref.header.location.1">6</a>, <a href="#rfc.xref.header.location.2">8.5</a>, <a href="#rfc.iref.h.5"><b>10.4</b></a>, <a href="#rfc.xref.header.location.3">11.3</a>, <a href="#rfc.xref.header.location.4">A.2</a></li> |
|---|
| 2623 | <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">4</a>, <a href="#rfc.xref.header.max-forwards.2">8.8</a>, <a href="#rfc.iref.h.6"><b>10.5</b></a>, <a href="#rfc.xref.header.max-forwards.3">11.3</a></li> |
|---|
| 2624 | <li>Referer <a href="#rfc.xref.header.referer.1">4</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a></li> |
|---|
| 2625 | <li>Retry-After <a href="#rfc.xref.header.retry-after.1">6</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a>, <a href="#rfc.xref.header.retry-after.2">11.3</a></li> |
|---|
| 2626 | <li>Server <a href="#rfc.xref.header.server.1">6</a>, <a href="#rfc.iref.h.9"><b>10.8</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.2</a></li> |
|---|
| 2627 | <li>User-Agent <a href="#rfc.xref.header.user-agent.1">4</a>, <a href="#rfc.iref.h.10"><b>10.9</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> |
|---|
| 2628 | </ul> |
|---|
| 2629 | </li> |
|---|
| 2630 | </ul> |
|---|
| 2631 | </li> |
|---|
| 2632 | <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> |
|---|
| 2633 | <li>Idempotent Methods <a href="#rfc.iref.i.1"><b>8.1.2</b></a></li> |
|---|
| 2634 | </ul> |
|---|
| 2635 | </li> |
|---|
| 2636 | <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> |
|---|
| 2637 | <li>LINK method <a href="#rfc.iref.l.2"><b>A.1</b></a></li> |
|---|
| 2638 | <li>Location header <a href="#rfc.xref.header.location.1">6</a>, <a href="#rfc.xref.header.location.2">8.5</a>, <a href="#rfc.iref.l.1"><b>10.4</b></a>, <a href="#rfc.xref.header.location.3">11.3</a>, <a href="#rfc.xref.header.location.4">A.2</a></li> |
|---|
| 2639 | </ul> |
|---|
| 2640 | </li> |
|---|
| 2641 | <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> |
|---|
| 2642 | <li>Max-Forwards header <a href="#rfc.xref.header.max-forwards.1">4</a>, <a href="#rfc.xref.header.max-forwards.2">8.8</a>, <a href="#rfc.iref.m.9"><b>10.5</b></a>, <a href="#rfc.xref.header.max-forwards.3">11.3</a></li> |
|---|
| 2643 | <li>Methods |
|---|
| 2644 | <ul> |
|---|
| 2645 | <li>CONNECT <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>8.9</b></a>, <a href="#rfc.xref.CONNECT.2">11.1</a></li> |
|---|
| 2646 | <li>DELETE <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>8.7</b></a>, <a href="#rfc.xref.DELETE.2">11.1</a></li> |
|---|
| 2647 | <li>GET <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>8.3</b></a>, <a href="#rfc.xref.GET.2">11.1</a></li> |
|---|
| 2648 | <li>HEAD <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>8.4</b></a>, <a href="#rfc.xref.HEAD.2">11.1</a></li> |
|---|
| 2649 | <li>LINK <a href="#rfc.iref.m.11"><b>A.1</b></a></li> |
|---|
| 2650 | <li>OPTIONS <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.m.1"><b>8.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.5</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> |
|---|
| 2651 | <li>PATCH <a href="#rfc.iref.m.10"><b>A.1</b></a></li> |
|---|
| 2652 | <li>POST <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.m.4"><b>8.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A.2</a></li> |
|---|
| 2653 | <li>PUT <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>8.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a></li> |
|---|
| 2654 | <li>TRACE <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.m.7"><b>8.8</b></a>, <a href="#rfc.xref.TRACE.2">10.5</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li> |
|---|
| 2655 | <li>UNLINK <a href="#rfc.iref.m.12"><b>A.1</b></a></li> |
|---|
| 2656 | </ul> |
|---|
| 2657 | </li> |
|---|
| 2658 | </ul> |
|---|
| 2659 | </li> |
|---|
| 2660 | <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> |
|---|
| 2661 | <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">3</a>, <a href="#rfc.iref.o.1"><b>8.2</b></a>, <a href="#rfc.xref.OPTIONS.2">10.5</a>, <a href="#rfc.xref.OPTIONS.3">11.1</a></li> |
|---|
| 2662 | </ul> |
|---|
| 2663 | </li> |
|---|
| 2664 | <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> |
|---|
| 2665 | <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">2</a>, <a href="#rfc.xref.Part1.3">2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">2</a>, <a href="#rfc.xref.Part1.8">2</a>, <a href="#rfc.xref.Part1.9">2</a>, <a href="#rfc.xref.Part1.10">2</a>, <a href="#rfc.xref.Part1.11">2</a>, <a href="#rfc.xref.Part1.12">2</a>, <a href="#rfc.xref.Part1.13">2</a>, <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.15">4</a>, <a href="#rfc.xref.Part1.16">4</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#rfc.xref.Part1.18">8.8</a>, <a href="#rfc.xref.Part1.19">8.8</a>, <a href="#rfc.xref.Part1.20">9.1.1</a>, <a href="#rfc.xref.Part1.21">9.5.6</a>, <a href="#rfc.xref.Part1.22">10.2</a>, <a href="#rfc.xref.Part1.23">10.8</a>, <a href="#rfc.xref.Part1.24">10.8</a>, <a href="#rfc.xref.Part1.25">10.9</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.26">A.2</a><ul> |
|---|
| 2666 | <li><em>Section 2.1</em> <a href="#rfc.xref.Part1.2">2</a></li> |
|---|
| 2667 | <li><em>Section 2.2</em> <a href="#rfc.xref.Part1.3">2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">2</a></li> |
|---|
| 2668 | <li><em>Section 3.1</em> <a href="#rfc.xref.Part1.21">9.5.6</a></li> |
|---|
| 2669 | <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.8">2</a>, <a href="#rfc.xref.Part1.9">2</a>, <a href="#rfc.xref.Part1.13">2</a></li> |
|---|
| 2670 | <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.11">2</a></li> |
|---|
| 2671 | <li><em>Section 3.5</em> <a href="#rfc.xref.Part1.12">2</a>, <a href="#rfc.xref.Part1.23">10.8</a>, <a href="#rfc.xref.Part1.25">10.9</a></li> |
|---|
| 2672 | <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.17">7</a></li> |
|---|
| 2673 | <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.20">9.1.1</a>, <a href="#rfc.xref.Part1.22">10.2</a></li> |
|---|
| 2674 | <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.10">2</a>, <a href="#rfc.xref.Part1.15">4</a></li> |
|---|
| 2675 | <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.16">4</a></li> |
|---|
| 2676 | <li><em>Section 8.9</em> <a href="#rfc.xref.Part1.18">8.8</a>, <a href="#rfc.xref.Part1.24">10.8</a>, <a href="#rfc.xref.Part1.26">A.2</a></li> |
|---|
| 2677 | <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.19">8.8</a></li> |
|---|
| 2678 | </ul> |
|---|
| 2679 | </li> |
|---|
| 2680 | <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2</a>, <a href="#rfc.xref.Part3.2">2</a>, <a href="#rfc.xref.Part3.3">2</a>, <a href="#rfc.xref.Part3.4">2</a>, <a href="#rfc.xref.Part3.5">4</a>, <a href="#rfc.xref.Part3.6">4</a>, <a href="#rfc.xref.Part3.7">4</a>, <a href="#rfc.xref.Part3.8">4</a>, <a href="#rfc.xref.Part3.9">7</a>, <a href="#rfc.xref.Part3.10">9.3.1</a>, <a href="#rfc.xref.Part3.11">10.4</a>, <a href="#Part3"><b>14.1</b></a><ul> |
|---|
| 2681 | <li><em>Section 5</em> <a href="#rfc.xref.Part3.10">9.3.1</a></li> |
|---|
| 2682 | <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">2</a>, <a href="#rfc.xref.Part3.5">4</a></li> |
|---|
| 2683 | <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">2</a>, <a href="#rfc.xref.Part3.6">4</a></li> |
|---|
| 2684 | <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">2</a>, <a href="#rfc.xref.Part3.7">4</a></li> |
|---|
| 2685 | <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">2</a>, <a href="#rfc.xref.Part3.8">4</a></li> |
|---|
| 2686 | <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.11">10.4</a></li> |
|---|
| 2687 | </ul> |
|---|
| 2688 | </li> |
|---|
| 2689 | <li><em>Part4</em> <a href="#rfc.xref.Part4.1">2</a>, <a href="#rfc.xref.Part4.2">2</a>, <a href="#rfc.xref.Part4.3">2</a>, <a href="#rfc.xref.Part4.4">2</a>, <a href="#rfc.xref.Part4.5">2</a>, <a href="#rfc.xref.Part4.6">4</a>, <a href="#rfc.xref.Part4.7">4</a>, <a href="#rfc.xref.Part4.8">4</a>, <a href="#rfc.xref.Part4.9">4</a>, <a href="#rfc.xref.Part4.10">6</a>, <a href="#rfc.xref.Part4.11">9.2.2</a>, <a href="#rfc.xref.Part4.12">9.3.5</a>, <a href="#rfc.xref.Part4.13">9.4.13</a>, <a href="#Part4"><b>14.1</b></a>, <a href="#rfc.xref.Part4.14">B.2</a><ul> |
|---|
| 2690 | <li><em>Section 7.1</em> <a href="#rfc.xref.Part4.1">2</a>, <a href="#rfc.xref.Part4.10">6</a>, <a href="#rfc.xref.Part4.11">9.2.2</a></li> |
|---|
| 2691 | <li><em>Section 7.2</em> <a href="#rfc.xref.Part4.2">2</a>, <a href="#rfc.xref.Part4.6">4</a></li> |
|---|
| 2692 | <li><em>Section 7.3</em> <a href="#rfc.xref.Part4.3">2</a>, <a href="#rfc.xref.Part4.7">4</a></li> |
|---|
| 2693 | <li><em>Section 7.4</em> <a href="#rfc.xref.Part4.4">2</a>, <a href="#rfc.xref.Part4.8">4</a></li> |
|---|
| 2694 | <li><em>Section 7.5</em> <a href="#rfc.xref.Part4.5">2</a>, <a href="#rfc.xref.Part4.9">4</a></li> |
|---|
| 2695 | </ul> |
|---|
| 2696 | </li> |
|---|
| 2697 | <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2</a>, <a href="#rfc.xref.Part5.2">2</a>, <a href="#rfc.xref.Part5.3">2</a>, <a href="#rfc.xref.Part5.4">4</a>, <a href="#rfc.xref.Part5.5">4</a>, <a href="#rfc.xref.Part5.6">6</a>, <a href="#rfc.xref.Part5.7">8.3</a>, <a href="#rfc.xref.Part5.8">9.1.2</a>, <a href="#rfc.xref.Part5.9">9.2.7</a>, <a href="#rfc.xref.Part5.10">9.4.17</a>, <a href="#Part5"><b>14.1</b></a><ul> |
|---|
| 2698 | <li><em>Section 6.1</em> <a href="#rfc.xref.Part5.1">2</a>, <a href="#rfc.xref.Part5.6">6</a></li> |
|---|
| 2699 | <li><em>Section 6.3</em> <a href="#rfc.xref.Part5.2">2</a>, <a href="#rfc.xref.Part5.4">4</a></li> |
|---|
| 2700 | <li><em>Section 6.4</em> <a href="#rfc.xref.Part5.3">2</a>, <a href="#rfc.xref.Part5.5">4</a>, <a href="#rfc.xref.Part5.7">8.3</a>, <a href="#rfc.xref.Part5.8">9.1.2</a>, <a href="#rfc.xref.Part5.10">9.4.17</a></li> |
|---|
| 2701 | </ul> |
|---|
| 2702 | </li> |
|---|
| 2703 | <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2</a>, <a href="#rfc.xref.Part6.2">2</a>, <a href="#rfc.xref.Part6.3">6</a>, <a href="#rfc.xref.Part6.4">6</a>, <a href="#rfc.xref.Part6.5">8.3</a>, <a href="#Part6"><b>14.1</b></a><ul> |
|---|
| 2704 | <li><em>Section 16.1</em> <a href="#rfc.xref.Part6.1">2</a>, <a href="#rfc.xref.Part6.3">6</a></li> |
|---|
| 2705 | <li><em>Section 16.5</em> <a href="#rfc.xref.Part6.2">2</a>, <a href="#rfc.xref.Part6.4">6</a></li> |
|---|
| 2706 | </ul> |
|---|
| 2707 | </li> |
|---|
| 2708 | <li><em>Part7</em> <a href="#rfc.xref.Part7.1">2</a>, <a href="#rfc.xref.Part7.2">2</a>, <a href="#rfc.xref.Part7.3">2</a>, <a href="#rfc.xref.Part7.4">2</a>, <a href="#rfc.xref.Part7.5">4</a>, <a href="#rfc.xref.Part7.6">4</a>, <a href="#rfc.xref.Part7.7">6</a>, <a href="#rfc.xref.Part7.8">6</a>, <a href="#rfc.xref.Part7.9">9.4.2</a>, <a href="#rfc.xref.Part7.10">9.4.8</a>, <a href="#Part7"><b>14.1</b></a><ul> |
|---|
| 2709 | <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">2</a>, <a href="#rfc.xref.Part7.5">4</a></li> |
|---|
| 2710 | <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.2">2</a>, <a href="#rfc.xref.Part7.7">6</a></li> |
|---|
| 2711 | <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.3">2</a>, <a href="#rfc.xref.Part7.6">4</a></li> |
|---|
| 2712 | <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.4">2</a>, <a href="#rfc.xref.Part7.8">6</a></li> |
|---|
| 2713 | </ul> |
|---|
| 2714 | </li> |
|---|
| 2715 | <li>PATCH method <a href="#rfc.iref.p.3"><b>A.1</b></a></li> |
|---|
| 2716 | <li>POST method <a href="#rfc.xref.POST.1">3</a>, <a href="#rfc.iref.p.1"><b>8.5</b></a>, <a href="#rfc.xref.POST.2">11.1</a>, <a href="#rfc.xref.POST.3">A.2</a></li> |
|---|
| 2717 | <li>PUT method <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>8.6</b></a>, <a href="#rfc.xref.PUT.2">11.1</a></li> |
|---|
| 2718 | </ul> |
|---|
| 2719 | </li> |
|---|
| 2720 | <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> |
|---|
| 2721 | <li>Referer header <a href="#rfc.xref.header.referer.1">4</a>, <a href="#rfc.iref.r.1"><b>10.6</b></a>, <a href="#rfc.xref.header.referer.2">11.3</a></li> |
|---|
| 2722 | <li>Retry-After header <a href="#rfc.xref.header.retry-after.1">6</a>, <a href="#rfc.iref.r.2"><b>10.7</b></a>, <a href="#rfc.xref.header.retry-after.2">11.3</a></li> |
|---|
| 2723 | <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">9.3.3</a>, <a href="#RFC1945"><b>14.2</b></a></li> |
|---|
| 2724 | <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">9.3.3</a>, <a href="#RFC2068"><b>14.2</b></a>, <a href="#rfc.xref.RFC2068.2">A.1</a><ul> |
|---|
| 2725 | <li><em>Section 19.6.1</em> <a href="#rfc.xref.RFC2068.2">A.1</a></li> |
|---|
| 2726 | </ul> |
|---|
| 2727 | </li> |
|---|
| 2728 | <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>14.1</b></a></li> |
|---|
| 2729 | <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>14.2</b></a>, <a href="#rfc.xref.RFC2616.2">B.1</a></li> |
|---|
| 2730 | <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">8.9</a>, <a href="#rfc.xref.RFC2817.2">11.2</a>, <a href="#RFC2817"><b>14.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul> |
|---|
| 2731 | <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.2">11.2</a>, <a href="#rfc.xref.RFC2817.3">A.2</a></li> |
|---|
| 2732 | </ul> |
|---|
| 2733 | </li> |
|---|
| 2734 | <li><em>RFC2822</em> <a href="#rfc.xref.RFC2822.1">10.3</a>, <a href="#rfc.xref.RFC2822.2">10.3</a>, <a href="#RFC2822"><b>14.2</b></a><ul> |
|---|
| 2735 | <li><em>Section 3.4</em> <a href="#rfc.xref.RFC2822.1">10.3</a>, <a href="#rfc.xref.RFC2822.2">10.3</a></li> |
|---|
| 2736 | </ul> |
|---|
| 2737 | </li> |
|---|
| 2738 | <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">11.3</a>, <a href="#RFC3864"><b>14.2</b></a></li> |
|---|
| 2739 | <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">3.1</a>, <a href="#rfc.xref.RFC5226.2">5.1</a>, <a href="#RFC5226"><b>14.2</b></a><ul> |
|---|
| 2740 | <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">3.1</a>, <a href="#rfc.xref.RFC5226.2">5.1</a></li> |
|---|
| 2741 | </ul> |
|---|
| 2742 | </li> |
|---|
| 2743 | </ul> |
|---|
| 2744 | </li> |
|---|
| 2745 | <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> |
|---|
| 2746 | <li>Safe Methods <a href="#rfc.iref.s.1"><b>8.1.1</b></a></li> |
|---|
| 2747 | <li>Server header <a href="#rfc.xref.header.server.1">6</a>, <a href="#rfc.iref.s.43"><b>10.8</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.2</a></li> |
|---|
| 2748 | <li>Status Codes |
|---|
| 2749 | <ul> |
|---|
| 2750 | <li>100 Continue <a href="#rfc.xref.status.100.1">5</a>, <a href="#rfc.iref.s.2"><b>9.1.1</b></a>, <a href="#rfc.xref.status.100.2">11.2</a></li> |
|---|
| 2751 | <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">5</a>, <a href="#rfc.iref.s.3"><b>9.1.2</b></a>, <a href="#rfc.xref.status.101.2">11.2</a></li> |
|---|
| 2752 | <li>200 OK <a href="#rfc.xref.status.200.1">5</a>, <a href="#rfc.iref.s.4"><b>9.2.1</b></a>, <a href="#rfc.xref.status.200.2">11.2</a></li> |
|---|
| 2753 | <li>201 Created <a href="#rfc.xref.status.201.1">5</a>, <a href="#rfc.iref.s.5"><b>9.2.2</b></a>, <a href="#rfc.xref.status.201.2">11.2</a>, <a href="#rfc.xref.status.201.3">A.1</a></li> |
|---|
| 2754 | <li>202 Accepted <a href="#rfc.xref.status.202.1">5</a>, <a href="#rfc.iref.s.6"><b>9.2.3</b></a>, <a href="#rfc.xref.status.202.2">11.2</a></li> |
|---|
| 2755 | <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">5</a>, <a href="#rfc.iref.s.7"><b>9.2.4</b></a>, <a href="#rfc.xref.status.203.2">11.2</a></li> |
|---|
| 2756 | <li>204 No Content <a href="#rfc.xref.status.204.1">5</a>, <a href="#rfc.iref.s.8"><b>9.2.5</b></a>, <a href="#rfc.xref.status.204.2">11.2</a></li> |
|---|
| 2757 | <li>205 Reset Content <a href="#rfc.xref.status.205.1">5</a>, <a href="#rfc.iref.s.9"><b>9.2.6</b></a>, <a href="#rfc.xref.status.205.2">11.2</a></li> |
|---|
| 2758 | <li>206 Partial Content <a href="#rfc.xref.status.206.1">5</a>, <a href="#rfc.iref.s.10"><b>9.2.7</b></a>, <a href="#rfc.xref.status.206.2">11.2</a></li> |
|---|
| 2759 | <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">5</a>, <a href="#rfc.iref.s.11"><b>9.3.1</b></a>, <a href="#rfc.xref.status.300.2">11.2</a></li> |
|---|
| 2760 | <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">5</a>, <a href="#rfc.iref.s.12"><b>9.3.2</b></a>, <a href="#rfc.xref.status.301.2">11.2</a>, <a href="#rfc.xref.status.301.3">A.2</a></li> |
|---|
| 2761 | <li>302 Found <a href="#rfc.xref.status.302.1">5</a>, <a href="#rfc.iref.s.13"><b>9.3.3</b></a>, <a href="#rfc.xref.status.302.2">11.2</a>, <a href="#rfc.xref.status.302.3">A.2</a></li> |
|---|
| 2762 | <li>303 See Other <a href="#rfc.xref.status.303.1">5</a>, <a href="#rfc.iref.s.14"><b>9.3.4</b></a>, <a href="#rfc.xref.status.303.2">11.2</a></li> |
|---|
| 2763 | <li>304 Not Modified <a href="#rfc.xref.status.304.1">5</a>, <a href="#rfc.iref.s.15"><b>9.3.5</b></a>, <a href="#rfc.xref.status.304.2">11.2</a></li> |
|---|
| 2764 | <li>305 Use Proxy <a href="#rfc.xref.status.305.1">5</a>, <a href="#rfc.iref.s.16"><b>9.3.6</b></a>, <a href="#rfc.xref.status.305.2">11.2</a>, <a href="#rfc.xref.status.305.3">A.2</a></li> |
|---|
| 2765 | <li>306 (Unused) <a href="#rfc.iref.s.17"><b>9.3.7</b></a>, <a href="#rfc.xref.status.306.1">11.2</a></li> |
|---|
| 2766 | <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">5</a>, <a href="#rfc.iref.s.18"><b>9.3.8</b></a>, <a href="#rfc.xref.status.307.2">11.2</a>, <a href="#rfc.xref.status.307.3">A.2</a></li> |
|---|
| 2767 | <li>400 Bad Request <a href="#rfc.xref.status.400.1">5</a>, <a href="#rfc.iref.s.19"><b>9.4.1</b></a>, <a href="#rfc.xref.status.400.2">11.2</a></li> |
|---|
| 2768 | <li>401 Unauthorized <a href="#rfc.xref.status.401.1">5</a>, <a href="#rfc.iref.s.20"><b>9.4.2</b></a>, <a href="#rfc.xref.status.401.2">11.2</a></li> |
|---|
| 2769 | <li>402 Payment Required <a href="#rfc.xref.status.402.1">5</a>, <a href="#rfc.iref.s.21"><b>9.4.3</b></a>, <a href="#rfc.xref.status.402.2">11.2</a></li> |
|---|
| 2770 | <li>403 Forbidden <a href="#rfc.xref.status.403.1">5</a>, <a href="#rfc.iref.s.22"><b>9.4.4</b></a>, <a href="#rfc.xref.status.403.2">11.2</a>, <a href="#rfc.xref.status.403.3">A.1</a></li> |
|---|
| 2771 | <li>404 Not Found <a href="#rfc.xref.status.404.1">5</a>, <a href="#rfc.iref.s.23"><b>9.4.5</b></a>, <a href="#rfc.xref.status.404.2">11.2</a>, <a href="#rfc.xref.status.404.3">A.1</a></li> |
|---|
| 2772 | <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">5</a>, <a href="#rfc.iref.s.24"><b>9.4.6</b></a>, <a href="#rfc.xref.status.405.2">11.2</a></li> |
|---|
| 2773 | <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">5</a>, <a href="#rfc.iref.s.25"><b>9.4.7</b></a>, <a href="#rfc.xref.status.406.2">11.2</a></li> |
|---|
| 2774 | <li>407 Proxy Authentication Required <a href="#rfc.xref.status.407.1">5</a>, <a href="#rfc.iref.s.26"><b>9.4.8</b></a>, <a href="#rfc.xref.status.407.2">11.2</a></li> |
|---|
| 2775 | <li>408 Request Timeout <a href="#rfc.xref.status.408.1">5</a>, <a href="#rfc.iref.s.27"><b>9.4.9</b></a>, <a href="#rfc.xref.status.408.2">11.2</a></li> |
|---|
| 2776 | <li>409 Conflict <a href="#rfc.xref.status.409.1">5</a>, <a href="#rfc.iref.s.28"><b>9.4.10</b></a>, <a href="#rfc.xref.status.409.2">11.2</a></li> |
|---|
| 2777 | <li>410 Gone <a href="#rfc.xref.status.410.1">5</a>, <a href="#rfc.iref.s.29"><b>9.4.11</b></a>, <a href="#rfc.xref.status.410.2">11.2</a>, <a href="#rfc.xref.status.410.3">A.1</a></li> |
|---|
| 2778 | <li>411 Length Required <a href="#rfc.xref.status.411.1">5</a>, <a href="#rfc.iref.s.30"><b>9.4.12</b></a>, <a href="#rfc.xref.status.411.2">11.2</a></li> |
|---|
| 2779 | <li>412 Precondition Failed <a href="#rfc.xref.status.412.1">5</a>, <a href="#rfc.iref.s.31"><b>9.4.13</b></a>, <a href="#rfc.xref.status.412.2">11.2</a></li> |
|---|
| 2780 | <li>413 Request Entity Too Large <a href="#rfc.xref.status.413.1">5</a>, <a href="#rfc.iref.s.32"><b>9.4.14</b></a>, <a href="#rfc.xref.status.413.2">11.2</a></li> |
|---|
| 2781 | <li>414 Request-URI Too Long <a href="#rfc.xref.status.414.1">5</a>, <a href="#rfc.iref.s.33"><b>9.4.15</b></a>, <a href="#rfc.xref.status.414.2">11.2</a></li> |
|---|
| 2782 | <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">5</a>, <a href="#rfc.iref.s.34"><b>9.4.16</b></a>, <a href="#rfc.xref.status.415.2">11.2</a></li> |
|---|
| 2783 | <li>416 Requested Range Not Satisfiable <a href="#rfc.xref.status.416.1">5</a>, <a href="#rfc.iref.s.35"><b>9.4.17</b></a>, <a href="#rfc.xref.status.416.2">11.2</a></li> |
|---|
| 2784 | <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">5</a>, <a href="#rfc.iref.s.36"><b>9.4.18</b></a>, <a href="#rfc.xref.status.417.2">11.2</a></li> |
|---|
| 2785 | <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">5</a>, <a href="#rfc.iref.s.37"><b>9.5.1</b></a>, <a href="#rfc.xref.status.500.2">11.2</a></li> |
|---|
| 2786 | <li>501 Not Implemented <a href="#rfc.xref.status.501.1">5</a>, <a href="#rfc.iref.s.38"><b>9.5.2</b></a>, <a href="#rfc.xref.status.501.2">11.2</a></li> |
|---|
| 2787 | <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">5</a>, <a href="#rfc.iref.s.39"><b>9.5.3</b></a>, <a href="#rfc.xref.status.502.2">11.2</a></li> |
|---|
| 2788 | <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">5</a>, <a href="#rfc.iref.s.40"><b>9.5.4</b></a>, <a href="#rfc.xref.status.503.2">11.2</a></li> |
|---|
| 2789 | <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">5</a>, <a href="#rfc.iref.s.41"><b>9.5.5</b></a>, <a href="#rfc.xref.status.504.2">11.2</a>, <a href="#rfc.xref.status.504.3">A.1</a></li> |
|---|
| 2790 | <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">5</a>, <a href="#rfc.iref.s.42"><b>9.5.6</b></a>, <a href="#rfc.xref.status.505.2">11.2</a></li> |
|---|
| 2791 | </ul> |
|---|
| 2792 | </li> |
|---|
| 2793 | </ul> |
|---|
| 2794 | </li> |
|---|
| 2795 | <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> |
|---|
| 2796 | <li>TRACE method <a href="#rfc.xref.TRACE.1">3</a>, <a href="#rfc.iref.t.1"><b>8.8</b></a>, <a href="#rfc.xref.TRACE.2">10.5</a>, <a href="#rfc.xref.TRACE.3">11.1</a></li> |
|---|
| 2797 | </ul> |
|---|
| 2798 | </li> |
|---|
| 2799 | <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> |
|---|
| 2800 | <li>UNLINK method <a href="#rfc.iref.u.2"><b>A.1</b></a></li> |
|---|
| 2801 | <li>User-Agent header <a href="#rfc.xref.header.user-agent.1">4</a>, <a href="#rfc.iref.u.1"><b>10.9</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> |
|---|
| 2802 | </ul> |
|---|
| 2803 | </li> |
|---|
| 2804 | </ul> |
|---|
| 2805 | </div> |
|---|
| 2806 | <div class="avoidbreak"> |
|---|
| 2807 | <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> |
|---|
| 2808 | <p><b>Roy T. Fielding</b> |
|---|
| 2809 | (editor) |
|---|
| 2810 | <br>Day Software<br>23 Corporate Plaza DR, Suite 280<br>Newport Beach, CA 92660<br>USA<br>Phone: <a href="tel:+1-949-706-5300">+1-949-706-5300</a><br>Fax: <a href="fax:+1-949-706-5305">+1-949-706-5305</a><br>EMail: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p> |
|---|
| 2811 | <p><b>Jim Gettys</b><br>One Laptop per Child<br>21 Oak Knoll Road<br>Carlisle, MA 01741<br>USA<br>EMail: <a href="mailto:jg@laptop.org">jg@laptop.org</a><br>URI: <a href="http://www.laptop.org/">http://www.laptop.org/</a></p> |
|---|
| 2812 | <p><b>Jeffrey C. Mogul</b><br>Hewlett-Packard Company<br>HP Labs, Large Scale Systems Group<br>1501 Page Mill Road, MS 1177<br>Palo Alto, CA 94304<br>USA<br>EMail: <a href="mailto:JeffMogul@acm.org">JeffMogul@acm.org</a></p> |
|---|
| 2813 | <p><b>Henrik Frystyk Nielsen</b><br>Microsoft Corporation<br>1 Microsoft Way<br>Redmond, WA 98052<br>USA<br>EMail: <a href="mailto:henrikn@microsoft.com">henrikn@microsoft.com</a></p> |
|---|
| 2814 | <p><b>Larry Masinter</b><br>Adobe Systems, Incorporated<br>345 Park Ave<br>San Jose, CA 95110<br>USA<br>EMail: <a href="mailto:LMM@acm.org">LMM@acm.org</a><br>URI: <a href="http://larry.masinter.net/">http://larry.masinter.net/</a></p> |
|---|
| 2815 | <p><b>Paul J. Leach</b><br>Microsoft Corporation<br>1 Microsoft Way<br>Redmond, WA 98052<br>EMail: <a href="mailto:paulle@microsoft.com">paulle@microsoft.com</a></p> |
|---|
| 2816 | <p><b>Tim Berners-Lee</b><br>World Wide Web Consortium<br>MIT Computer Science and Artificial Intelligence Laboratory<br>The Stata Center, Building 32<br>32 Vassar Street<br>Cambridge, MA 02139<br>USA<br>EMail: <a href="mailto:timbl@w3.org">timbl@w3.org</a><br>URI: <a href="http://www.w3.org/People/Berners-Lee/">http://www.w3.org/People/Berners-Lee/</a></p> |
|---|
| 2817 | <p><b>Yves Lafon</b> |
|---|
| 2818 | (editor) |
|---|
| 2819 | <br>World Wide Web Consortium<br>W3C / ERCIM<br>2004, rte des Lucioles<br>Sophia-Antipolis, AM 06902<br>France<br>EMail: <a href="mailto:ylafon@w3.org">ylafon@w3.org</a><br>URI: <a href="http://www.raubacapeu.net/people/yves/">http://www.raubacapeu.net/people/yves/</a></p> |
|---|
| 2820 | <p><b>Julian F. Reschke</b> |
|---|
| 2821 | (editor) |
|---|
| 2822 | <br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW 48155<br>Germany<br>Phone: <a href="tel:+492512807760">+49 251 2807760</a><br>Fax: <a href="fax:+492512807761">+49 251 2807761</a><br>EMail: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p> |
|---|
| 2823 | </div> |
|---|
| 2824 | <div id="rfc.copyright"> |
|---|
| 2825 | <h1><a href="#rfc.copyright">Full Copyright Statement</a></h1> |
|---|
| 2826 | <p>Copyright © The IETF Trust (2008).</p> |
|---|
| 2827 | <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the |
|---|
| 2828 | authors retain all their rights. |
|---|
| 2829 | </p> |
|---|
| 2830 | <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION |
|---|
| 2831 | HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE |
|---|
| 2832 | DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN |
|---|
| 2833 | WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
|---|
| 2834 | </p> |
|---|
| 2835 | </div> |
|---|
| 2836 | <div id="rfc.ipr"> |
|---|
| 2837 | <h1><a href="#rfc.ipr">Intellectual Property</a></h1> |
|---|
| 2838 | <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might |
|---|
| 2839 | be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any |
|---|
| 2840 | license under such rights might or might not be available; nor does it represent that it has made any independent effort to |
|---|
| 2841 | identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and |
|---|
| 2842 | BCP 79. |
|---|
| 2843 | </p> |
|---|
| 2844 | <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result |
|---|
| 2845 | of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users |
|---|
| 2846 | of this specification can be obtained from the IETF on-line IPR repository at <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. |
|---|
| 2847 | </p> |
|---|
| 2848 | <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary |
|---|
| 2849 | rights that may cover technology that may be required to implement this standard. Please address the information to the IETF |
|---|
| 2850 | at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>. |
|---|
| 2851 | </p> |
|---|
| 2852 | </div> |
|---|
| 2853 | </body> |
|---|
| 2854 | </html> |
|---|
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
