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