| [231] | 1 | <!DOCTYPE html |
|---|
| 2 | PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
|---|
| 3 | <html lang="en"> |
|---|
| [1099] | 4 | <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> |
|---|
| [231] | 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: verdana, helvetica, arial, sans-serif; |
|---|
| 27 | font-size: 10pt; |
|---|
| 28 | } |
|---|
| 29 | cite { |
|---|
| 30 | font-style: normal; |
|---|
| 31 | } |
|---|
| 32 | dd { |
|---|
| 33 | margin-right: 2em; |
|---|
| 34 | } |
|---|
| 35 | dl { |
|---|
| 36 | margin-left: 2em; |
|---|
| 37 | } |
|---|
| 38 | |
|---|
| [1099] | 39 | ul.empty { |
|---|
| 40 | list-style-type: none; |
|---|
| 41 | } |
|---|
| 42 | ul.empty li { |
|---|
| [231] | 43 | margin-top: .5em; |
|---|
| 44 | } |
|---|
| 45 | dl p { |
|---|
| 46 | margin-left: 0em; |
|---|
| 47 | } |
|---|
| 48 | dt { |
|---|
| 49 | margin-top: .5em; |
|---|
| 50 | } |
|---|
| 51 | h1 { |
|---|
| 52 | font-size: 14pt; |
|---|
| 53 | line-height: 21pt; |
|---|
| 54 | page-break-after: avoid; |
|---|
| 55 | } |
|---|
| 56 | h1.np { |
|---|
| 57 | page-break-before: always; |
|---|
| 58 | } |
|---|
| 59 | h1 a { |
|---|
| 60 | color: #333333; |
|---|
| 61 | } |
|---|
| 62 | h2 { |
|---|
| 63 | font-size: 12pt; |
|---|
| 64 | line-height: 15pt; |
|---|
| 65 | page-break-after: avoid; |
|---|
| 66 | } |
|---|
| [1099] | 67 | h3, h4, h5, h6 { |
|---|
| [231] | 68 | font-size: 10pt; |
|---|
| 69 | page-break-after: avoid; |
|---|
| 70 | } |
|---|
| [1099] | 71 | h2 a, h3 a, h4 a, h5 a, h6 a { |
|---|
| [231] | 72 | color: black; |
|---|
| 73 | } |
|---|
| 74 | img { |
|---|
| 75 | margin-left: 3em; |
|---|
| 76 | } |
|---|
| 77 | li { |
|---|
| 78 | margin-left: 2em; |
|---|
| 79 | margin-right: 2em; |
|---|
| 80 | } |
|---|
| 81 | ol { |
|---|
| 82 | margin-left: 2em; |
|---|
| 83 | margin-right: 2em; |
|---|
| 84 | } |
|---|
| 85 | ol p { |
|---|
| 86 | margin-left: 0em; |
|---|
| 87 | } |
|---|
| 88 | p { |
|---|
| 89 | margin-left: 2em; |
|---|
| 90 | margin-right: 2em; |
|---|
| 91 | } |
|---|
| 92 | pre { |
|---|
| 93 | margin-left: 3em; |
|---|
| 94 | background-color: lightyellow; |
|---|
| 95 | padding: .25em; |
|---|
| 96 | } |
|---|
| 97 | pre.text2 { |
|---|
| 98 | border-style: dotted; |
|---|
| 99 | border-width: 1px; |
|---|
| 100 | background-color: #f0f0f0; |
|---|
| 101 | width: 69em; |
|---|
| 102 | } |
|---|
| 103 | pre.inline { |
|---|
| 104 | background-color: white; |
|---|
| 105 | padding: 0em; |
|---|
| 106 | } |
|---|
| 107 | pre.text { |
|---|
| 108 | border-style: dotted; |
|---|
| 109 | border-width: 1px; |
|---|
| 110 | background-color: #f8f8f8; |
|---|
| 111 | width: 69em; |
|---|
| 112 | } |
|---|
| 113 | pre.drawing { |
|---|
| 114 | border-style: solid; |
|---|
| 115 | border-width: 1px; |
|---|
| 116 | background-color: #f8f8f8; |
|---|
| 117 | padding: 2em; |
|---|
| 118 | } |
|---|
| 119 | table { |
|---|
| 120 | margin-left: 2em; |
|---|
| 121 | } |
|---|
| 122 | table.header { |
|---|
| [1099] | 123 | border-spacing: 1px; |
|---|
| [231] | 124 | width: 95%; |
|---|
| 125 | font-size: 10pt; |
|---|
| 126 | color: white; |
|---|
| 127 | } |
|---|
| 128 | td.top { |
|---|
| 129 | vertical-align: top; |
|---|
| 130 | } |
|---|
| 131 | td.topnowrap { |
|---|
| 132 | vertical-align: top; |
|---|
| 133 | white-space: nowrap; |
|---|
| 134 | } |
|---|
| [1099] | 135 | table.header td { |
|---|
| [231] | 136 | background-color: gray; |
|---|
| 137 | width: 50%; |
|---|
| 138 | } |
|---|
| [1099] | 139 | table.header a { |
|---|
| [231] | 140 | color: white; |
|---|
| 141 | } |
|---|
| 142 | td.reference { |
|---|
| 143 | vertical-align: top; |
|---|
| 144 | white-space: nowrap; |
|---|
| 145 | padding-right: 1em; |
|---|
| 146 | } |
|---|
| 147 | thead { |
|---|
| 148 | display:table-header-group; |
|---|
| 149 | } |
|---|
| [1099] | 150 | ul.toc, ul.toc ul { |
|---|
| [231] | 151 | list-style: none; |
|---|
| 152 | margin-left: 1.5em; |
|---|
| 153 | margin-right: 0em; |
|---|
| 154 | padding-left: 0em; |
|---|
| 155 | } |
|---|
| [1099] | 156 | ul.toc li { |
|---|
| [231] | 157 | line-height: 150%; |
|---|
| 158 | font-weight: bold; |
|---|
| 159 | font-size: 10pt; |
|---|
| 160 | margin-left: 0em; |
|---|
| 161 | margin-right: 0em; |
|---|
| 162 | } |
|---|
| [1099] | 163 | ul.toc li li { |
|---|
| [231] | 164 | line-height: normal; |
|---|
| 165 | font-weight: normal; |
|---|
| 166 | font-size: 9pt; |
|---|
| 167 | margin-left: 0em; |
|---|
| 168 | margin-right: 0em; |
|---|
| 169 | } |
|---|
| [1099] | 170 | li.excluded { |
|---|
| [231] | 171 | font-size: 0pt; |
|---|
| 172 | } |
|---|
| 173 | ul p { |
|---|
| 174 | margin-left: 0em; |
|---|
| 175 | } |
|---|
| [1099] | 176 | ul.ind, ul.ind ul { |
|---|
| [231] | 177 | list-style: none; |
|---|
| 178 | margin-left: 1.5em; |
|---|
| 179 | margin-right: 0em; |
|---|
| 180 | padding-left: 0em; |
|---|
| [1099] | 181 | page-break-before: avoid; |
|---|
| [231] | 182 | } |
|---|
| [1099] | 183 | ul.ind li { |
|---|
| [231] | 184 | font-weight: bold; |
|---|
| 185 | line-height: 200%; |
|---|
| 186 | margin-left: 0em; |
|---|
| 187 | margin-right: 0em; |
|---|
| 188 | } |
|---|
| [1099] | 189 | ul.ind li li { |
|---|
| [231] | 190 | font-weight: normal; |
|---|
| 191 | line-height: 150%; |
|---|
| 192 | margin-left: 0em; |
|---|
| 193 | margin-right: 0em; |
|---|
| 194 | } |
|---|
| [1099] | 195 | .avoidbreak { |
|---|
| 196 | page-break-inside: avoid; |
|---|
| 197 | } |
|---|
| [231] | 198 | .bcp14 { |
|---|
| 199 | font-style: normal; |
|---|
| 200 | text-transform: lowercase; |
|---|
| 201 | font-variant: small-caps; |
|---|
| 202 | } |
|---|
| 203 | .comment { |
|---|
| 204 | background-color: yellow; |
|---|
| 205 | } |
|---|
| 206 | .center { |
|---|
| 207 | text-align: center; |
|---|
| 208 | } |
|---|
| 209 | .error { |
|---|
| 210 | color: red; |
|---|
| 211 | font-style: italic; |
|---|
| 212 | font-weight: bold; |
|---|
| 213 | } |
|---|
| 214 | .figure { |
|---|
| 215 | font-weight: bold; |
|---|
| 216 | text-align: center; |
|---|
| 217 | font-size: 9pt; |
|---|
| 218 | } |
|---|
| 219 | .filename { |
|---|
| 220 | color: #333333; |
|---|
| 221 | font-weight: bold; |
|---|
| 222 | font-size: 12pt; |
|---|
| 223 | line-height: 21pt; |
|---|
| 224 | text-align: center; |
|---|
| 225 | } |
|---|
| 226 | .fn { |
|---|
| 227 | font-weight: bold; |
|---|
| 228 | } |
|---|
| 229 | .hidden { |
|---|
| 230 | display: none; |
|---|
| 231 | } |
|---|
| 232 | .left { |
|---|
| 233 | text-align: left; |
|---|
| 234 | } |
|---|
| 235 | .right { |
|---|
| 236 | text-align: right; |
|---|
| 237 | } |
|---|
| 238 | .title { |
|---|
| 239 | color: #990000; |
|---|
| 240 | font-size: 18pt; |
|---|
| 241 | line-height: 18pt; |
|---|
| 242 | font-weight: bold; |
|---|
| 243 | text-align: center; |
|---|
| 244 | margin-top: 36pt; |
|---|
| 245 | } |
|---|
| 246 | .vcardline { |
|---|
| 247 | display: block; |
|---|
| 248 | } |
|---|
| 249 | .warning { |
|---|
| 250 | font-size: 14pt; |
|---|
| 251 | background-color: yellow; |
|---|
| 252 | } |
|---|
| 253 | |
|---|
| 254 | |
|---|
| 255 | @media print { |
|---|
| 256 | .noprint { |
|---|
| 257 | display: none; |
|---|
| 258 | } |
|---|
| 259 | |
|---|
| 260 | a { |
|---|
| 261 | color: black; |
|---|
| 262 | text-decoration: none; |
|---|
| 263 | } |
|---|
| 264 | |
|---|
| 265 | table.header { |
|---|
| 266 | width: 90%; |
|---|
| 267 | } |
|---|
| 268 | |
|---|
| 269 | td.header { |
|---|
| 270 | width: 50%; |
|---|
| 271 | color: black; |
|---|
| 272 | background-color: white; |
|---|
| 273 | vertical-align: top; |
|---|
| 274 | font-size: 12pt; |
|---|
| 275 | } |
|---|
| 276 | |
|---|
| 277 | ul.toc a::after { |
|---|
| 278 | content: leader('.') target-counter(attr(href), page); |
|---|
| 279 | } |
|---|
| 280 | |
|---|
| [1099] | 281 | ul.ind li li a { |
|---|
| [231] | 282 | content: target-counter(attr(href), page); |
|---|
| 283 | } |
|---|
| 284 | |
|---|
| 285 | .print2col { |
|---|
| 286 | column-count: 2; |
|---|
| 287 | -moz-column-count: 2; |
|---|
| 288 | column-fill: auto; |
|---|
| 289 | } |
|---|
| 290 | } |
|---|
| 291 | |
|---|
| 292 | @page { |
|---|
| 293 | @top-left { |
|---|
| [1099] | 294 | content: "Internet-Draft"; |
|---|
| [231] | 295 | } |
|---|
| 296 | @top-right { |
|---|
| 297 | content: "February 2008"; |
|---|
| 298 | } |
|---|
| 299 | @top-center { |
|---|
| 300 | content: "HTTP/1.1, Part 2"; |
|---|
| 301 | } |
|---|
| 302 | @bottom-left { |
|---|
| 303 | content: "Fielding, et al."; |
|---|
| 304 | } |
|---|
| 305 | @bottom-center { |
|---|
| 306 | content: "Standards Track"; |
|---|
| 307 | } |
|---|
| 308 | @bottom-right { |
|---|
| 309 | content: "[Page " counter(page) "]"; |
|---|
| 310 | } |
|---|
| 311 | } |
|---|
| 312 | |
|---|
| 313 | @page:first { |
|---|
| 314 | @top-left { |
|---|
| 315 | content: normal; |
|---|
| 316 | } |
|---|
| 317 | @top-right { |
|---|
| 318 | content: normal; |
|---|
| 319 | } |
|---|
| 320 | @top-center { |
|---|
| 321 | content: normal; |
|---|
| 322 | } |
|---|
| 323 | } |
|---|
| 324 | </style><link rel="Contents" href="#rfc.toc"> |
|---|
| 325 | <link rel="Author" href="#rfc.authors"> |
|---|
| 326 | <link rel="Copyright" href="#rfc.copyright"> |
|---|
| 327 | <link rel="Index" href="#rfc.index"> |
|---|
| 328 | <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> |
|---|
| 329 | <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"> |
|---|
| 330 | <link rel="Chapter" title="3 Method" href="#rfc.section.3"> |
|---|
| 331 | <link rel="Chapter" title="4 Request Header Fields" href="#rfc.section.4"> |
|---|
| 332 | <link rel="Chapter" title="5 Status Code and Reason Phrase" href="#rfc.section.5"> |
|---|
| 333 | <link rel="Chapter" title="6 Response Header Fields" href="#rfc.section.6"> |
|---|
| 334 | <link rel="Chapter" title="7 Entity" href="#rfc.section.7"> |
|---|
| 335 | <link rel="Chapter" title="8 Method Definitions" href="#rfc.section.8"> |
|---|
| 336 | <link rel="Chapter" title="9 Status Code Definitions" href="#rfc.section.9"> |
|---|
| 337 | <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10"> |
|---|
| 338 | <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"> |
|---|
| 339 | <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12"> |
|---|
| 340 | <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13"> |
|---|
| 341 | <link rel="Chapter" href="#rfc.section.14" title="14 References"> |
|---|
| 342 | <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> |
|---|
| 343 | <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> |
|---|
| [1099] | 344 | <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.537, 2010-12-30 14:21:59, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> |
|---|
| 345 | <link rel="schema.dct" href="http://purl.org/dc/terms/"> |
|---|
| 346 | <meta name="dct.creator" content="Fielding, R."> |
|---|
| 347 | <meta name="dct.creator" content="Gettys, J."> |
|---|
| 348 | <meta name="dct.creator" content="Mogul, J."> |
|---|
| 349 | <meta name="dct.creator" content="Frystyk, H."> |
|---|
| 350 | <meta name="dct.creator" content="Masinter, L."> |
|---|
| 351 | <meta name="dct.creator" content="Leach, P."> |
|---|
| 352 | <meta name="dct.creator" content="Berners-Lee, T."> |
|---|
| 353 | <meta name="dct.creator" content="Lafon, Y."> |
|---|
| 354 | <meta name="dct.creator" content="Reschke, J. F."> |
|---|
| 355 | <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-02"> |
|---|
| 356 | <meta name="dct.issued" scheme="ISO8601" content="2008-02-24"> |
|---|
| 357 | <meta name="dct.replaces" content="urn:ietf:rfc:2616"> |
|---|
| 358 | <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."> |
|---|
| 359 | <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."> |
|---|
| [231] | 360 | </head> |
|---|
| 361 | <body> |
|---|
| [1099] | 362 | <table class="header"> |
|---|
| 363 | <tbody> |
|---|
| 364 | <tr> |
|---|
| 365 | <td class="left">Network Working Group</td> |
|---|
| 366 | <td class="right">R. Fielding, Editor</td> |
|---|
| 367 | </tr> |
|---|
| 368 | <tr> |
|---|
| 369 | <td class="left">Internet-Draft</td> |
|---|
| 370 | <td class="right">Day Software</td> |
|---|
| 371 | </tr> |
|---|
| 372 | <tr> |
|---|
| 373 | <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) |
|---|
| 374 | </td> |
|---|
| 375 | <td class="right">J. Gettys</td> |
|---|
| 376 | </tr> |
|---|
| 377 | <tr> |
|---|
| 378 | <td class="left">Intended status: Standards Track</td> |
|---|
| 379 | <td class="right">One Laptop per Child</td> |
|---|
| 380 | </tr> |
|---|
| 381 | <tr> |
|---|
| 382 | <td class="left">Expires: August 27, 2008</td> |
|---|
| 383 | <td class="right">J. Mogul</td> |
|---|
| 384 | </tr> |
|---|
| 385 | <tr> |
|---|
| 386 | <td class="left"></td> |
|---|
| 387 | <td class="right">HP</td> |
|---|
| 388 | </tr> |
|---|
| 389 | <tr> |
|---|
| 390 | <td class="left"></td> |
|---|
| 391 | <td class="right">H. Frystyk</td> |
|---|
| 392 | </tr> |
|---|
| 393 | <tr> |
|---|
| 394 | <td class="left"></td> |
|---|
| 395 | <td class="right">Microsoft</td> |
|---|
| 396 | </tr> |
|---|
| 397 | <tr> |
|---|
| 398 | <td class="left"></td> |
|---|
| 399 | <td class="right">L. Masinter</td> |
|---|
| 400 | </tr> |
|---|
| 401 | <tr> |
|---|
| 402 | <td class="left"></td> |
|---|
| 403 | <td class="right">Adobe Systems</td> |
|---|
| 404 | </tr> |
|---|
| 405 | <tr> |
|---|
| 406 | <td class="left"></td> |
|---|
| 407 | <td class="right">P. Leach</td> |
|---|
| 408 | </tr> |
|---|
| 409 | <tr> |
|---|
| 410 | <td class="left"></td> |
|---|
| 411 | <td class="right">Microsoft</td> |
|---|
| 412 | </tr> |
|---|
| 413 | <tr> |
|---|
| 414 | <td class="left"></td> |
|---|
| 415 | <td class="right">T. Berners-Lee</td> |
|---|
| 416 | </tr> |
|---|
| 417 | <tr> |
|---|
| 418 | <td class="left"></td> |
|---|
| 419 | <td class="right">W3C/MIT</td> |
|---|
| 420 | </tr> |
|---|
| 421 | <tr> |
|---|
| 422 | <td class="left"></td> |
|---|
| 423 | <td class="right">Y. Lafon, Editor</td> |
|---|
| 424 | </tr> |
|---|
| 425 | <tr> |
|---|
| 426 | <td class="left"></td> |
|---|
| 427 | <td class="right">W3C</td> |
|---|
| 428 | </tr> |
|---|
| 429 | <tr> |
|---|
| 430 | <td class="left"></td> |
|---|
| 431 | <td class="right">J. Reschke, Editor</td> |
|---|
| 432 | </tr> |
|---|
| 433 | <tr> |
|---|
| 434 | <td class="left"></td> |
|---|
| 435 | <td class="right">greenbytes</td> |
|---|
| 436 | </tr> |
|---|
| 437 | <tr> |
|---|
| 438 | <td class="left"></td> |
|---|
| 439 | <td class="right">February 24, 2008</td> |
|---|
| 440 | </tr> |
|---|
| 441 | </tbody> |
|---|
| [231] | 442 | </table> |
|---|
| 443 | <p class="title">HTTP/1.1, part 2: Message Semantics<br><span class="filename">draft-ietf-httpbis-p2-semantics-02</span></p> |
|---|
| 444 | <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1> |
|---|
| 445 | <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she |
|---|
| 446 | is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section |
|---|
| 447 | 6 of BCP 79. |
|---|
| 448 | </p> |
|---|
| 449 | <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note |
|---|
| 450 | that other groups may also distribute working documents as Internet-Drafts. |
|---|
| 451 | </p> |
|---|
| 452 | <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other |
|---|
| 453 | documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work |
|---|
| 454 | in progress”. |
|---|
| 455 | </p> |
|---|
| [1099] | 456 | <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>. |
|---|
| [231] | 457 | </p> |
|---|
| [1099] | 458 | <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>. |
|---|
| [231] | 459 | </p> |
|---|
| [1099] | 460 | <p>This Internet-Draft will expire on August 27, 2008.</p> |
|---|
| [231] | 461 | <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> |
|---|
| 462 | <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information |
|---|
| 463 | systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the |
|---|
| 464 | seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part |
|---|
| 465 | 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and |
|---|
| 466 | response-header fields. |
|---|
| 467 | </p> |
|---|
| 468 | <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> |
|---|
| 469 | <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues |
|---|
| 470 | 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>>. |
|---|
| 471 | </p> |
|---|
| 472 | <p>This draft incorporates those issue resolutions that were either collected in the original RFC2616 errata list (<<a href="http://purl.org/NET/http-errata">http://purl.org/NET/http-errata</a>>), or which were agreed upon on the mailing list between October 2006 and November 2007 (as published in "draft-lafon-rfc2616bis-03"). |
|---|
| 473 | </p> |
|---|
| 474 | <hr class="noprint"> |
|---|
| 475 | <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> |
|---|
| 476 | <ul class="toc"> |
|---|
| [1099] | 477 | <li>1. <a href="#introduction">Introduction</a><ul> |
|---|
| 478 | <li>1.1 <a href="#intro.requirements">Requirements</a></li> |
|---|
| [231] | 479 | </ul> |
|---|
| 480 | </li> |
|---|
| [1099] | 481 | <li>2. <a href="#notation">Notational Conventions and Generic Grammar</a></li> |
|---|
| 482 | <li>3. <a href="#method">Method</a></li> |
|---|
| 483 | <li>4. <a href="#request.header.fields">Request Header Fields</a></li> |
|---|
| 484 | <li>5. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> |
|---|
| 485 | <li>6. <a href="#response.header.fields">Response Header Fields</a></li> |
|---|
| 486 | <li>7. <a href="#entity">Entity</a></li> |
|---|
| 487 | <li>8. <a href="#method.definitions">Method Definitions</a><ul> |
|---|
| 488 | <li>8.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul> |
|---|
| 489 | <li>8.1.1 <a href="#safe.methods">Safe Methods</a></li> |
|---|
| 490 | <li>8.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> |
|---|
| [231] | 491 | </ul> |
|---|
| 492 | </li> |
|---|
| [1099] | 493 | <li>8.2 <a href="#OPTIONS">OPTIONS</a></li> |
|---|
| 494 | <li>8.3 <a href="#GET">GET</a></li> |
|---|
| 495 | <li>8.4 <a href="#HEAD">HEAD</a></li> |
|---|
| 496 | <li>8.5 <a href="#POST">POST</a></li> |
|---|
| 497 | <li>8.6 <a href="#PUT">PUT</a></li> |
|---|
| 498 | <li>8.7 <a href="#DELETE">DELETE</a></li> |
|---|
| 499 | <li>8.8 <a href="#TRACE">TRACE</a></li> |
|---|
| 500 | <li>8.9 <a href="#CONNECT">CONNECT</a></li> |
|---|
| [231] | 501 | </ul> |
|---|
| 502 | </li> |
|---|
| [1099] | 503 | <li>9. <a href="#status.codes">Status Code Definitions</a><ul> |
|---|
| 504 | <li>9.1 <a href="#status.1xx">Informational 1xx</a><ul> |
|---|
| 505 | <li>9.1.1 <a href="#status.100">100 Continue</a></li> |
|---|
| 506 | <li>9.1.2 <a href="#status.101">101 Switching Protocols</a></li> |
|---|
| [231] | 507 | </ul> |
|---|
| 508 | </li> |
|---|
| [1099] | 509 | <li>9.2 <a href="#status.2xx">Successful 2xx</a><ul> |
|---|
| 510 | <li>9.2.1 <a href="#status.200">200 OK</a></li> |
|---|
| 511 | <li>9.2.2 <a href="#status.201">201 Created</a></li> |
|---|
| 512 | <li>9.2.3 <a href="#status.202">202 Accepted</a></li> |
|---|
| 513 | <li>9.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li> |
|---|
| 514 | <li>9.2.5 <a href="#status.204">204 No Content</a></li> |
|---|
| 515 | <li>9.2.6 <a href="#status.205">205 Reset Content</a></li> |
|---|
| 516 | <li>9.2.7 <a href="#status.206">206 Partial Content</a></li> |
|---|
| [231] | 517 | </ul> |
|---|
| 518 | </li> |
|---|
| [1099] | 519 | <li>9.3 <a href="#status.3xx">Redirection 3xx</a><ul> |
|---|
| 520 | <li>9.3.1 <a href="#status.300">300 Multiple Choices</a></li> |
|---|
| 521 | <li>9.3.2 <a href="#status.301">301 Moved Permanently</a></li> |
|---|
| 522 | <li>9.3.3 <a href="#status.302">302 Found</a></li> |
|---|
| 523 | <li>9.3.4 <a href="#status.303">303 See Other</a></li> |
|---|
| 524 | <li>9.3.5 <a href="#status.304">304 Not Modified</a></li> |
|---|
| 525 | <li>9.3.6 <a href="#status.305">305 Use Proxy</a></li> |
|---|
| 526 | <li>9.3.7 <a href="#status.306">306 (Unused)</a></li> |
|---|
| 527 | <li>9.3.8 <a href="#status.307">307 Temporary Redirect</a></li> |
|---|
| [231] | 528 | </ul> |
|---|
| 529 | </li> |
|---|
| [1099] | 530 | <li>9.4 <a href="#status.4xx">Client Error 4xx</a><ul> |
|---|
| 531 | <li>9.4.1 <a href="#status.400">400 Bad Request</a></li> |
|---|
| 532 | <li>9.4.2 <a href="#status.401">401 Unauthorized</a></li> |
|---|
| 533 | <li>9.4.3 <a href="#status.402">402 Payment Required</a></li> |
|---|
| 534 | <li>9.4.4 <a href="#status.403">403 Forbidden</a></li> |
|---|
| 535 | <li>9.4.5 <a href="#status.404">404 Not Found</a></li> |
|---|
| 536 | <li>9.4.6 <a href="#status.405">405 Method Not Allowed</a></li> |
|---|
| 537 | <li>9.4.7 <a href="#status.406">406 Not Acceptable</a></li> |
|---|
| 538 | <li>9.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li> |
|---|
| 539 | <li>9.4.9 <a href="#status.408">408 Request Timeout</a></li> |
|---|
| 540 | <li>9.4.10 <a href="#status.409">409 Conflict</a></li> |
|---|
| 541 | <li>9.4.11 <a href="#status.410">410 Gone</a></li> |
|---|
| 542 | <li>9.4.12 <a href="#status.411">411 Length Required</a></li> |
|---|
| 543 | <li>9.4.13 <a href="#status.412">412 Precondition Failed</a></li> |
|---|
| 544 | <li>9.4.14 <a href="#status.413">413 Request Entity Too Large</a></li> |
|---|
| 545 | <li>9.4.15 <a href="#status.414">414 Request-URI Too Long</a></li> |
|---|
| 546 | <li>9.4.16 <a href="#status.415">415 Unsupported Media Type</a></li> |
|---|
| 547 | <li>9.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li> |
|---|
| 548 | <li>9.4.18 <a href="#status.417">417 Expectation Failed</a></li> |
|---|
| [231] | 549 | </ul> |
|---|
| 550 | </li> |
|---|
| [1099] | 551 | <li>9.5 <a href="#status.5xx">Server Error 5xx</a><ul> |
|---|
| 552 | <li>9.5.1 <a href="#status.500">500 Internal Server Error</a></li> |
|---|
| 553 | <li>9.5.2 <a href="#status.501">501 Not Implemented</a></li> |
|---|
| 554 | <li>9.5.3 <a href="#status.502">502 Bad Gateway</a></li> |
|---|
| 555 | <li>9.5.4 <a href="#status.503">503 Service Unavailable</a></li> |
|---|
| 556 | <li>9.5.5 <a href="#status.504">504 Gateway Timeout</a></li> |
|---|
| 557 | <li>9.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li> |
|---|
| [231] | 558 | </ul> |
|---|
| 559 | </li> |
|---|
| 560 | </ul> |
|---|
| 561 | </li> |
|---|
| [1099] | 562 | <li>10. <a href="#header.fields">Header Field Definitions</a><ul> |
|---|
| 563 | <li>10.1 <a href="#header.allow">Allow</a></li> |
|---|
| 564 | <li>10.2 <a href="#header.expect">Expect</a></li> |
|---|
| 565 | <li>10.3 <a href="#header.from">From</a></li> |
|---|
| 566 | <li>10.4 <a href="#header.location">Location</a></li> |
|---|
| 567 | <li>10.5 <a href="#header.max-forwards">Max-Forwards</a></li> |
|---|
| 568 | <li>10.6 <a href="#header.referer">Referer</a></li> |
|---|
| 569 | <li>10.7 <a href="#header.retry-after">Retry-After</a></li> |
|---|
| 570 | <li>10.8 <a href="#header.server">Server</a></li> |
|---|
| 571 | <li>10.9 <a href="#header.user-agent">User-Agent</a></li> |
|---|
| [231] | 572 | </ul> |
|---|
| 573 | </li> |
|---|
| [1099] | 574 | <li>11. <a href="#IANA.considerations">IANA Considerations</a></li> |
|---|
| 575 | <li>12. <a href="#security.considerations">Security Considerations</a><ul> |
|---|
| 576 | <li>12.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> |
|---|
| 577 | <li>12.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> |
|---|
| 578 | <li>12.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li> |
|---|
| [231] | 579 | </ul> |
|---|
| 580 | </li> |
|---|
| [1099] | 581 | <li>13. <a href="#ack">Acknowledgments</a></li> |
|---|
| 582 | <li>14. <a href="#rfc.references">References</a><ul> |
|---|
| 583 | <li>14.1 <a href="#rfc.references.1">Normative References</a></li> |
|---|
| 584 | <li>14.2 <a href="#rfc.references.2">Informative References</a></li> |
|---|
| [231] | 585 | </ul> |
|---|
| 586 | </li> |
|---|
| [1099] | 587 | <li><a href="#rfc.authors">Authors' Addresses</a></li> |
|---|
| 588 | <li>A. <a href="#compatibility">Compatibility with Previous Versions</a><ul> |
|---|
| 589 | <li>A.1 <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li> |
|---|
| 590 | <li>A.2 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> |
|---|
| [231] | 591 | </ul> |
|---|
| 592 | </li> |
|---|
| [1099] | 593 | <li>B. <a href="#rfc.section.B">Change Log (to be removed by RFC Editor before publication)</a><ul> |
|---|
| 594 | <li>B.1 <a href="#rfc.section.B.1">Since RFC2616</a></li> |
|---|
| 595 | <li>B.2 <a href="#rfc.section.B.2">Since draft-ietf-httpbis-p2-semantics-00</a></li> |
|---|
| 596 | <li>B.3 <a href="#rfc.section.B.3">Since draft-ietf-httpbis-p2-semantics-01</a></li> |
|---|
| [231] | 597 | </ul> |
|---|
| 598 | </li> |
|---|
| [1099] | 599 | <li><a href="#rfc.index">Index</a></li> |
|---|
| 600 | <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> |
|---|
| [231] | 601 | </ul> |
|---|
| 602 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> |
|---|
| 603 | <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 |
|---|
| 604 | to each request, in the order received on that connection, with one or more HTTP response messages. This document defines |
|---|
| 605 | the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various |
|---|
| 606 | response messages that might be expected as a result of applying that method for the requested resource. |
|---|
| 607 | </p> |
|---|
| 608 | <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 |
|---|
| 609 | errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will |
|---|
| 610 | be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general |
|---|
| 611 | header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed |
|---|
| 612 | 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>. |
|---|
| 613 | </p> |
|---|
| 614 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> |
|---|
| 615 | <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" |
|---|
| 616 | 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>. |
|---|
| 617 | </p> |
|---|
| 618 | <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." |
|---|
| 619 | </p> |
|---|
| 620 | <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1> |
|---|
| [1099] | 621 | <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> |
|---|
| [231] | 622 | </p> |
|---|
| 623 | <div id="rfc.figure.u.1"></div><pre class="inline"> DIGIT = <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>> |
|---|
| 624 | </pre><div id="rfc.figure.u.2"></div><pre class="inline"> comment = <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>> |
|---|
| 625 | quoted-string = <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>> |
|---|
| 626 | token = <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>> |
|---|
| 627 | </pre><div id="abnf.dependencies"> |
|---|
| 628 | <p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> |
|---|
| 629 | </div> |
|---|
| 630 | <div id="rfc.figure.u.3"></div><pre class="inline"> absoluteURI = <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>> |
|---|
| 631 | fragment = <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>> |
|---|
| 632 | Host = <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>> |
|---|
| 633 | HTTP-date = <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>> |
|---|
| 634 | product = <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>> |
|---|
| 635 | relativeURI = <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>> |
|---|
| 636 | TE = <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>> |
|---|
| 637 | </pre><div id="rfc.figure.u.4"></div><pre class="inline"> Accept = <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>> |
|---|
| 638 | Accept-Charset = |
|---|
| 639 | <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>> |
|---|
| 640 | Accept-Encoding = |
|---|
| 641 | <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>> |
|---|
| 642 | Accept-Language = |
|---|
| 643 | <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>> |
|---|
| 644 | </pre><div id="rfc.figure.u.5"></div><pre class="inline"> ETag = <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>> |
|---|
| 645 | If-Match = <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>> |
|---|
| 646 | If-Modified-Since = |
|---|
| 647 | <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>> |
|---|
| 648 | If-None-Match = <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>> |
|---|
| 649 | If-Unmodified-Since = |
|---|
| 650 | <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>> |
|---|
| 651 | </pre><div id="rfc.figure.u.6"></div><pre class="inline"> Accept-Ranges = <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>> |
|---|
| 652 | If-Range = <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>> |
|---|
| 653 | Range = <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>> |
|---|
| 654 | </pre><div id="rfc.figure.u.7"></div><pre class="inline"> Age = <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>> |
|---|
| 655 | Vary = <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>> |
|---|
| 656 | </pre><div id="rfc.figure.u.8"></div><pre class="inline"> Authorization = <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>> |
|---|
| 657 | Proxy-Authenticate = |
|---|
| 658 | <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>> |
|---|
| 659 | Proxy-Authorization = |
|---|
| 660 | <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>> |
|---|
| 661 | WWW-Authenticate = |
|---|
| 662 | <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>> |
|---|
| 663 | </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1> |
|---|
| 664 | <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> |
|---|
| 665 | <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> |
|---|
| 666 | | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> |
|---|
| 667 | | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a> |
|---|
| 668 | | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 8.5</a> |
|---|
| 669 | | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 8.6</a> |
|---|
| 670 | | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 8.7</a> |
|---|
| 671 | | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 8.8</a> |
|---|
| 672 | | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 8.9</a> |
|---|
| 673 | | extension-method |
|---|
| 674 | extension-method = token |
|---|
| 675 | </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 |
|---|
| 676 | 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 |
|---|
| 677 | resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET |
|---|
| 678 | 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>. |
|---|
| 679 | </p> |
|---|
| 680 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> |
|---|
| 681 | <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, |
|---|
| 682 | to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language |
|---|
| 683 | method invocation. |
|---|
| 684 | </p> |
|---|
| 685 | <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.3"></span> request-header = Accept ; <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> |
|---|
| 686 | | Accept-Charset ; <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> |
|---|
| 687 | | Accept-Encoding ; <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> |
|---|
| 688 | | Accept-Language ; <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> |
|---|
| 689 | | Authorization ; <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> |
|---|
| 690 | | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a> |
|---|
| 691 | | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a> |
|---|
| 692 | | Host ; <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> |
|---|
| 693 | | If-Match ; <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> |
|---|
| 694 | | If-Modified-Since ; <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> |
|---|
| 695 | | If-None-Match ; <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> |
|---|
| 696 | | If-Range ; <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> |
|---|
| 697 | | If-Unmodified-Since ; <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> |
|---|
| 698 | | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.5</a> |
|---|
| 699 | | Proxy-Authorization ; <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> |
|---|
| 700 | | Range ; <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> |
|---|
| 701 | | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a> |
|---|
| 702 | | TE ; <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> |
|---|
| 703 | | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a> |
|---|
| 704 | </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 |
|---|
| 705 | 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. |
|---|
| 706 | Unrecognized header fields are treated as entity-header fields. |
|---|
| 707 | </p> |
|---|
| 708 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> |
|---|
| 709 | <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 |
|---|
| 710 | 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 |
|---|
| 711 | by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. |
|---|
| 712 | </p> |
|---|
| 713 | <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, |
|---|
| 714 | 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. |
|---|
| 715 | </p> |
|---|
| 716 | <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> Status-Code = |
|---|
| 717 | "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue |
|---|
| 718 | | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols |
|---|
| 719 | | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 9.2.1</a>: OK |
|---|
| 720 | | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 9.2.2</a>: Created |
|---|
| 721 | | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 9.2.3</a>: Accepted |
|---|
| 722 | | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 9.2.4</a>: Non-Authoritative Information |
|---|
| 723 | | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 9.2.5</a>: No Content |
|---|
| 724 | | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 9.2.6</a>: Reset Content |
|---|
| 725 | | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 9.2.7</a>: Partial Content |
|---|
| 726 | | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 9.3.1</a>: Multiple Choices |
|---|
| 727 | | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 9.3.2</a>: Moved Permanently |
|---|
| 728 | | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 9.3.3</a>: Found |
|---|
| 729 | | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 9.3.4</a>: See Other |
|---|
| 730 | | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 9.3.5</a>: Not Modified |
|---|
| 731 | | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 9.3.6</a>: Use Proxy |
|---|
| 732 | | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 9.3.8</a>: Temporary Redirect |
|---|
| 733 | | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 9.4.1</a>: Bad Request |
|---|
| 734 | | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 9.4.2</a>: Unauthorized |
|---|
| 735 | | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 9.4.3</a>: Payment Required |
|---|
| 736 | | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 9.4.4</a>: Forbidden |
|---|
| 737 | | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 9.4.5</a>: Not Found |
|---|
| 738 | | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 9.4.6</a>: Method Not Allowed |
|---|
| 739 | | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 9.4.7</a>: Not Acceptable |
|---|
| 740 | | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 9.4.8</a>: Proxy Authentication Required |
|---|
| 741 | | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 9.4.9</a>: Request Time-out |
|---|
| 742 | | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 9.4.10</a>: Conflict |
|---|
| 743 | | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 9.4.11</a>: Gone |
|---|
| 744 | | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 9.4.12</a>: Length Required |
|---|
| 745 | | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 9.4.13</a>: Precondition Failed |
|---|
| 746 | | "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 |
|---|
| 747 | | "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 |
|---|
| 748 | | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 9.4.16</a>: Unsupported Media Type |
|---|
| 749 | | "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 |
|---|
| 750 | | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 9.4.18</a>: Expectation Failed |
|---|
| 751 | | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 9.5.1</a>: Internal Server Error |
|---|
| 752 | | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 9.5.2</a>: Not Implemented |
|---|
| 753 | | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 9.5.3</a>: Bad Gateway |
|---|
| 754 | | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 9.5.4</a>: Service Unavailable |
|---|
| 755 | | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 9.5.5</a>: Gateway Time-out |
|---|
| 756 | | "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 |
|---|
| 757 | | extension-code |
|---|
| 758 | |
|---|
| 759 | extension-code = 3DIGIT |
|---|
| 760 | Reason-Phrase = *<TEXT, excluding CR, LF> |
|---|
| 761 | </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, |
|---|
| 762 | 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 |
|---|
| 763 | 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 |
|---|
| 764 | 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 |
|---|
| 765 | which will explain the unusual status. |
|---|
| 766 | </p> |
|---|
| 767 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> |
|---|
| 768 | <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 |
|---|
| 769 | Status-Line. These header fields give information about the server and about further access to the resource identified by |
|---|
| 770 | the Request-URI. |
|---|
| 771 | </p> |
|---|
| 772 | <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span> response-header = Accept-Ranges ; <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> |
|---|
| 773 | | Age ; <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> |
|---|
| 774 | | ETag ; <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> |
|---|
| 775 | | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a> |
|---|
| 776 | | Proxy-Authenticate ; <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> |
|---|
| 777 | | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a> |
|---|
| 778 | | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a> |
|---|
| 779 | | Vary ; <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> |
|---|
| 780 | | WWW-Authenticate ; <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> |
|---|
| 781 | </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 |
|---|
| 782 | 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 |
|---|
| 783 | fields. Unrecognized header fields are treated as entity-header fields. |
|---|
| 784 | </p> |
|---|
| 785 | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="entity" href="#entity">Entity</a></h1> |
|---|
| 786 | <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 |
|---|
| 787 | fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header |
|---|
| 788 | 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>. |
|---|
| 789 | </p> |
|---|
| 790 | <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 |
|---|
| 791 | safe and proper transfer of the message. |
|---|
| 792 | </p> |
|---|
| 793 | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> |
|---|
| 794 | <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 |
|---|
| 795 | to share the same semantics for separately extended clients and servers. |
|---|
| 796 | </p> |
|---|
| 797 | <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> |
|---|
| 798 | <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> |
|---|
| 799 | <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 |
|---|
| 800 | careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves |
|---|
| 801 | or others. |
|---|
| 802 | </p> |
|---|
| 803 | <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 "safe". This allows user |
|---|
| 804 | agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact |
|---|
| 805 | that a possibly unsafe action is being requested. |
|---|
| 806 | </p> |
|---|
| 807 | <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; |
|---|
| 808 | in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the |
|---|
| 809 | side-effects, so therefore cannot be held accountable for them. |
|---|
| 810 | </p> |
|---|
| 811 | <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> |
|---|
| 812 | <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 |
|---|
| 813 | > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, |
|---|
| 814 | the methods OPTIONS and TRACE <em class="bcp14">SHOULD NOT</em> have side effects, and so are inherently idempotent. |
|---|
| 815 | </p> |
|---|
| 816 | <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 |
|---|
| 817 | sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that |
|---|
| 818 | is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result |
|---|
| 819 | depends on a value that is later modified in the same sequence. |
|---|
| 820 | </p> |
|---|
| 821 | <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 |
|---|
| 822 | on the same set of resources). |
|---|
| 823 | </p> |
|---|
| 824 | <div id="rfc.iref.o.1"></div> |
|---|
| 825 | <div id="rfc.iref.m.1"></div> |
|---|
| 826 | <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> |
|---|
| 827 | <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 |
|---|
| 828 | chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated |
|---|
| 829 | with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. |
|---|
| 830 | </p> |
|---|
| 831 | <p id="rfc.section.8.2.p.2">Responses to this method are not cacheable.</p> |
|---|
| 832 | <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 |
|---|
| 833 | 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 |
|---|
| 834 | to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension <em class="bcp14">MAY</em> discard the request body. |
|---|
| 835 | </p> |
|---|
| 836 | <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 |
|---|
| 837 | a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful |
|---|
| 838 | as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. |
|---|
| 839 | For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). |
|---|
| 840 | </p> |
|---|
| 841 | <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 |
|---|
| 842 | with that resource. |
|---|
| 843 | </p> |
|---|
| 844 | <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., |
|---|
| 845 | 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, |
|---|
| 846 | 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". |
|---|
| 847 | </p> |
|---|
| 848 | <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 |
|---|
| 849 | 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 |
|---|
| 850 | request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. |
|---|
| 851 | </p> |
|---|
| 852 | <div id="rfc.iref.g.8"></div> |
|---|
| 853 | <div id="rfc.iref.m.2"></div> |
|---|
| 854 | <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="GET" href="#GET">GET</a></h2> |
|---|
| 855 | <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 |
|---|
| 856 | refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not |
|---|
| 857 | the source text of the process, unless that text happens to be the output of the process. |
|---|
| 858 | </p> |
|---|
| 859 | <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, |
|---|
| 860 | If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under |
|---|
| 861 | the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary |
|---|
| 862 | network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already |
|---|
| 863 | held by the client. |
|---|
| 864 | </p> |
|---|
| 865 | <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 |
|---|
| 866 | 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 |
|---|
| 867 | without transferring data already held by the client. |
|---|
| 868 | </p> |
|---|
| 869 | <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>. |
|---|
| 870 | </p> |
|---|
| 871 | <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. |
|---|
| 872 | </p> |
|---|
| 873 | <div id="rfc.iref.h.1"></div> |
|---|
| 874 | <div id="rfc.iref.m.3"></div> |
|---|
| 875 | <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> |
|---|
| 876 | <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 |
|---|
| 877 | the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext |
|---|
| 878 | links for validity, accessibility, and recent modification. |
|---|
| 879 | </p> |
|---|
| 880 | <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 |
|---|
| 881 | from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the |
|---|
| 882 | cache <em class="bcp14">MUST</em> treat the cache entry as stale. |
|---|
| 883 | </p> |
|---|
| 884 | <div id="rfc.iref.p.1"></div> |
|---|
| 885 | <div id="rfc.iref.m.4"></div> |
|---|
| 886 | <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="POST" href="#POST">POST</a></h2> |
|---|
| 887 | <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 |
|---|
| 888 | by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the |
|---|
| 889 | following functions: |
|---|
| 890 | </p> |
|---|
| 891 | <ul> |
|---|
| 892 | <li>Annotation of existing resources;</li> |
|---|
| 893 | <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> |
|---|
| 894 | <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> |
|---|
| 895 | <li>Extending a database through an append operation.</li> |
|---|
| 896 | </ul> |
|---|
| 897 | <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> |
|---|
| 898 | <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 |
|---|
| 899 | 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity |
|---|
| 900 | that describes the result. |
|---|
| 901 | </p> |
|---|
| 902 | <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 |
|---|
| 903 | header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.4</a>). |
|---|
| 904 | </p> |
|---|
| 905 | <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. |
|---|
| 906 | However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. |
|---|
| 907 | </p> |
|---|
| 908 | <div id="rfc.iref.p.2"></div> |
|---|
| 909 | <div id="rfc.iref.m.5"></div> |
|---|
| 910 | <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="PUT" href="#PUT">PUT</a></h2> |
|---|
| 911 | <p id="rfc.section.8.6.p.1">The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an |
|---|
| 912 | already 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 |
|---|
| 913 | resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create |
|---|
| 914 | 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 |
|---|
| 915 | 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, |
|---|
| 916 | 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. |
|---|
| 917 | </p> |
|---|
| 918 | <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. |
|---|
| 919 | </p> |
|---|
| 920 | <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 |
|---|
| 921 | URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting |
|---|
| 922 | process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request |
|---|
| 923 | 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, |
|---|
| 924 | 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. |
|---|
| 925 | </p> |
|---|
| 926 | <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 |
|---|
| 927 | is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in |
|---|
| 928 | several other URIs being defined by the origin server. |
|---|
| 929 | </p> |
|---|
| 930 | <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> |
|---|
| 931 | <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. |
|---|
| 932 | </p> |
|---|
| 933 | <div id="rfc.iref.d.1"></div> |
|---|
| 934 | <div id="rfc.iref.m.6"></div> |
|---|
| 935 | <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> |
|---|
| 936 | <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 |
|---|
| 937 | has been carried out, even if the status code returned from the origin server indicates that the action has been completed |
|---|
| 938 | 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 |
|---|
| 939 | location. |
|---|
| 940 | </p> |
|---|
| 941 | <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, |
|---|
| 942 | or 204 (No Content) if the action has been enacted but the response does not include an entity. |
|---|
| 943 | </p> |
|---|
| 944 | <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. |
|---|
| 945 | </p> |
|---|
| 946 | <div id="rfc.iref.t.1"></div> |
|---|
| 947 | <div id="rfc.iref.m.7"></div> |
|---|
| 948 | <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> |
|---|
| 949 | <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 |
|---|
| 950 | 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 |
|---|
| 951 | 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. |
|---|
| 952 | </p> |
|---|
| 953 | <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 |
|---|
| 954 | 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 |
|---|
| 955 | client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an |
|---|
| 956 | infinite loop. |
|---|
| 957 | </p> |
|---|
| 958 | <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". Responses to this method <em class="bcp14">MUST NOT</em> be cached. |
|---|
| 959 | </p> |
|---|
| 960 | <div id="rfc.iref.c.1"></div> |
|---|
| 961 | <div id="rfc.iref.m.8"></div> |
|---|
| 962 | <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> |
|---|
| 963 | <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. |
|---|
| 964 | SSL tunneling <a href="#Luo1998" id="rfc.xref.Luo1998.1"><cite title="Tunneling TCP based protocols through Web proxy servers">[Luo1998]</cite></a>). |
|---|
| 965 | </p> |
|---|
| 966 | <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> |
|---|
| 967 | <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 |
|---|
| 968 | in the response. |
|---|
| 969 | </p> |
|---|
| 970 | <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> |
|---|
| 971 | <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 |
|---|
| 972 | terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any |
|---|
| 973 | 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. |
|---|
| 974 | </p> |
|---|
| 975 | <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 |
|---|
| 976 | (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. |
|---|
| 977 | </p> |
|---|
| 978 | <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 |
|---|
| 979 | requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards |
|---|
| 980 | a request, then it need not forward the corresponding 100 (Continue) response(s).) |
|---|
| 981 | </p> |
|---|
| 982 | <div id="rfc.iref.23"></div> |
|---|
| 983 | <div id="rfc.iref.s.1"></div> |
|---|
| 984 | <h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> |
|---|
| 985 | <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 |
|---|
| 986 | 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 |
|---|
| 987 | 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.19"><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. |
|---|
| 988 | </p> |
|---|
| 989 | <div id="rfc.iref.24"></div> |
|---|
| 990 | <div id="rfc.iref.s.2"></div> |
|---|
| 991 | <h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> |
|---|
| 992 | <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 |
|---|
| 993 | by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
|---|
| 994 | </p> |
|---|
| 995 | <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 |
|---|
| 996 | older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use |
|---|
| 997 | such features. |
|---|
| 998 | </p> |
|---|
| 999 | <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> |
|---|
| 1000 | <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> |
|---|
| 1001 | <div id="rfc.iref.25"></div> |
|---|
| 1002 | <div id="rfc.iref.s.3"></div> |
|---|
| 1003 | <h3 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> |
|---|
| 1004 | <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 |
|---|
| 1005 | example: |
|---|
| 1006 | </p> |
|---|
| 1007 | <dl> |
|---|
| 1008 | <dt>GET</dt> |
|---|
| 1009 | <dd>an entity corresponding to the requested resource is sent in the response;</dd> |
|---|
| 1010 | <dt>HEAD</dt> |
|---|
| 1011 | <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd> |
|---|
| 1012 | <dt>POST</dt> |
|---|
| 1013 | <dd>an entity describing or containing the result of the action;</dd> |
|---|
| 1014 | <dt>TRACE</dt> |
|---|
| 1015 | <dd>an entity containing the request message as received by the end server.</dd> |
|---|
| 1016 | </dl> |
|---|
| 1017 | <div id="rfc.iref.26"></div> |
|---|
| 1018 | <div id="rfc.iref.s.4"></div> |
|---|
| 1019 | <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> |
|---|
| 1020 | <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 |
|---|
| 1021 | by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header |
|---|
| 1022 | 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 |
|---|
| 1023 | the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin |
|---|
| 1024 | 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. |
|---|
| 1025 | </p> |
|---|
| 1026 | <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, |
|---|
| 1027 | 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>. |
|---|
| 1028 | </p> |
|---|
| 1029 | <div id="rfc.iref.27"></div> |
|---|
| 1030 | <div id="rfc.iref.s.5"></div> |
|---|
| 1031 | <h3 id="rfc.section.9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> |
|---|
| 1032 | <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 |
|---|
| 1033 | be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status |
|---|
| 1034 | code from an asynchronous operation such as this. |
|---|
| 1035 | </p> |
|---|
| 1036 | <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 |
|---|
| 1037 | (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the |
|---|
| 1038 | 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 |
|---|
| 1039 | user can expect the request to be fulfilled. |
|---|
| 1040 | </p> |
|---|
| 1041 | <div id="rfc.iref.28"></div> |
|---|
| 1042 | <div id="rfc.iref.s.6"></div> |
|---|
| 1043 | <h3 id="rfc.section.9.2.4"><a href="#rfc.section.9.2.4">9.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> |
|---|
| 1044 | <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 |
|---|
| 1045 | 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 |
|---|
| 1046 | result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only |
|---|
| 1047 | appropriate when the response would otherwise be 200 (OK). |
|---|
| 1048 | </p> |
|---|
| 1049 | <div id="rfc.iref.29"></div> |
|---|
| 1050 | <div id="rfc.iref.s.7"></div> |
|---|
| 1051 | <h3 id="rfc.section.9.2.5"><a href="#rfc.section.9.2.5">9.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> |
|---|
| 1052 | <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. |
|---|
| 1053 | 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. |
|---|
| 1054 | </p> |
|---|
| 1055 | <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 |
|---|
| 1056 | 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. |
|---|
| 1057 | </p> |
|---|
| 1058 | <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. |
|---|
| 1059 | </p> |
|---|
| 1060 | <div id="rfc.iref.30"></div> |
|---|
| 1061 | <div id="rfc.iref.s.8"></div> |
|---|
| 1062 | <h3 id="rfc.section.9.2.6"><a href="#rfc.section.9.2.6">9.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> |
|---|
| 1063 | <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 |
|---|
| 1064 | 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 |
|---|
| 1065 | another input action. The response <em class="bcp14">MUST NOT</em> include an entity. |
|---|
| 1066 | </p> |
|---|
| 1067 | <div id="rfc.iref.31"></div> |
|---|
| 1068 | <div id="rfc.iref.s.9"></div> |
|---|
| 1069 | <h3 id="rfc.section.9.2.7"><a href="#rfc.section.9.2.7">9.2.7</a> <a id="status.206" href="#status.206">206 Partial Content</a></h3> |
|---|
| 1070 | <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 |
|---|
| 1071 | in <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. |
|---|
| 1072 | </p> |
|---|
| 1073 | <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> |
|---|
| 1074 | <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. |
|---|
| 1075 | 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 |
|---|
| 1076 | GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. |
|---|
| 1077 | </p> |
|---|
| [1099] | 1078 | <ul class="empty"> |
|---|
| 1079 | <li> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that |
|---|
| [231] | 1080 | there might be clients that implement such a fixed limitation. |
|---|
| [1099] | 1081 | </li> |
|---|
| 1082 | </ul> |
|---|
| [231] | 1083 | <div id="rfc.iref.32"></div> |
|---|
| 1084 | <div id="rfc.iref.s.10"></div> |
|---|
| 1085 | <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> |
|---|
| 1086 | <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 |
|---|
| 1087 | 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 |
|---|
| 1088 | location. |
|---|
| 1089 | </p> |
|---|
| 1090 | <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 |
|---|
| 1091 | the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending |
|---|
| 1092 | 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. |
|---|
| 1093 | </p> |
|---|
| 1094 | <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. |
|---|
| 1095 | </p> |
|---|
| 1096 | <div id="rfc.iref.33"></div> |
|---|
| 1097 | <div id="rfc.iref.s.11"></div> |
|---|
| 1098 | <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> |
|---|
| 1099 | <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 |
|---|
| 1100 | to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. |
|---|
| 1101 | </p> |
|---|
| 1102 | <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). |
|---|
| 1103 | </p> |
|---|
| 1104 | <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 |
|---|
| 1105 | the request was issued. |
|---|
| 1106 | </p> |
|---|
| [1099] | 1107 | <ul class="empty"> |
|---|
| 1108 | <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 |
|---|
| [231] | 1109 | change it into a GET request. |
|---|
| [1099] | 1110 | </li> |
|---|
| 1111 | </ul> |
|---|
| [231] | 1112 | <div id="rfc.iref.34"></div> |
|---|
| 1113 | <div id="rfc.iref.s.12"></div> |
|---|
| 1114 | <h3 id="rfc.section.9.3.3"><a href="#rfc.section.9.3.3">9.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> |
|---|
| 1115 | <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 |
|---|
| 1116 | 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 |
|---|
| 1117 | header field. |
|---|
| 1118 | </p> |
|---|
| 1119 | <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). |
|---|
| 1120 | </p> |
|---|
| 1121 | <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 |
|---|
| 1122 | the request was issued. |
|---|
| 1123 | </p> |
|---|
| [1099] | 1124 | <ul class="empty"> |
|---|
| 1125 | <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 |
|---|
| [231] | 1126 | treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. |
|---|
| 1127 | The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected |
|---|
| 1128 | of the client. |
|---|
| [1099] | 1129 | </li> |
|---|
| 1130 | </ul> |
|---|
| [231] | 1131 | <div id="rfc.iref.35"></div> |
|---|
| 1132 | <div id="rfc.iref.s.13"></div> |
|---|
| 1133 | <h3 id="rfc.section.9.3.4"><a href="#rfc.section.9.3.4">9.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> |
|---|
| 1134 | <p id="rfc.section.9.3.4.p.1">The response to the request can be found under a different URI and <em class="bcp14">SHOULD</em> be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script |
|---|
| 1135 | to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested |
|---|
| 1136 | resource. The 303 response <em class="bcp14">MUST NOT</em> be cached, but the response to the second (redirected) request might be cacheable. |
|---|
| 1137 | </p> |
|---|
| 1138 | <p id="rfc.section.9.3.4.p.2">The different 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). |
|---|
| 1139 | </p> |
|---|
| [1099] | 1140 | <ul class="empty"> |
|---|
| 1141 | <li> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the |
|---|
| [231] | 1142 | 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. |
|---|
| [1099] | 1143 | </li> |
|---|
| 1144 | </ul> |
|---|
| [231] | 1145 | <div id="rfc.iref.36"></div> |
|---|
| 1146 | <div id="rfc.iref.s.14"></div> |
|---|
| 1147 | <h3 id="rfc.section.9.3.5"><a href="#rfc.section.9.3.5">9.3.5</a> <a id="status.304" href="#status.304">304 Not Modified</a></h3> |
|---|
| 1148 | <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, |
|---|
| 1149 | as defined in <a href="#Part4" id="rfc.xref.Part4.12"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. |
|---|
| 1150 | </p> |
|---|
| 1151 | <div id="rfc.iref.37"></div> |
|---|
| 1152 | <div id="rfc.iref.s.15"></div> |
|---|
| 1153 | <h3 id="rfc.section.9.3.6"><a href="#rfc.section.9.3.6">9.3.6</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> |
|---|
| 1154 | <p id="rfc.section.9.3.6.p.1">The requested resource <em class="bcp14">MUST</em> be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is |
|---|
| 1155 | expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers. |
|---|
| 1156 | </p> |
|---|
| [1099] | 1157 | <ul class="empty"> |
|---|
| 1158 | <li> <b>Note:</b> <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing |
|---|
| [231] | 1159 | these limitations has significant security consequences. |
|---|
| [1099] | 1160 | </li> |
|---|
| 1161 | </ul> |
|---|
| [231] | 1162 | <div id="rfc.iref.38"></div> |
|---|
| 1163 | <div id="rfc.iref.s.16"></div> |
|---|
| 1164 | <h3 id="rfc.section.9.3.7"><a href="#rfc.section.9.3.7">9.3.7</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> |
|---|
| 1165 | <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> |
|---|
| 1166 | <div id="rfc.iref.39"></div> |
|---|
| 1167 | <div id="rfc.iref.s.17"></div> |
|---|
| 1168 | <h3 id="rfc.section.9.3.8"><a href="#rfc.section.9.3.8">9.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> |
|---|
| 1169 | <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 |
|---|
| 1170 | header field. |
|---|
| 1171 | </p> |
|---|
| 1172 | <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 |
|---|
| 1173 | 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. |
|---|
| 1174 | </p> |
|---|
| 1175 | <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 |
|---|
| 1176 | the request was issued. |
|---|
| 1177 | </p> |
|---|
| 1178 | <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> |
|---|
| 1179 | <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 |
|---|
| 1180 | 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. |
|---|
| 1181 | These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user. |
|---|
| 1182 | </p> |
|---|
| 1183 | <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 |
|---|
| 1184 | the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send |
|---|
| 1185 | a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted |
|---|
| 1186 | by the HTTP application. |
|---|
| 1187 | </p> |
|---|
| 1188 | <div id="rfc.iref.40"></div> |
|---|
| 1189 | <div id="rfc.iref.s.18"></div> |
|---|
| 1190 | <h3 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> |
|---|
| 1191 | <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. |
|---|
| 1192 | </p> |
|---|
| 1193 | <div id="rfc.iref.41"></div> |
|---|
| 1194 | <div id="rfc.iref.s.19"></div> |
|---|
| 1195 | <h3 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h3> |
|---|
| 1196 | <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>). |
|---|
| 1197 | </p> |
|---|
| 1198 | <div id="rfc.iref.42"></div> |
|---|
| 1199 | <div id="rfc.iref.s.20"></div> |
|---|
| 1200 | <h3 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> |
|---|
| 1201 | <p id="rfc.section.9.4.3.p.1">This code is reserved for future use.</p> |
|---|
| 1202 | <div id="rfc.iref.43"></div> |
|---|
| 1203 | <div id="rfc.iref.s.21"></div> |
|---|
| 1204 | <h3 id="rfc.section.9.4.4"><a href="#rfc.section.9.4.4">9.4.4</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> |
|---|
| 1205 | <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, |
|---|
| 1206 | 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, |
|---|
| 1207 | the status code 404 (Not Found) can be used instead. |
|---|
| 1208 | </p> |
|---|
| 1209 | <div id="rfc.iref.44"></div> |
|---|
| 1210 | <div id="rfc.iref.s.22"></div> |
|---|
| 1211 | <h3 id="rfc.section.9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> |
|---|
| 1212 | <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 |
|---|
| 1213 | 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 |
|---|
| 1214 | and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request |
|---|
| 1215 | has been refused, or when no other response is applicable. |
|---|
| 1216 | </p> |
|---|
| 1217 | <div id="rfc.iref.45"></div> |
|---|
| 1218 | <div id="rfc.iref.s.23"></div> |
|---|
| 1219 | <h3 id="rfc.section.9.4.6"><a href="#rfc.section.9.4.6">9.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> |
|---|
| 1220 | <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. |
|---|
| 1221 | </p> |
|---|
| 1222 | <div id="rfc.iref.46"></div> |
|---|
| 1223 | <div id="rfc.iref.s.24"></div> |
|---|
| 1224 | <h3 id="rfc.section.9.4.7"><a href="#rfc.section.9.4.7">9.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> |
|---|
| 1225 | <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 |
|---|
| 1226 | not acceptable according to the accept headers sent in the request. |
|---|
| 1227 | </p> |
|---|
| 1228 | <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 |
|---|
| 1229 | can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. |
|---|
| 1230 | 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. |
|---|
| 1231 | </p> |
|---|
| [1099] | 1232 | <ul class="empty"> |
|---|
| 1233 | <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. |
|---|
| [231] | 1234 | In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of |
|---|
| 1235 | an incoming response to determine if it is acceptable. |
|---|
| [1099] | 1236 | </li> |
|---|
| 1237 | </ul> |
|---|
| [231] | 1238 | <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. |
|---|
| 1239 | </p> |
|---|
| 1240 | <div id="rfc.iref.47"></div> |
|---|
| 1241 | <div id="rfc.iref.s.25"></div> |
|---|
| 1242 | <h3 id="rfc.section.9.4.8"><a href="#rfc.section.9.4.8">9.4.8</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h3> |
|---|
| 1243 | <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>). |
|---|
| 1244 | </p> |
|---|
| 1245 | <div id="rfc.iref.48"></div> |
|---|
| 1246 | <div id="rfc.iref.s.26"></div> |
|---|
| 1247 | <h3 id="rfc.section.9.4.9"><a href="#rfc.section.9.4.9">9.4.9</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> |
|---|
| 1248 | <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. |
|---|
| 1249 | </p> |
|---|
| 1250 | <div id="rfc.iref.49"></div> |
|---|
| 1251 | <div id="rfc.iref.s.27"></div> |
|---|
| 1252 | <h3 id="rfc.section.9.4.10"><a href="#rfc.section.9.4.10">9.4.10</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> |
|---|
| 1253 | <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 |
|---|
| 1254 | situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response |
|---|
| 1255 | 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 |
|---|
| 1256 | enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. |
|---|
| 1257 | </p> |
|---|
| 1258 | <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 |
|---|
| 1259 | being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might |
|---|
| 1260 | use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain |
|---|
| 1261 | a list of the differences between the two versions in a format defined by the response Content-Type. |
|---|
| 1262 | </p> |
|---|
| 1263 | <div id="rfc.iref.50"></div> |
|---|
| 1264 | <div id="rfc.iref.s.28"></div> |
|---|
| 1265 | <h3 id="rfc.section.9.4.11"><a href="#rfc.section.9.4.11">9.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3> |
|---|
| 1266 | <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 |
|---|
| 1267 | 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 |
|---|
| 1268 | 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. |
|---|
| 1269 | </p> |
|---|
| 1270 | <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 |
|---|
| 1271 | is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event |
|---|
| 1272 | is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's |
|---|
| 1273 | site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time |
|---|
| 1274 | -- that is left to the discretion of the server owner. |
|---|
| 1275 | </p> |
|---|
| 1276 | <div id="rfc.iref.51"></div> |
|---|
| 1277 | <div id="rfc.iref.s.29"></div> |
|---|
| 1278 | <h3 id="rfc.section.9.4.12"><a href="#rfc.section.9.4.12">9.4.12</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> |
|---|
| 1279 | <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 |
|---|
| 1280 | message. |
|---|
| 1281 | </p> |
|---|
| 1282 | <div id="rfc.iref.52"></div> |
|---|
| 1283 | <div id="rfc.iref.s.30"></div> |
|---|
| 1284 | <h3 id="rfc.section.9.4.13"><a href="#rfc.section.9.4.13">9.4.13</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h3> |
|---|
| 1285 | <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 |
|---|
| 1286 | defined in <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. |
|---|
| 1287 | </p> |
|---|
| 1288 | <div id="rfc.iref.53"></div> |
|---|
| 1289 | <div id="rfc.iref.s.31"></div> |
|---|
| 1290 | <h3 id="rfc.section.9.4.14"><a href="#rfc.section.9.4.14">9.4.14</a> <a id="status.413" href="#status.413">413 Request Entity Too Large</a></h3> |
|---|
| 1291 | <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. |
|---|
| 1292 | The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. |
|---|
| 1293 | </p> |
|---|
| 1294 | <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. |
|---|
| 1295 | </p> |
|---|
| 1296 | <div id="rfc.iref.54"></div> |
|---|
| 1297 | <div id="rfc.iref.s.32"></div> |
|---|
| 1298 | <h3 id="rfc.section.9.4.15"><a href="#rfc.section.9.4.15">9.4.15</a> <a id="status.414" href="#status.414">414 Request-URI Too Long</a></h3> |
|---|
| 1299 | <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 |
|---|
| 1300 | rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query |
|---|
| 1301 | information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points |
|---|
| 1302 | to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some |
|---|
| 1303 | servers using fixed-length buffers for reading or manipulating the Request-URI. |
|---|
| 1304 | </p> |
|---|
| 1305 | <div id="rfc.iref.55"></div> |
|---|
| 1306 | <div id="rfc.iref.s.33"></div> |
|---|
| 1307 | <h3 id="rfc.section.9.4.16"><a href="#rfc.section.9.4.16">9.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> |
|---|
| 1308 | <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 |
|---|
| 1309 | resource for the requested method. |
|---|
| 1310 | </p> |
|---|
| 1311 | <div id="rfc.iref.56"></div> |
|---|
| 1312 | <div id="rfc.iref.s.34"></div> |
|---|
| 1313 | <h3 id="rfc.section.9.4.17"><a href="#rfc.section.9.4.17">9.4.17</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3> |
|---|
| 1314 | <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. |
|---|
| 1315 | </p> |
|---|
| 1316 | <div id="rfc.iref.57"></div> |
|---|
| 1317 | <div id="rfc.iref.s.35"></div> |
|---|
| 1318 | <h3 id="rfc.section.9.4.18"><a href="#rfc.section.9.4.18">9.4.18</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> |
|---|
| 1319 | <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 |
|---|
| 1320 | not be met by the next-hop server. |
|---|
| 1321 | </p> |
|---|
| 1322 | <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> |
|---|
| 1323 | <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 |
|---|
| 1324 | 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. |
|---|
| 1325 | User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method. |
|---|
| 1326 | </p> |
|---|
| 1327 | <div id="rfc.iref.58"></div> |
|---|
| 1328 | <div id="rfc.iref.s.36"></div> |
|---|
| 1329 | <h3 id="rfc.section.9.5.1"><a href="#rfc.section.9.5.1">9.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> |
|---|
| 1330 | <p id="rfc.section.9.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> |
|---|
| 1331 | <div id="rfc.iref.59"></div> |
|---|
| 1332 | <div id="rfc.iref.s.37"></div> |
|---|
| 1333 | <h3 id="rfc.section.9.5.2"><a href="#rfc.section.9.5.2">9.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3> |
|---|
| 1334 | <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 |
|---|
| 1335 | does not recognize the request method and is not capable of supporting it for any resource. |
|---|
| 1336 | </p> |
|---|
| 1337 | <div id="rfc.iref.60"></div> |
|---|
| 1338 | <div id="rfc.iref.s.38"></div> |
|---|
| 1339 | <h3 id="rfc.section.9.5.3"><a href="#rfc.section.9.5.3">9.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3> |
|---|
| 1340 | <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 |
|---|
| 1341 | to fulfill the request. |
|---|
| 1342 | </p> |
|---|
| 1343 | <div id="rfc.iref.61"></div> |
|---|
| 1344 | <div id="rfc.iref.s.39"></div> |
|---|
| 1345 | <h3 id="rfc.section.9.5.4"><a href="#rfc.section.9.5.4">9.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> |
|---|
| 1346 | <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 |
|---|
| 1347 | 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. |
|---|
| 1348 | </p> |
|---|
| [1099] | 1349 | <ul class="empty"> |
|---|
| 1350 | <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 |
|---|
| [231] | 1351 | to simply refuse the connection. |
|---|
| [1099] | 1352 | </li> |
|---|
| 1353 | </ul> |
|---|
| [231] | 1354 | <div id="rfc.iref.62"></div> |
|---|
| 1355 | <div id="rfc.iref.s.40"></div> |
|---|
| 1356 | <h3 id="rfc.section.9.5.5"><a href="#rfc.section.9.5.5">9.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> |
|---|
| 1357 | <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 |
|---|
| 1358 | URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. |
|---|
| 1359 | </p> |
|---|
| [1099] | 1360 | <ul class="empty"> |
|---|
| 1361 | <li> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. |
|---|
| 1362 | </li> |
|---|
| 1363 | </ul> |
|---|
| [231] | 1364 | <div id="rfc.iref.63"></div> |
|---|
| 1365 | <div id="rfc.iref.s.41"></div> |
|---|
| 1366 | <h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> |
|---|
| 1367 | <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 |
|---|
| 1368 | is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described |
|---|
| 1369 | in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</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>, 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. |
|---|
| 1370 | </p> |
|---|
| 1371 | <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> |
|---|
| 1372 | <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> |
|---|
| 1373 | <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 |
|---|
| 1374 | receives the entity. |
|---|
| 1375 | </p> |
|---|
| 1376 | <div id="rfc.iref.a.1"></div> |
|---|
| 1377 | <div id="rfc.iref.h.2"></div> |
|---|
| 1378 | <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> |
|---|
| 1379 | <p id="rfc.section.10.1.p.1">The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose |
|---|
| 1380 | of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. |
|---|
| 1381 | </p> |
|---|
| 1382 | <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Allow = "Allow" ":" #Method |
|---|
| 1383 | </pre><p id="rfc.section.10.1.p.3">Example of use:</p> |
|---|
| 1384 | <div id="rfc.figure.u.14"></div><pre class="text"> Allow: GET, HEAD, PUT |
|---|
| 1385 | </pre><p id="rfc.section.10.1.p.5">This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value <em class="bcp14">SHOULD</em> be followed. The actual set of allowed methods is defined by the origin server at the time of each request. |
|---|
| 1386 | </p> |
|---|
| 1387 | <p id="rfc.section.10.1.p.6">The Allow header field <em class="bcp14">MAY</em> be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not |
|---|
| 1388 | required to support these methods and <em class="bcp14">SHOULD</em> include an Allow header in the response giving the actual supported methods. |
|---|
| 1389 | </p> |
|---|
| 1390 | <p id="rfc.section.10.1.p.7">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 |
|---|
| 1391 | means of communicating with the origin server. |
|---|
| 1392 | </p> |
|---|
| 1393 | <div id="rfc.iref.e.1"></div> |
|---|
| 1394 | <div id="rfc.iref.h.3"></div> |
|---|
| 1395 | <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> |
|---|
| 1396 | <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> |
|---|
| 1397 | <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> Expect = "Expect" ":" 1#expectation |
|---|
| 1398 | |
|---|
| 1399 | expectation = "100-continue" | expectation-extension |
|---|
| 1400 | expectation-extension = token [ "=" ( token | quoted-string ) |
|---|
| 1401 | *expect-params ] |
|---|
| 1402 | expect-params = ";" token [ "=" ( token | quoted-string ) ] |
|---|
| 1403 | </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 |
|---|
| 1404 | the request, some other 4xx status. |
|---|
| 1405 | </p> |
|---|
| 1406 | <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 |
|---|
| 1407 | 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. |
|---|
| 1408 | </p> |
|---|
| 1409 | <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 |
|---|
| 1410 | for quoted-string expectation-extensions. |
|---|
| 1411 | </p> |
|---|
| 1412 | <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 |
|---|
| 1413 | request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. |
|---|
| 1414 | </p> |
|---|
| 1415 | <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> |
|---|
| 1416 | <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status. |
|---|
| 1417 | </p> |
|---|
| 1418 | <div id="rfc.iref.f.1"></div> |
|---|
| 1419 | <div id="rfc.iref.h.4"></div> |
|---|
| 1420 | <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.from" href="#header.from">From</a></h2> |
|---|
| 1421 | <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="http://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>: |
|---|
| 1422 | </p> |
|---|
| 1423 | <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.14"></span> From = "From" ":" mailbox |
|---|
| 1424 | |
|---|
| 1425 | mailbox = <mailbox, defined in <a href="#RFC2822" id="rfc.xref.RFC2822.2"><cite title="Internet Message Format">[RFC2822]</cite></a>, <a href="http://tools.ietf.org/html/rfc2822#section-3.4">Section 3.4</a>> |
|---|
| 1426 | </pre><p id="rfc.section.10.3.p.3">An example is:</p> |
|---|
| 1427 | <div id="rfc.figure.u.17"></div><pre class="text"> From: webmaster@example.org |
|---|
| 1428 | </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 |
|---|
| 1429 | 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 |
|---|
| 1430 | end. |
|---|
| 1431 | </p> |
|---|
| 1432 | <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 |
|---|
| 1433 | issuer's address <em class="bcp14">SHOULD</em> be used. |
|---|
| 1434 | </p> |
|---|
| 1435 | <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 |
|---|
| 1436 | security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at |
|---|
| 1437 | any time prior to a request. |
|---|
| 1438 | </p> |
|---|
| 1439 | <div id="rfc.iref.l.1"></div> |
|---|
| 1440 | <div id="rfc.iref.h.5"></div> |
|---|
| 1441 | <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="header.location" href="#header.location">Location</a></h2> |
|---|
| 1442 | <p id="rfc.section.10.4.p.1">The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion |
|---|
| 1443 | of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource |
|---|
| 1444 | 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 |
|---|
| 1445 | URI. |
|---|
| 1446 | </p> |
|---|
| 1447 | <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.15"></span> Location = "Location" ":" absoluteURI [ "#" fragment ] |
|---|
| 1448 | </pre><p id="rfc.section.10.4.p.3">An example is:</p> |
|---|
| 1449 | <div id="rfc.figure.u.19"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html |
|---|
| 1450 | </pre><p id="rfc.section.10.4.p.5"> </p> |
|---|
| [1099] | 1451 | <ul class="empty"> |
|---|
| 1452 | <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 request. |
|---|
| [231] | 1453 | It is therefore possible for a response to contain header fields for both Location and Content-Location. |
|---|
| [1099] | 1454 | </li> |
|---|
| 1455 | </ul> |
|---|
| [231] | 1456 | <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> |
|---|
| 1457 | <ul> |
|---|
| 1458 | <li>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</li> |
|---|
| 1459 | <li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment |
|---|
| 1460 | characteristics. |
|---|
| 1461 | </li> |
|---|
| 1462 | <li>With 305 Use Proxy.</li> |
|---|
| 1463 | </ul> |
|---|
| 1464 | <div id="rfc.iref.m.9"></div> |
|---|
| 1465 | <div id="rfc.iref.h.6"></div> |
|---|
| 1466 | <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> |
|---|
| 1467 | <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 |
|---|
| 1468 | useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. |
|---|
| 1469 | </p> |
|---|
| 1470 | <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
|---|
| 1471 | </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> |
|---|
| 1472 | <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). |
|---|
| 1473 | </p> |
|---|
| 1474 | <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 |
|---|
| 1475 | referred to as part of that method definition. |
|---|
| 1476 | </p> |
|---|
| 1477 | <div id="rfc.iref.r.1"></div> |
|---|
| 1478 | <div id="rfc.iref.h.7"></div> |
|---|
| 1479 | <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> |
|---|
| 1480 | <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 |
|---|
| 1481 | from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header |
|---|
| 1482 | allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows |
|---|
| 1483 | 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. |
|---|
| 1484 | </p> |
|---|
| 1485 | <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
|---|
| 1486 | </pre><p id="rfc.section.10.6.p.3">Example:</p> |
|---|
| 1487 | <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html |
|---|
| 1488 | </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. |
|---|
| 1489 | </p> |
|---|
| 1490 | <div id="rfc.iref.r.2"></div> |
|---|
| 1491 | <div id="rfc.iref.h.8"></div> |
|---|
| 1492 | <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> |
|---|
| 1493 | <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 |
|---|
| 1494 | 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 |
|---|
| 1495 | the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after |
|---|
| 1496 | the time of the response. |
|---|
| 1497 | </p> |
|---|
| 1498 | <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
|---|
| 1499 | </pre><p id="rfc.section.10.7.p.3">Time spans are non-negative decimal integers, representing time in seconds.</p> |
|---|
| 1500 | <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.19"></span> delta-seconds = 1*DIGIT |
|---|
| 1501 | </pre><p id="rfc.section.10.7.p.5">Two examples of its use are</p> |
|---|
| 1502 | <div id="rfc.figure.u.25"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
|---|
| 1503 | Retry-After: 120 |
|---|
| 1504 | </pre><p id="rfc.section.10.7.p.7">In the latter example, the delay is 2 minutes.</p> |
|---|
| 1505 | <div id="rfc.iref.s.42"></div> |
|---|
| 1506 | <div id="rfc.iref.h.9"></div> |
|---|
| 1507 | <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.server" href="#header.server">Server</a></h2> |
|---|
| 1508 | <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. |
|---|
| 1509 | 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.22"><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 |
|---|
| 1510 | for identifying the application. |
|---|
| 1511 | </p> |
|---|
| 1512 | <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.20"></span> Server = "Server" ":" 1*( product | comment ) |
|---|
| 1513 | </pre><p id="rfc.section.10.8.p.3">Example:</p> |
|---|
| 1514 | <div id="rfc.figure.u.27"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 |
|---|
| 1515 | </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.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). |
|---|
| 1516 | </p> |
|---|
| [1099] | 1517 | <ul class="empty"> |
|---|
| 1518 | <li> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks |
|---|
| [231] | 1519 | against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable |
|---|
| 1520 | option. |
|---|
| [1099] | 1521 | </li> |
|---|
| 1522 | </ul> |
|---|
| [231] | 1523 | <div id="rfc.iref.u.1"></div> |
|---|
| 1524 | <div id="rfc.iref.h.10"></div> |
|---|
| 1525 | <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> |
|---|
| 1526 | <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 |
|---|
| 1527 | purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses |
|---|
| 1528 | 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.24"><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 |
|---|
| 1529 | product tokens are listed in order of their significance for identifying the application. |
|---|
| 1530 | </p> |
|---|
| 1531 | <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.21"></span> User-Agent = "User-Agent" ":" 1*( product | comment ) |
|---|
| 1532 | </pre><p id="rfc.section.10.9.p.3">Example:</p> |
|---|
| 1533 | <div id="rfc.figure.u.29"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
|---|
| 1534 | </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> |
|---|
| [1099] | 1535 | <p id="rfc.section.11.p.1"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD.]</span> |
|---|
| [231] | 1536 | </p> |
|---|
| 1537 | <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> |
|---|
| 1538 | <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 |
|---|
| 1539 | as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does |
|---|
| 1540 | make some suggestions for reducing security risks. |
|---|
| 1541 | </p> |
|---|
| 1542 | <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> |
|---|
| 1543 | <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 |
|---|
| 1544 | a priori method of determining the sensitivity of any particular piece of information within the context of any given request. |
|---|
| 1545 | 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 |
|---|
| 1546 | special mention in this context: Server, Via, Referer and From. |
|---|
| 1547 | </p> |
|---|
| 1548 | <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 |
|---|
| 1549 | against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. |
|---|
| 1550 | </p> |
|---|
| 1551 | <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, |
|---|
| 1552 | they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. |
|---|
| 1553 | </p> |
|---|
| 1554 | <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 |
|---|
| 1555 | can be abused if user details are not separated from the information contained in the Referer. Even when the personal information |
|---|
| 1556 | has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. |
|---|
| 1557 | </p> |
|---|
| 1558 | <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 |
|---|
| 1559 | 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. |
|---|
| 1560 | </p> |
|---|
| 1561 | <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 |
|---|
| 1562 | of From and Referer information. |
|---|
| 1563 | </p> |
|---|
| 1564 | <p id="rfc.section.12.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.2" 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 |
|---|
| 1565 | might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently |
|---|
| 1566 | has no better mechanism. |
|---|
| 1567 | </p> |
|---|
| 1568 | <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> |
|---|
| 1569 | <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 |
|---|
| 1570 | recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could |
|---|
| 1571 | have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From |
|---|
| 1572 | information. |
|---|
| 1573 | </p> |
|---|
| 1574 | <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. |
|---|
| 1575 | </p> |
|---|
| 1576 | <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 |
|---|
| 1577 | in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might |
|---|
| 1578 | be visible to third parties. Such services can use POST-based form submission instead. |
|---|
| 1579 | </p> |
|---|
| 1580 | <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> |
|---|
| 1581 | <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 |
|---|
| 1582 | to make sure that they do not attempt to invalidate resources over which they have no authority. |
|---|
| 1583 | </p> |
|---|
| 1584 | <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> |
|---|
| 1585 | <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References |
|---|
| 1586 | </h1> |
|---|
| 1587 | <h2 id="rfc.references.1"><a href="#rfc.section.14.1" id="rfc.section.14.1">14.1</a> Normative References |
|---|
| 1588 | </h2> |
|---|
| [1099] | 1589 | <table> |
|---|
| [231] | 1590 | <tr> |
|---|
| 1591 | <td class="reference"><b id="Part1">[Part1]</b></td> |
|---|
| [1099] | 1592 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-02">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-02 (work in progress), February 2008. |
|---|
| [231] | 1593 | </td> |
|---|
| 1594 | </tr> |
|---|
| 1595 | <tr> |
|---|
| 1596 | <td class="reference"><b id="Part3">[Part3]</b></td> |
|---|
| [1099] | 1597 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-02">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-02 (work in progress), February 2008. |
|---|
| [231] | 1598 | </td> |
|---|
| 1599 | </tr> |
|---|
| 1600 | <tr> |
|---|
| 1601 | <td class="reference"><b id="Part4">[Part4]</b></td> |
|---|
| [1099] | 1602 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-02">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-02 (work in progress), February 2008. |
|---|
| [231] | 1603 | </td> |
|---|
| 1604 | </tr> |
|---|
| 1605 | <tr> |
|---|
| 1606 | <td class="reference"><b id="Part5">[Part5]</b></td> |
|---|
| [1099] | 1607 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-02">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-02 (work in progress), February 2008. |
|---|
| [231] | 1608 | </td> |
|---|
| 1609 | </tr> |
|---|
| 1610 | <tr> |
|---|
| 1611 | <td class="reference"><b id="Part6">[Part6]</b></td> |
|---|
| [1099] | 1612 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-02">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-02 (work in progress), February 2008. |
|---|
| [231] | 1613 | </td> |
|---|
| 1614 | </tr> |
|---|
| 1615 | <tr> |
|---|
| 1616 | <td class="reference"><b id="Part7">[Part7]</b></td> |
|---|
| [1099] | 1617 | <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="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-02">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-02 (work in progress), February 2008. |
|---|
| [231] | 1618 | </td> |
|---|
| 1619 | </tr> |
|---|
| 1620 | <tr> |
|---|
| 1621 | <td class="reference"><b id="RFC2119">[RFC2119]</b></td> |
|---|
| [1099] | 1622 | <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. |
|---|
| [231] | 1623 | </td> |
|---|
| 1624 | </tr> |
|---|
| 1625 | </table> |
|---|
| 1626 | <h2 id="rfc.references.2"><a href="#rfc.section.14.2" id="rfc.section.14.2">14.2</a> Informative References |
|---|
| 1627 | </h2> |
|---|
| [1099] | 1628 | <table> |
|---|
| [231] | 1629 | <tr> |
|---|
| 1630 | <td class="reference"><b id="Luo1998">[Luo1998]</b></td> |
|---|
| 1631 | <td class="top">Luotonen, A., “<a href="http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01">Tunneling TCP based protocols through Web proxy servers</a>”, Internet-Draft draft-luotonen-web-proxy-tunneling-01 (work in progress), August 1998. |
|---|
| 1632 | </td> |
|---|
| 1633 | </tr> |
|---|
| 1634 | <tr> |
|---|
| 1635 | <td class="reference"><b id="RFC1945">[RFC1945]</b></td> |
|---|
| [1099] | 1636 | <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. |
|---|
| [231] | 1637 | </td> |
|---|
| 1638 | </tr> |
|---|
| 1639 | <tr> |
|---|
| 1640 | <td class="reference"><b id="RFC2068">[RFC2068]</b></td> |
|---|
| [1099] | 1641 | <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. |
|---|
| [231] | 1642 | </td> |
|---|
| 1643 | </tr> |
|---|
| 1644 | <tr> |
|---|
| 1645 | <td class="reference"><b id="RFC2616">[RFC2616]</b></td> |
|---|
| [1099] | 1646 | <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. |
|---|
| [231] | 1647 | </td> |
|---|
| 1648 | </tr> |
|---|
| 1649 | <tr> |
|---|
| 1650 | <td class="reference"><b id="RFC2822">[RFC2822]</b></td> |
|---|
| 1651 | <td class="top">Resnick, P., “<a href="http://tools.ietf.org/html/rfc2822">Internet Message Format</a>”, RFC 2822, April 2001. |
|---|
| 1652 | </td> |
|---|
| 1653 | </tr> |
|---|
| 1654 | </table> |
|---|
| [1099] | 1655 | <div class="avoidbreak"> |
|---|
| 1656 | <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> |
|---|
| 1657 | <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span> |
|---|
| 1658 | (editor) |
|---|
| 1659 | <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Day Software</span><span class="adr"><span class="street-address vcardline">23 Corporate Plaza DR, Suite 280</span><span class="vcardline"><span class="locality">Newport Beach</span>, <span class="region">CA</span> <span class="postal-code">92660</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel">Phone: <a href="tel:+1-949-706-5300"><span class="value">+1-949-706-5300</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1-949-706-5305"><span class="value">+1-949-706-5305</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@gbiv.com"><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address> |
|---|
| 1660 | <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">One Laptop per Child</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span> <span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:jg@laptop.org"><span class="email">jg@laptop.org</span></a></span><span class="vcardline">URI: <a href="http://www.laptop.org/" class="url">http://www.laptop.org/</a></span></address> |
|---|
| 1661 | <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:JeffMogul@acm.org"><span class="email">JeffMogul@acm.org</span></a></span></address> |
|---|
| 1662 | <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:henrikn@microsoft.com"><span class="email">henrikn@microsoft.com</span></a></span></address> |
|---|
| 1663 | <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems, Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:LMM@acm.org"><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address> |
|---|
| 1664 | <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address> |
|---|
| 1665 | <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address> |
|---|
| 1666 | <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span> |
|---|
| 1667 | (editor) |
|---|
| 1668 | <span class="n hidden"><span class="family-name">Lafon</span><span class="given-name">Yves</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">W3C / ERCIM</span><span class="street-address vcardline">2004, rte des Lucioles</span><span class="vcardline"><span class="locality">Sophia-Antipolis</span>, <span class="region">AM</span> <span class="postal-code">06902</span></span><span class="country-name vcardline">France</span></span><span class="vcardline">EMail: <a href="mailto:ylafon@w3.org"><span class="email">ylafon@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.raubacapeu.net/people/yves/" class="url">http://www.raubacapeu.net/people/yves/</a></span></address> |
|---|
| 1669 | <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span> |
|---|
| 1670 | (editor) |
|---|
| 1671 | <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">EMail: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> |
|---|
| 1672 | </div> |
|---|
| 1673 | <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> |
|---|
| [231] | 1674 | <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> |
|---|
| 1675 | <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.2" title="504 Gateway Timeout">Section 9.5.5</a>). |
|---|
| 1676 | </p> |
|---|
| 1677 | <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.2" title="201 Created">Section 9.2.2</a>). |
|---|
| 1678 | </p> |
|---|
| 1679 | <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 |
|---|
| 1680 | of errors here can have significant impact on the Internet, and to deal with the following problems: |
|---|
| 1681 | </p> |
|---|
| 1682 | <ol> |
|---|
| 1683 | <li>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where this was incorrectly placing a requirement on the behavior of |
|---|
| 1684 | an implementation of a future version of HTTP/1.x |
|---|
| 1685 | </li> |
|---|
| 1686 | <li>Made it clear that user-agents should retry requests, not "clients" in general.</li> |
|---|
| 1687 | <li>Converted requirements for clients to ignore unexpected 100 (Continue) responses, and for proxies to forward 100 responses, |
|---|
| 1688 | into a general requirement for 1xx responses. |
|---|
| 1689 | </li> |
|---|
| 1690 | <li>Modified some TCP-specific language, to make it clearer that non-TCP transports are possible for HTTP.</li> |
|---|
| 1691 | <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. |
|---|
| 1692 | </li> |
|---|
| 1693 | <li>Allow, rather than require, a server to omit 100 (Continue) if it has already seen some of the request body.</li> |
|---|
| 1694 | <li>Allow servers to defend against denial-of-service attacks and broken clients.</li> |
|---|
| 1695 | </ol> |
|---|
| 1696 | <p id="rfc.section.A.1.p.4">This change adds the Expect header and 417 status code.</p> |
|---|
| 1697 | <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.2" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>) |
|---|
| 1698 | </p> |
|---|
| 1699 | <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="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. |
|---|
| 1700 | </p> |
|---|
| 1701 | <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> |
|---|
| 1702 | <p id="rfc.section.A.2.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 8.5</a>) |
|---|
| 1703 | </p> |
|---|
| 1704 | <p id="rfc.section.A.2.p.2">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the |
|---|
| 1705 | user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">9.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">9.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">9.3.8</a> ) |
|---|
| 1706 | </p> |
|---|
| 1707 | <p id="rfc.section.A.2.p.3">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications |
|---|
| 1708 | as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.4</a>) |
|---|
| 1709 | </p> |
|---|
| 1710 | <p id="rfc.section.A.2.p.4">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly |
|---|
| 1711 | 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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>) |
|---|
| 1712 | </p> |
|---|
| 1713 | <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) |
|---|
| 1714 | </h1> |
|---|
| 1715 | <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 |
|---|
| 1716 | </h2> |
|---|
| 1717 | <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>. |
|---|
| 1718 | </p> |
|---|
| 1719 | <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p2-semantics-00 |
|---|
| 1720 | </h2> |
|---|
| 1721 | <p id="rfc.section.B.2.p.1">Closed issues: </p> |
|---|
| 1722 | <ul> |
|---|
| 1723 | <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>>) |
|---|
| 1724 | </li> |
|---|
| 1725 | <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>>) |
|---|
| 1726 | </li> |
|---|
| 1727 | <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>>) |
|---|
| 1728 | </li> |
|---|
| 1729 | <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>>) |
|---|
| 1730 | </li> |
|---|
| 1731 | <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" |
|---|
| 1732 | </li> |
|---|
| 1733 | <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" |
|---|
| 1734 | </li> |
|---|
| 1735 | <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" |
|---|
| 1736 | </li> |
|---|
| 1737 | <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" |
|---|
| 1738 | </li> |
|---|
| 1739 | </ul> |
|---|
| 1740 | <p id="rfc.section.B.2.p.2">Other changes: </p> |
|---|
| 1741 | <ul> |
|---|
| 1742 | <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> |
|---|
| 1743 | </li> |
|---|
| 1744 | </ul> |
|---|
| 1745 | <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> Since draft-ietf-httpbis-p2-semantics-01 |
|---|
| 1746 | </h2> |
|---|
| 1747 | <p id="rfc.section.B.3.p.1">Closed issues: </p> |
|---|
| 1748 | <ul> |
|---|
| 1749 | <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" |
|---|
| 1750 | </li> |
|---|
| 1751 | <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" |
|---|
| 1752 | </li> |
|---|
| 1753 | </ul> |
|---|
| 1754 | <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>>): |
|---|
| 1755 | </p> |
|---|
| 1756 | <ul> |
|---|
| 1757 | <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li> |
|---|
| 1758 | <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> |
|---|
| 1759 | <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li> |
|---|
| 1760 | </ul> |
|---|
| 1761 | <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> |
|---|
| 1762 | <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.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> |
|---|
| 1763 | </p> |
|---|
| 1764 | <div class="print2col"> |
|---|
| 1765 | <ul class="ind"> |
|---|
| [1099] | 1766 | <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> |
|---|
| 1767 | <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5</a>, <a href="#rfc.iref.23"><b>9.1.1</b></a></li> |
|---|
| 1768 | <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">5</a>, <a href="#rfc.iref.24"><b>9.1.2</b></a></li> |
|---|
| [231] | 1769 | </ul> |
|---|
| 1770 | </li> |
|---|
| [1099] | 1771 | <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul> |
|---|
| 1772 | <li>200 OK (status code) <a href="#rfc.xref.status.200.1">5</a>, <a href="#rfc.iref.25"><b>9.2.1</b></a></li> |
|---|
| 1773 | <li>201 Created (status code) <a href="#rfc.xref.status.201.1">5</a>, <a href="#rfc.iref.26"><b>9.2.2</b></a>, <a href="#rfc.xref.status.201.2">A.1</a></li> |
|---|
| 1774 | <li>202 Accepted (status code) <a href="#rfc.xref.status.202.1">5</a>, <a href="#rfc.iref.27"><b>9.2.3</b></a></li> |
|---|
| 1775 | <li>203 Non-Authoritative Information (status code) <a href="#rfc.xref.status.203.1">5</a>, <a href="#rfc.iref.28"><b>9.2.4</b></a></li> |
|---|
| 1776 | <li>204 No Content (status code) <a href="#rfc.xref.status.204.1">5</a>, <a href="#rfc.iref.29"><b>9.2.5</b></a></li> |
|---|
| 1777 | <li>205 Reset Content (status code) <a href="#rfc.xref.status.205.1">5</a>, <a href="#rfc.iref.30"><b>9.2.6</b></a></li> |
|---|
| 1778 | <li>206 Partial Content (status code) <a href="#rfc.xref.status.206.1">5</a>, <a href="#rfc.iref.31"><b>9.2.7</b></a></li> |
|---|
| [231] | 1779 | </ul> |
|---|
| 1780 | </li> |
|---|
| [1099] | 1781 | <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> |
|---|
| 1782 | <li>300 Multiple Choices (status code) <a href="#rfc.xref.status.300.1">5</a>, <a href="#rfc.iref.32"><b>9.3.1</b></a></li> |
|---|
| 1783 | <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">5</a>, <a href="#rfc.iref.33"><b>9.3.2</b></a>, <a href="#rfc.xref.status.301.2">A.2</a></li> |
|---|
| 1784 | <li>302 Found (status code) <a href="#rfc.xref.status.302.1">5</a>, <a href="#rfc.iref.34"><b>9.3.3</b></a>, <a href="#rfc.xref.status.302.2">A.2</a></li> |
|---|
| 1785 | <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">5</a>, <a href="#rfc.iref.35"><b>9.3.4</b></a></li> |
|---|
| 1786 | <li>304 Not Modified (status code) <a href="#rfc.xref.status.304.1">5</a>, <a href="#rfc.iref.36"><b>9.3.5</b></a></li> |
|---|
| 1787 | <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">5</a>, <a href="#rfc.iref.37"><b>9.3.6</b></a></li> |
|---|
| 1788 | <li>306 (Unused) (status code) <a href="#rfc.iref.38"><b>9.3.7</b></a></li> |
|---|
| 1789 | <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">5</a>, <a href="#rfc.iref.39"><b>9.3.8</b></a>, <a href="#rfc.xref.status.307.2">A.2</a></li> |
|---|
| [231] | 1790 | </ul> |
|---|
| 1791 | </li> |
|---|
| [1099] | 1792 | <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> |
|---|
| 1793 | <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">5</a>, <a href="#rfc.iref.40"><b>9.4.1</b></a></li> |
|---|
| 1794 | <li>401 Unauthorized (status code) <a href="#rfc.xref.status.401.1">5</a>, <a href="#rfc.iref.41"><b>9.4.2</b></a></li> |
|---|
| 1795 | <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">5</a>, <a href="#rfc.iref.42"><b>9.4.3</b></a></li> |
|---|
| 1796 | <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">5</a>, <a href="#rfc.iref.43"><b>9.4.4</b></a>, <a href="#rfc.xref.status.403.2">A.1</a></li> |
|---|
| 1797 | <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">5</a>, <a href="#rfc.iref.44"><b>9.4.5</b></a>, <a href="#rfc.xref.status.404.2">A.1</a></li> |
|---|
| 1798 | <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">5</a>, <a href="#rfc.iref.45"><b>9.4.6</b></a></li> |
|---|
| 1799 | <li>406 Not Acceptable (status code) <a href="#rfc.xref.status.406.1">5</a>, <a href="#rfc.iref.46"><b>9.4.7</b></a></li> |
|---|
| 1800 | <li>407 Proxy Authentication Required (status code) <a href="#rfc.xref.status.407.1">5</a>, <a href="#rfc.iref.47"><b>9.4.8</b></a></li> |
|---|
| 1801 | <li>408 Request Timeout (status code) <a href="#rfc.xref.status.408.1">5</a>, <a href="#rfc.iref.48"><b>9.4.9</b></a></li> |
|---|
| 1802 | <li>409 Conflict (status code) <a href="#rfc.xref.status.409.1">5</a>, <a href="#rfc.iref.49"><b>9.4.10</b></a></li> |
|---|
| 1803 | <li>410 Gone (status code) <a href="#rfc.xref.status.410.1">5</a>, <a href="#rfc.iref.50"><b>9.4.11</b></a>, <a href="#rfc.xref.status.410.2">A.1</a></li> |
|---|
| 1804 | <li>411 Length Required (status code) <a href="#rfc.xref.status.411.1">5</a>, <a href="#rfc.iref.51"><b>9.4.12</b></a></li> |
|---|
| 1805 | <li>412 Precondition Failed (status code) <a href="#rfc.xref.status.412.1">5</a>, <a href="#rfc.iref.52"><b>9.4.13</b></a></li> |
|---|
| 1806 | <li>413 Request Entity Too Large (status code) <a href="#rfc.xref.status.413.1">5</a>, <a href="#rfc.iref.53"><b>9.4.14</b></a></li> |
|---|
| 1807 | <li>414 Request-URI Too Long (status code) <a href="#rfc.xref.status.414.1">5</a>, <a href="#rfc.iref.54"><b>9.4.15</b></a></li> |
|---|
| 1808 | <li>415 Unsupported Media Type (status code) <a href="#rfc.xref.status.415.1">5</a>, <a href="#rfc.iref.55"><b>9.4.16</b></a></li> |
|---|
| 1809 | <li>416 Requested Range Not Satisfiable (status code) <a href="#rfc.xref.status.416.1">5</a>, <a href="#rfc.iref.56"><b>9.4.17</b></a></li> |
|---|
| 1810 | <li>417 Expectation Failed (status code) <a href="#rfc.xref.status.417.1">5</a>, <a href="#rfc.iref.57"><b>9.4.18</b></a></li> |
|---|
| [231] | 1811 | </ul> |
|---|
| 1812 | </li> |
|---|
| [1099] | 1813 | <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul> |
|---|
| 1814 | <li>500 Internal Server Error (status code) <a href="#rfc.xref.status.500.1">5</a>, <a href="#rfc.iref.58"><b>9.5.1</b></a></li> |
|---|
| 1815 | <li>501 Not Implemented (status code) <a href="#rfc.xref.status.501.1">5</a>, <a href="#rfc.iref.59"><b>9.5.2</b></a></li> |
|---|
| 1816 | <li>502 Bad Gateway (status code) <a href="#rfc.xref.status.502.1">5</a>, <a href="#rfc.iref.60"><b>9.5.3</b></a></li> |
|---|
| 1817 | <li>503 Service Unavailable (status code) <a href="#rfc.xref.status.503.1">5</a>, <a href="#rfc.iref.61"><b>9.5.4</b></a></li> |
|---|
| 1818 | <li>504 Gateway Timeout (status code) <a href="#rfc.xref.status.504.1">5</a>, <a href="#rfc.iref.62"><b>9.5.5</b></a>, <a href="#rfc.xref.status.504.2">A.1</a></li> |
|---|
| 1819 | <li>505 HTTP Version Not Supported (status code) <a href="#rfc.xref.status.505.1">5</a>, <a href="#rfc.iref.63"><b>9.5.6</b></a></li> |
|---|
| [231] | 1820 | </ul> |
|---|
| 1821 | </li> |
|---|
| [1099] | 1822 | <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> |
|---|
| 1823 | <li>Allow header <a href="#rfc.xref.header.allow.1">3</a>, <a href="#rfc.iref.a.1"><b>10.1</b></a></li> |
|---|
| [231] | 1824 | </ul> |
|---|
| 1825 | </li> |
|---|
| [1099] | 1826 | <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul> |
|---|
| 1827 | <li>CONNECT method <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.c.1"><b>8.9</b></a></li> |
|---|
| [231] | 1828 | </ul> |
|---|
| 1829 | </li> |
|---|
| [1099] | 1830 | <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> |
|---|
| 1831 | <li>DELETE method <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.d.1"><b>8.7</b></a></li> |
|---|
| [231] | 1832 | </ul> |
|---|
| 1833 | </li> |
|---|
| [1099] | 1834 | <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> |
|---|
| 1835 | <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></li> |
|---|
| [231] | 1836 | </ul> |
|---|
| 1837 | </li> |
|---|
| [1099] | 1838 | <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> |
|---|
| 1839 | <li>From header <a href="#rfc.xref.header.from.1">4</a>, <a href="#rfc.iref.f.1"><b>10.3</b></a></li> |
|---|
| [231] | 1840 | </ul> |
|---|
| 1841 | </li> |
|---|
| [1099] | 1842 | <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> |
|---|
| 1843 | <li>GET method <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.g.8"><b>8.3</b></a></li> |
|---|
| 1844 | <li><tt>Grammar</tt> |
|---|
| 1845 | <ul> |
|---|
| 1846 | <li><tt>Allow</tt> <a href="#rfc.iref.g.9"><b>10.1</b></a></li> |
|---|
| 1847 | <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.19"><b>10.7</b></a></li> |
|---|
| 1848 | <li><tt>Expect</tt> <a href="#rfc.iref.g.10"><b>10.2</b></a></li> |
|---|
| 1849 | <li><tt>expect-params</tt> <a href="#rfc.iref.g.13"><b>10.2</b></a></li> |
|---|
| 1850 | <li><tt>expectation</tt> <a href="#rfc.iref.g.11"><b>10.2</b></a></li> |
|---|
| 1851 | <li><tt>expectation-extension</tt> <a href="#rfc.iref.g.12"><b>10.2</b></a></li> |
|---|
| 1852 | <li><tt>extension-code</tt> <a href="#rfc.iref.g.5"><b>5</b></a></li> |
|---|
| 1853 | <li><tt>extension-method</tt> <a href="#rfc.iref.g.2"><b>3</b></a></li> |
|---|
| 1854 | <li><tt>From</tt> <a href="#rfc.iref.g.14"><b>10.3</b></a></li> |
|---|
| 1855 | <li><tt>Location</tt> <a href="#rfc.iref.g.15"><b>10.4</b></a></li> |
|---|
| 1856 | <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.16"><b>10.5</b></a></li> |
|---|
| 1857 | <li><tt>Method</tt> <a href="#rfc.iref.g.1"><b>3</b></a></li> |
|---|
| 1858 | <li><tt>Reason-Phrase</tt> <a href="#rfc.iref.g.6"><b>5</b></a></li> |
|---|
| 1859 | <li><tt>Referer</tt> <a href="#rfc.iref.g.17"><b>10.6</b></a></li> |
|---|
| 1860 | <li><tt>request-header</tt> <a href="#rfc.iref.g.3"><b>4</b></a></li> |
|---|
| 1861 | <li><tt>response-header</tt> <a href="#rfc.iref.g.7"><b>6</b></a></li> |
|---|
| 1862 | <li><tt>Retry-After</tt> <a href="#rfc.iref.g.18"><b>10.7</b></a></li> |
|---|
| 1863 | <li><tt>Server</tt> <a href="#rfc.iref.g.20"><b>10.8</b></a></li> |
|---|
| 1864 | <li><tt>Status-Code</tt> <a href="#rfc.iref.g.4"><b>5</b></a></li> |
|---|
| 1865 | <li><tt>User-Agent</tt> <a href="#rfc.iref.g.21"><b>10.9</b></a></li> |
|---|
| [231] | 1866 | </ul> |
|---|
| 1867 | </li> |
|---|
| 1868 | </ul> |
|---|
| 1869 | </li> |
|---|
| [1099] | 1870 | <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul> |
|---|
| 1871 | <li>HEAD method <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.h.1"><b>8.4</b></a></li> |
|---|
| 1872 | <li>Headers |
|---|
| 1873 | <ul> |
|---|
| 1874 | <li>Allow <a href="#rfc.xref.header.allow.1">3</a>, <a href="#rfc.iref.h.2"><b>10.1</b></a></li> |
|---|
| 1875 | <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></li> |
|---|
| 1876 | <li>From <a href="#rfc.xref.header.from.1">4</a>, <a href="#rfc.iref.h.4"><b>10.3</b></a></li> |
|---|
| 1877 | <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">A.2</a></li> |
|---|
| 1878 | <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></li> |
|---|
| 1879 | <li>Referer <a href="#rfc.xref.header.referer.1">4</a>, <a href="#rfc.iref.h.7"><b>10.6</b></a></li> |
|---|
| 1880 | <li>Retry-After <a href="#rfc.xref.header.retry-after.1">6</a>, <a href="#rfc.iref.h.8"><b>10.7</b></a></li> |
|---|
| 1881 | <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">12.1</a>, <a href="#rfc.xref.header.server.3">A.2</a></li> |
|---|
| 1882 | <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">12.1</a></li> |
|---|
| [231] | 1883 | </ul> |
|---|
| 1884 | </li> |
|---|
| 1885 | </ul> |
|---|
| 1886 | </li> |
|---|
| [1099] | 1887 | <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> |
|---|
| 1888 | <li>LINK method <a href="#rfc.iref.l.2"><b>A.1</b></a></li> |
|---|
| 1889 | <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">A.2</a></li> |
|---|
| 1890 | <li><em>Luo1998</em> <a href="#rfc.xref.Luo1998.1">8.9</a>, <a href="#Luo1998"><b>14.2</b></a></li> |
|---|
| [231] | 1891 | </ul> |
|---|
| 1892 | </li> |
|---|
| [1099] | 1893 | <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> |
|---|
| 1894 | <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></li> |
|---|
| 1895 | <li>Methods |
|---|
| 1896 | <ul> |
|---|
| 1897 | <li>CONNECT <a href="#rfc.xref.CONNECT.1">3</a>, <a href="#rfc.iref.m.8"><b>8.9</b></a></li> |
|---|
| 1898 | <li>DELETE <a href="#rfc.xref.DELETE.1">3</a>, <a href="#rfc.iref.m.6"><b>8.7</b></a></li> |
|---|
| 1899 | <li>GET <a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.iref.m.2"><b>8.3</b></a></li> |
|---|
| 1900 | <li>HEAD <a href="#rfc.xref.HEAD.1">3</a>, <a href="#rfc.iref.m.3"><b>8.4</b></a></li> |
|---|
| 1901 | <li>LINK <a href="#rfc.iref.m.11"><b>A.1</b></a></li> |
|---|
| 1902 | <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></li> |
|---|
| 1903 | <li>PATCH <a href="#rfc.iref.m.10"><b>A.1</b></a></li> |
|---|
| 1904 | <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">A.2</a></li> |
|---|
| 1905 | <li>PUT <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.m.5"><b>8.6</b></a></li> |
|---|
| 1906 | <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></li> |
|---|
| 1907 | <li>UNLINK <a href="#rfc.iref.m.12"><b>A.1</b></a></li> |
|---|
| [231] | 1908 | </ul> |
|---|
| 1909 | </li> |
|---|
| 1910 | </ul> |
|---|
| 1911 | </li> |
|---|
| [1099] | 1912 | <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> |
|---|
| 1913 | <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></li> |
|---|
| [231] | 1914 | </ul> |
|---|
| 1915 | </li> |
|---|
| [1099] | 1916 | <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> |
|---|
| 1917 | <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">9.1.1</a>, <a href="#rfc.xref.Part1.20">9.5.6</a>, <a href="#rfc.xref.Part1.21">10.2</a>, <a href="#rfc.xref.Part1.22">10.8</a>, <a href="#rfc.xref.Part1.23">10.8</a>, <a href="#rfc.xref.Part1.24">10.9</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.25">A.2</a><ul> |
|---|
| 1918 | <li><em>Section 2.1</em> <a href="#rfc.xref.Part1.2">2</a></li> |
|---|
| 1919 | <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> |
|---|
| 1920 | <li><em>Section 3.1</em> <a href="#rfc.xref.Part1.20">9.5.6</a></li> |
|---|
| 1921 | <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> |
|---|
| 1922 | <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.11">2</a></li> |
|---|
| 1923 | <li><em>Section 3.5</em> <a href="#rfc.xref.Part1.12">2</a>, <a href="#rfc.xref.Part1.22">10.8</a>, <a href="#rfc.xref.Part1.24">10.9</a></li> |
|---|
| 1924 | <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.17">7</a></li> |
|---|
| 1925 | <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.19">9.1.1</a>, <a href="#rfc.xref.Part1.21">10.2</a></li> |
|---|
| 1926 | <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.10">2</a>, <a href="#rfc.xref.Part1.15">4</a></li> |
|---|
| 1927 | <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.16">4</a></li> |
|---|
| 1928 | <li><em>Section 8.9</em> <a href="#rfc.xref.Part1.18">8.8</a>, <a href="#rfc.xref.Part1.23">10.8</a>, <a href="#rfc.xref.Part1.25">A.2</a></li> |
|---|
| [231] | 1929 | </ul> |
|---|
| 1930 | </li> |
|---|
| [1099] | 1931 | <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> |
|---|
| 1932 | <li><em>Section 5</em> <a href="#rfc.xref.Part3.10">9.3.1</a></li> |
|---|
| 1933 | <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">2</a>, <a href="#rfc.xref.Part3.5">4</a></li> |
|---|
| 1934 | <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">2</a>, <a href="#rfc.xref.Part3.6">4</a></li> |
|---|
| 1935 | <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">2</a>, <a href="#rfc.xref.Part3.7">4</a></li> |
|---|
| 1936 | <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">2</a>, <a href="#rfc.xref.Part3.8">4</a></li> |
|---|
| 1937 | <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.11">10.4</a></li> |
|---|
| [231] | 1938 | </ul> |
|---|
| 1939 | </li> |
|---|
| [1099] | 1940 | <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> |
|---|
| 1941 | <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> |
|---|
| 1942 | <li><em>Section 7.2</em> <a href="#rfc.xref.Part4.2">2</a>, <a href="#rfc.xref.Part4.6">4</a></li> |
|---|
| 1943 | <li><em>Section 7.3</em> <a href="#rfc.xref.Part4.3">2</a>, <a href="#rfc.xref.Part4.7">4</a></li> |
|---|
| 1944 | <li><em>Section 7.4</em> <a href="#rfc.xref.Part4.4">2</a>, <a href="#rfc.xref.Part4.8">4</a></li> |
|---|
| 1945 | <li><em>Section 7.5</em> <a href="#rfc.xref.Part4.5">2</a>, <a href="#rfc.xref.Part4.9">4</a></li> |
|---|
| [231] | 1946 | </ul> |
|---|
| 1947 | </li> |
|---|
| [1099] | 1948 | <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> |
|---|
| 1949 | <li><em>Section 6.1</em> <a href="#rfc.xref.Part5.1">2</a>, <a href="#rfc.xref.Part5.6">6</a></li> |
|---|
| 1950 | <li><em>Section 6.3</em> <a href="#rfc.xref.Part5.2">2</a>, <a href="#rfc.xref.Part5.4">4</a></li> |
|---|
| 1951 | <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> |
|---|
| [231] | 1952 | </ul> |
|---|
| 1953 | </li> |
|---|
| [1099] | 1954 | <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> |
|---|
| 1955 | <li><em>Section 16.1</em> <a href="#rfc.xref.Part6.1">2</a>, <a href="#rfc.xref.Part6.3">6</a></li> |
|---|
| 1956 | <li><em>Section 16.5</em> <a href="#rfc.xref.Part6.2">2</a>, <a href="#rfc.xref.Part6.4">6</a></li> |
|---|
| [231] | 1957 | </ul> |
|---|
| 1958 | </li> |
|---|
| [1099] | 1959 | <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> |
|---|
| 1960 | <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.1">2</a>, <a href="#rfc.xref.Part7.5">4</a></li> |
|---|
| 1961 | <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.2">2</a>, <a href="#rfc.xref.Part7.7">6</a></li> |
|---|
| 1962 | <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.3">2</a>, <a href="#rfc.xref.Part7.6">4</a></li> |
|---|
| 1963 | <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.4">2</a>, <a href="#rfc.xref.Part7.8">6</a></li> |
|---|
| [231] | 1964 | </ul> |
|---|
| 1965 | </li> |
|---|
| [1099] | 1966 | <li>PATCH method <a href="#rfc.iref.p.3"><b>A.1</b></a></li> |
|---|
| 1967 | <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">A.2</a></li> |
|---|
| 1968 | <li>PUT method <a href="#rfc.xref.PUT.1">3</a>, <a href="#rfc.iref.p.2"><b>8.6</b></a></li> |
|---|
| [231] | 1969 | </ul> |
|---|
| 1970 | </li> |
|---|
| [1099] | 1971 | <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> |
|---|
| 1972 | <li>Referer header <a href="#rfc.xref.header.referer.1">4</a>, <a href="#rfc.iref.r.1"><b>10.6</b></a></li> |
|---|
| 1973 | <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></li> |
|---|
| 1974 | <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">9.3.3</a>, <a href="#RFC1945"><b>14.2</b></a></li> |
|---|
| 1975 | <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">9.3.3</a>, <a href="#rfc.xref.RFC2068.2">9.3.6</a>, <a href="#RFC2068"><b>14.2</b></a>, <a href="#rfc.xref.RFC2068.3">A.1</a></li> |
|---|
| 1976 | <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>14.1</b></a></li> |
|---|
| 1977 | <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> |
|---|
| 1978 | <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> |
|---|
| 1979 | <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> |
|---|
| [231] | 1980 | </ul> |
|---|
| 1981 | </li> |
|---|
| 1982 | </ul> |
|---|
| 1983 | </li> |
|---|
| [1099] | 1984 | <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul> |
|---|
| 1985 | <li>Server header <a href="#rfc.xref.header.server.1">6</a>, <a href="#rfc.iref.s.42"><b>10.8</b></a>, <a href="#rfc.xref.header.server.2">12.1</a>, <a href="#rfc.xref.header.server.3">A.2</a></li> |
|---|
| 1986 | <li>Status Codes |
|---|
| 1987 | <ul> |
|---|
| 1988 | <li>100 Continue <a href="#rfc.xref.status.100.1">5</a>, <a href="#rfc.iref.s.1"><b>9.1.1</b></a></li> |
|---|
| 1989 | <li>101 Switching Protocols <a href="#rfc.xref.status.101.1">5</a>, <a href="#rfc.iref.s.2"><b>9.1.2</b></a></li> |
|---|
| 1990 | <li>200 OK <a href="#rfc.xref.status.200.1">5</a>, <a href="#rfc.iref.s.3"><b>9.2.1</b></a></li> |
|---|
| 1991 | <li>201 Created <a href="#rfc.xref.status.201.1">5</a>, <a href="#rfc.iref.s.4"><b>9.2.2</b></a>, <a href="#rfc.xref.status.201.2">A.1</a></li> |
|---|
| 1992 | <li>202 Accepted <a href="#rfc.xref.status.202.1">5</a>, <a href="#rfc.iref.s.5"><b>9.2.3</b></a></li> |
|---|
| 1993 | <li>203 Non-Authoritative Information <a href="#rfc.xref.status.203.1">5</a>, <a href="#rfc.iref.s.6"><b>9.2.4</b></a></li> |
|---|
| 1994 | <li>204 No Content <a href="#rfc.xref.status.204.1">5</a>, <a href="#rfc.iref.s.7"><b>9.2.5</b></a></li> |
|---|
| 1995 | <li>205 Reset Content <a href="#rfc.xref.status.205.1">5</a>, <a href="#rfc.iref.s.8"><b>9.2.6</b></a></li> |
|---|
| 1996 | <li>206 Partial Content <a href="#rfc.xref.status.206.1">5</a>, <a href="#rfc.iref.s.9"><b>9.2.7</b></a></li> |
|---|
| 1997 | <li>300 Multiple Choices <a href="#rfc.xref.status.300.1">5</a>, <a href="#rfc.iref.s.10"><b>9.3.1</b></a></li> |
|---|
| 1998 | <li>301 Moved Permanently <a href="#rfc.xref.status.301.1">5</a>, <a href="#rfc.iref.s.11"><b>9.3.2</b></a>, <a href="#rfc.xref.status.301.2">A.2</a></li> |
|---|
| 1999 | <li>302 Found <a href="#rfc.xref.status.302.1">5</a>, <a href="#rfc.iref.s.12"><b>9.3.3</b></a>, <a href="#rfc.xref.status.302.2">A.2</a></li> |
|---|
| 2000 | <li>303 See Other <a href="#rfc.xref.status.303.1">5</a>, <a href="#rfc.iref.s.13"><b>9.3.4</b></a></li> |
|---|
| 2001 | <li>304 Not Modified <a href="#rfc.xref.status.304.1">5</a>, <a href="#rfc.iref.s.14"><b>9.3.5</b></a></li> |
|---|
| 2002 | <li>305 Use Proxy <a href="#rfc.xref.status.305.1">5</a>, <a href="#rfc.iref.s.15"><b>9.3.6</b></a></li> |
|---|
| 2003 | <li>306 (Unused) <a href="#rfc.iref.s.16"><b>9.3.7</b></a></li> |
|---|
| 2004 | <li>307 Temporary Redirect <a href="#rfc.xref.status.307.1">5</a>, <a href="#rfc.iref.s.17"><b>9.3.8</b></a>, <a href="#rfc.xref.status.307.2">A.2</a></li> |
|---|
| 2005 | <li>400 Bad Request <a href="#rfc.xref.status.400.1">5</a>, <a href="#rfc.iref.s.18"><b>9.4.1</b></a></li> |
|---|
| 2006 | <li>401 Unauthorized <a href="#rfc.xref.status.401.1">5</a>, <a href="#rfc.iref.s.19"><b>9.4.2</b></a></li> |
|---|
| 2007 | <li>402 Payment Required <a href="#rfc.xref.status.402.1">5</a>, <a href="#rfc.iref.s.20"><b>9.4.3</b></a></li> |
|---|
| 2008 | <li>403 Forbidden <a href="#rfc.xref.status.403.1">5</a>, <a href="#rfc.iref.s.21"><b>9.4.4</b></a>, <a href="#rfc.xref.status.403.2">A.1</a></li> |
|---|
| 2009 | <li>404 Not Found <a href="#rfc.xref.status.404.1">5</a>, <a href="#rfc.iref.s.22"><b>9.4.5</b></a>, <a href="#rfc.xref.status.404.2">A.1</a></li> |
|---|
| 2010 | <li>405 Method Not Allowed <a href="#rfc.xref.status.405.1">5</a>, <a href="#rfc.iref.s.23"><b>9.4.6</b></a></li> |
|---|
| 2011 | <li>406 Not Acceptable <a href="#rfc.xref.status.406.1">5</a>, <a href="#rfc.iref.s.24"><b>9.4.7</b></a></li> |
|---|
| 2012 | <li>407 Proxy Authentication Required <a href="#rfc.xref.status.407.1">5</a>, <a href="#rfc.iref.s.25"><b>9.4.8</b></a></li> |
|---|
| 2013 | <li>408 Request Timeout <a href="#rfc.xref.status.408.1">5</a>, <a href="#rfc.iref.s.26"><b>9.4.9</b></a></li> |
|---|
| 2014 | <li>409 Conflict <a href="#rfc.xref.status.409.1">5</a>, <a href="#rfc.iref.s.27"><b>9.4.10</b></a></li> |
|---|
| 2015 | <li>410 Gone <a href="#rfc.xref.status.410.1">5</a>, <a href="#rfc.iref.s.28"><b>9.4.11</b></a>, <a href="#rfc.xref.status.410.2">A.1</a></li> |
|---|
| 2016 | <li>411 Length Required <a href="#rfc.xref.status.411.1">5</a>, <a href="#rfc.iref.s.29"><b>9.4.12</b></a></li> |
|---|
| 2017 | <li>412 Precondition Failed <a href="#rfc.xref.status.412.1">5</a>, <a href="#rfc.iref.s.30"><b>9.4.13</b></a></li> |
|---|
| 2018 | <li>413 Request Entity Too Large <a href="#rfc.xref.status.413.1">5</a>, <a href="#rfc.iref.s.31"><b>9.4.14</b></a></li> |
|---|
| 2019 | <li>414 Request-URI Too Long <a href="#rfc.xref.status.414.1">5</a>, <a href="#rfc.iref.s.32"><b>9.4.15</b></a></li> |
|---|
| 2020 | <li>415 Unsupported Media Type <a href="#rfc.xref.status.415.1">5</a>, <a href="#rfc.iref.s.33"><b>9.4.16</b></a></li> |
|---|
| 2021 | <li>416 Requested Range Not Satisfiable <a href="#rfc.xref.status.416.1">5</a>, <a href="#rfc.iref.s.34"><b>9.4.17</b></a></li> |
|---|
| 2022 | <li>417 Expectation Failed <a href="#rfc.xref.status.417.1">5</a>, <a href="#rfc.iref.s.35"><b>9.4.18</b></a></li> |
|---|
| 2023 | <li>500 Internal Server Error <a href="#rfc.xref.status.500.1">5</a>, <a href="#rfc.iref.s.36"><b>9.5.1</b></a></li> |
|---|
| 2024 | <li>501 Not Implemented <a href="#rfc.xref.status.501.1">5</a>, <a href="#rfc.iref.s.37"><b>9.5.2</b></a></li> |
|---|
| 2025 | <li>502 Bad Gateway <a href="#rfc.xref.status.502.1">5</a>, <a href="#rfc.iref.s.38"><b>9.5.3</b></a></li> |
|---|
| 2026 | <li>503 Service Unavailable <a href="#rfc.xref.status.503.1">5</a>, <a href="#rfc.iref.s.39"><b>9.5.4</b></a></li> |
|---|
| 2027 | <li>504 Gateway Timeout <a href="#rfc.xref.status.504.1">5</a>, <a href="#rfc.iref.s.40"><b>9.5.5</b></a>, <a href="#rfc.xref.status.504.2">A.1</a></li> |
|---|
| 2028 | <li>505 HTTP Version Not Supported <a href="#rfc.xref.status.505.1">5</a>, <a href="#rfc.iref.s.41"><b>9.5.6</b></a></li> |
|---|
| [231] | 2029 | </ul> |
|---|
| 2030 | </li> |
|---|
| 2031 | </ul> |
|---|
| 2032 | </li> |
|---|
| [1099] | 2033 | <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> |
|---|
| 2034 | <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></li> |
|---|
| [231] | 2035 | </ul> |
|---|
| 2036 | </li> |
|---|
| [1099] | 2037 | <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> |
|---|
| 2038 | <li>UNLINK method <a href="#rfc.iref.u.2"><b>A.1</b></a></li> |
|---|
| 2039 | <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">12.1</a></li> |
|---|
| [231] | 2040 | </ul> |
|---|
| 2041 | </li> |
|---|
| 2042 | </ul> |
|---|
| 2043 | </div> |
|---|
| [1099] | 2044 | <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> |
|---|
| 2045 | <p>Copyright © The IETF Trust (2008).</p> |
|---|
| 2046 | <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the |
|---|
| 2047 | authors retain all their rights. |
|---|
| 2048 | </p> |
|---|
| 2049 | <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION |
|---|
| 2050 | HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE |
|---|
| 2051 | DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN |
|---|
| 2052 | WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
|---|
| 2053 | </p> |
|---|
| 2054 | <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1> |
|---|
| 2055 | <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might |
|---|
| 2056 | be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any |
|---|
| 2057 | license under such rights might or might not be available; nor does it represent that it has made any independent effort to |
|---|
| 2058 | identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and |
|---|
| 2059 | BCP 79. |
|---|
| 2060 | </p> |
|---|
| 2061 | <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result |
|---|
| 2062 | of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users |
|---|
| 2063 | 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>. |
|---|
| 2064 | </p> |
|---|
| 2065 | <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary |
|---|
| 2066 | rights that may cover technology that may be required to implement this standard. Please address the information to the IETF |
|---|
| 2067 | at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>. |
|---|
| 2068 | </p> |
|---|
| [231] | 2069 | </body> |
|---|
| 2070 | </html> |
|---|
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
