| 1 | <!DOCTYPE html |
|---|
| 2 | PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
|---|
| 3 | <html lang="en"> |
|---|
| 4 | <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"> |
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
|---|
| 6 | <title>SPDY Protocol</title><script> |
|---|
| 7 | var buttonsAdded = false; |
|---|
| 8 | |
|---|
| 9 | function init() { |
|---|
| 10 | var fb = document.createElement("div"); |
|---|
| 11 | fb.className = "feedback noprint"; |
|---|
| 12 | fb.setAttribute("onclick", "feedback();"); |
|---|
| 13 | fb.appendChild(document.createTextNode("feedback")); |
|---|
| 14 | |
|---|
| 15 | var bodyl = document.getElementsByTagName("body"); |
|---|
| 16 | bodyl.item(0).appendChild(fb); |
|---|
| 17 | } |
|---|
| 18 | |
|---|
| 19 | function feedback() { |
|---|
| 20 | toggleButtonsToElementsByName("h1"); |
|---|
| 21 | toggleButtonsToElementsByName("h2"); |
|---|
| 22 | toggleButtonsToElementsByName("h3"); |
|---|
| 23 | toggleButtonsToElementsByName("h4"); |
|---|
| 24 | |
|---|
| 25 | buttonsAdded = !buttonsAdded; |
|---|
| 26 | } |
|---|
| 27 | |
|---|
| 28 | function toggleButtonsToElementsByName(name) { |
|---|
| 29 | var list = document.getElementsByTagName(name); |
|---|
| 30 | for (var i = 0; i < list.length; i++) { |
|---|
| 31 | toggleButton(list.item(i)); |
|---|
| 32 | } |
|---|
| 33 | } |
|---|
| 34 | |
|---|
| 35 | function toggleButton(node) { |
|---|
| 36 | if (! buttonsAdded) { |
|---|
| 37 | |
|---|
| 38 | // docname |
|---|
| 39 | var template = "mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"; |
|---|
| 40 | |
|---|
| 41 | var id = node.getAttribute("id"); |
|---|
| 42 | // better id available? |
|---|
| 43 | var titlelinks = node.getElementsByTagName("a"); |
|---|
| 44 | for (var i = 0; i < titlelinks.length; i++) { |
|---|
| 45 | var tl = titlelinks.item(i); |
|---|
| 46 | if (tl.getAttribute("id")) { |
|---|
| 47 | id = tl.getAttribute("id"); |
|---|
| 48 | } |
|---|
| 49 | } |
|---|
| 50 | |
|---|
| 51 | // ref |
|---|
| 52 | var ref = window.location.toString(); |
|---|
| 53 | var hash = ref.indexOf("#"); |
|---|
| 54 | if (hash != -1) { |
|---|
| 55 | ref = ref.substring(0, hash); |
|---|
| 56 | } |
|---|
| 57 | if (id != "") { |
|---|
| 58 | ref += "#" + id; |
|---|
| 59 | } |
|---|
| 60 | |
|---|
| 61 | // docname |
|---|
| 62 | var docname = "draft-ietf-httpbis-http2-latest"; |
|---|
| 63 | |
|---|
| 64 | // section |
|---|
| 65 | var section = node.textContent; |
|---|
| 66 | section = section.replace("\u00a0", " "); |
|---|
| 67 | |
|---|
| 68 | // build URI from template |
|---|
| 69 | var uri = template.replace("{docname}", encodeURIComponent(docname)); |
|---|
| 70 | uri = uri.replace("{section}", encodeURIComponent(section)); |
|---|
| 71 | uri = uri.replace("{ref}", encodeURIComponent(ref)); |
|---|
| 72 | |
|---|
| 73 | var button = document.createElement("a"); |
|---|
| 74 | button.className = "fbbutton noprint"; |
|---|
| 75 | button.setAttribute("href", uri); |
|---|
| 76 | button.appendChild(document.createTextNode("send feedback")); |
|---|
| 77 | node.appendChild(button); |
|---|
| 78 | } |
|---|
| 79 | else { |
|---|
| 80 | var buttons = node.getElementsByTagName("a"); |
|---|
| 81 | for (var i = 0; i < buttons.length; i++) { |
|---|
| 82 | var b = buttons.item(i); |
|---|
| 83 | if (b.className == "fbbutton noprint") { |
|---|
| 84 | node.removeChild(b); |
|---|
| 85 | } |
|---|
| 86 | } |
|---|
| 87 | } |
|---|
| 88 | }</script><style type="text/css" title="Xml2Rfc (sans serif)"> |
|---|
| 89 | a { |
|---|
| 90 | text-decoration: none; |
|---|
| 91 | } |
|---|
| 92 | a.smpl { |
|---|
| 93 | color: black; |
|---|
| 94 | } |
|---|
| 95 | a:hover { |
|---|
| 96 | text-decoration: underline; |
|---|
| 97 | } |
|---|
| 98 | a:active { |
|---|
| 99 | text-decoration: underline; |
|---|
| 100 | } |
|---|
| 101 | address { |
|---|
| 102 | margin-top: 1em; |
|---|
| 103 | margin-left: 2em; |
|---|
| 104 | font-style: normal; |
|---|
| 105 | } |
|---|
| 106 | body { |
|---|
| 107 | color: black; |
|---|
| 108 | font-family: verdana, helvetica, arial, sans-serif; |
|---|
| 109 | font-size: 10pt; |
|---|
| 110 | margin-right: 2em; |
|---|
| 111 | } |
|---|
| 112 | cite { |
|---|
| 113 | font-style: normal; |
|---|
| 114 | } |
|---|
| 115 | dl { |
|---|
| 116 | margin-left: 2em; |
|---|
| 117 | } |
|---|
| 118 | ul.empty { |
|---|
| 119 | list-style-type: none; |
|---|
| 120 | } |
|---|
| 121 | ul.empty li { |
|---|
| 122 | margin-top: .5em; |
|---|
| 123 | } |
|---|
| 124 | dl p { |
|---|
| 125 | margin-left: 0em; |
|---|
| 126 | } |
|---|
| 127 | dt { |
|---|
| 128 | margin-top: .5em; |
|---|
| 129 | } |
|---|
| 130 | h1 { |
|---|
| 131 | font-size: 14pt; |
|---|
| 132 | line-height: 21pt; |
|---|
| 133 | page-break-after: avoid; |
|---|
| 134 | } |
|---|
| 135 | h1.np { |
|---|
| 136 | page-break-before: always; |
|---|
| 137 | } |
|---|
| 138 | h1 a { |
|---|
| 139 | color: #333333; |
|---|
| 140 | } |
|---|
| 141 | h2 { |
|---|
| 142 | font-size: 12pt; |
|---|
| 143 | line-height: 15pt; |
|---|
| 144 | page-break-after: avoid; |
|---|
| 145 | } |
|---|
| 146 | h3, h4, h5, h6 { |
|---|
| 147 | font-size: 10pt; |
|---|
| 148 | page-break-after: avoid; |
|---|
| 149 | } |
|---|
| 150 | h2 a, h3 a, h4 a, h5 a, h6 a { |
|---|
| 151 | color: black; |
|---|
| 152 | } |
|---|
| 153 | img { |
|---|
| 154 | margin-left: 3em; |
|---|
| 155 | } |
|---|
| 156 | li { |
|---|
| 157 | margin-left: 2em; |
|---|
| 158 | } |
|---|
| 159 | ol { |
|---|
| 160 | margin-left: 2em; |
|---|
| 161 | } |
|---|
| 162 | ol.la { |
|---|
| 163 | list-style-type: lower-alpha; |
|---|
| 164 | } |
|---|
| 165 | ol.ua { |
|---|
| 166 | list-style-type: upper-alpha; |
|---|
| 167 | } |
|---|
| 168 | ol p { |
|---|
| 169 | margin-left: 0em; |
|---|
| 170 | } |
|---|
| 171 | p { |
|---|
| 172 | margin-left: 2em; |
|---|
| 173 | } |
|---|
| 174 | pre { |
|---|
| 175 | margin-left: 3em; |
|---|
| 176 | background-color: lightyellow; |
|---|
| 177 | padding: .25em; |
|---|
| 178 | page-break-inside: avoid; |
|---|
| 179 | } |
|---|
| 180 | pre.ccmarker { |
|---|
| 181 | background-color: white; |
|---|
| 182 | color: gray; |
|---|
| 183 | } |
|---|
| 184 | pre.ccmarker > span { |
|---|
| 185 | font-size: small; |
|---|
| 186 | } |
|---|
| 187 | pre.cct { |
|---|
| 188 | margin-bottom: -1em; |
|---|
| 189 | } |
|---|
| 190 | pre.ccb { |
|---|
| 191 | margin-top: -1em; |
|---|
| 192 | } |
|---|
| 193 | pre.text2 { |
|---|
| 194 | border-style: dotted; |
|---|
| 195 | border-width: 1px; |
|---|
| 196 | background-color: #f0f0f0; |
|---|
| 197 | width: 69em; |
|---|
| 198 | } |
|---|
| 199 | pre.inline { |
|---|
| 200 | background-color: white; |
|---|
| 201 | padding: 0em; |
|---|
| 202 | } |
|---|
| 203 | pre.text { |
|---|
| 204 | border-style: dotted; |
|---|
| 205 | border-width: 1px; |
|---|
| 206 | background-color: #f8f8f8; |
|---|
| 207 | width: 69em; |
|---|
| 208 | } |
|---|
| 209 | pre.drawing { |
|---|
| 210 | border-style: solid; |
|---|
| 211 | border-width: 1px; |
|---|
| 212 | background-color: #f8f8f8; |
|---|
| 213 | padding: 2em; |
|---|
| 214 | } |
|---|
| 215 | table { |
|---|
| 216 | margin-left: 2em; |
|---|
| 217 | } |
|---|
| 218 | table.header { |
|---|
| 219 | border-spacing: 1px; |
|---|
| 220 | width: 95%; |
|---|
| 221 | font-size: 10pt; |
|---|
| 222 | color: white; |
|---|
| 223 | } |
|---|
| 224 | td.top { |
|---|
| 225 | vertical-align: top; |
|---|
| 226 | } |
|---|
| 227 | td.topnowrap { |
|---|
| 228 | vertical-align: top; |
|---|
| 229 | white-space: nowrap; |
|---|
| 230 | } |
|---|
| 231 | table.header td { |
|---|
| 232 | background-color: gray; |
|---|
| 233 | width: 50%; |
|---|
| 234 | } |
|---|
| 235 | td.reference { |
|---|
| 236 | vertical-align: top; |
|---|
| 237 | white-space: nowrap; |
|---|
| 238 | padding-right: 1em; |
|---|
| 239 | } |
|---|
| 240 | thead { |
|---|
| 241 | display:table-header-group; |
|---|
| 242 | } |
|---|
| 243 | ul.toc, ul.toc ul { |
|---|
| 244 | list-style: none; |
|---|
| 245 | margin-left: 1.5em; |
|---|
| 246 | padding-left: 0em; |
|---|
| 247 | } |
|---|
| 248 | ul.toc li { |
|---|
| 249 | line-height: 150%; |
|---|
| 250 | font-weight: bold; |
|---|
| 251 | font-size: 10pt; |
|---|
| 252 | margin-left: 0em; |
|---|
| 253 | } |
|---|
| 254 | ul.toc li li { |
|---|
| 255 | line-height: normal; |
|---|
| 256 | font-weight: normal; |
|---|
| 257 | font-size: 9pt; |
|---|
| 258 | margin-left: 0em; |
|---|
| 259 | } |
|---|
| 260 | li.excluded { |
|---|
| 261 | font-size: 0pt; |
|---|
| 262 | } |
|---|
| 263 | ul p { |
|---|
| 264 | margin-left: 0em; |
|---|
| 265 | } |
|---|
| 266 | ul.ind, ul.ind ul { |
|---|
| 267 | list-style: none; |
|---|
| 268 | margin-left: 1.5em; |
|---|
| 269 | padding-left: 0em; |
|---|
| 270 | page-break-before: avoid; |
|---|
| 271 | } |
|---|
| 272 | ul.ind li { |
|---|
| 273 | font-weight: bold; |
|---|
| 274 | line-height: 200%; |
|---|
| 275 | margin-left: 0em; |
|---|
| 276 | } |
|---|
| 277 | ul.ind li li { |
|---|
| 278 | font-weight: normal; |
|---|
| 279 | line-height: 150%; |
|---|
| 280 | margin-left: 0em; |
|---|
| 281 | } |
|---|
| 282 | .avoidbreak { |
|---|
| 283 | page-break-inside: avoid; |
|---|
| 284 | } |
|---|
| 285 | |
|---|
| 286 | .comment { |
|---|
| 287 | background-color: yellow; |
|---|
| 288 | } |
|---|
| 289 | .center { |
|---|
| 290 | text-align: center; |
|---|
| 291 | } |
|---|
| 292 | .error { |
|---|
| 293 | color: red; |
|---|
| 294 | font-style: italic; |
|---|
| 295 | font-weight: bold; |
|---|
| 296 | } |
|---|
| 297 | .figure { |
|---|
| 298 | font-weight: bold; |
|---|
| 299 | text-align: center; |
|---|
| 300 | font-size: 9pt; |
|---|
| 301 | } |
|---|
| 302 | .filename { |
|---|
| 303 | color: #333333; |
|---|
| 304 | font-weight: bold; |
|---|
| 305 | font-size: 12pt; |
|---|
| 306 | line-height: 21pt; |
|---|
| 307 | text-align: center; |
|---|
| 308 | } |
|---|
| 309 | .fn { |
|---|
| 310 | font-weight: bold; |
|---|
| 311 | } |
|---|
| 312 | .hidden { |
|---|
| 313 | display: none; |
|---|
| 314 | } |
|---|
| 315 | .left { |
|---|
| 316 | text-align: left; |
|---|
| 317 | } |
|---|
| 318 | .right { |
|---|
| 319 | text-align: right; |
|---|
| 320 | } |
|---|
| 321 | .title { |
|---|
| 322 | color: #990000; |
|---|
| 323 | font-size: 18pt; |
|---|
| 324 | line-height: 18pt; |
|---|
| 325 | font-weight: bold; |
|---|
| 326 | text-align: center; |
|---|
| 327 | margin-top: 36pt; |
|---|
| 328 | } |
|---|
| 329 | .vcardline { |
|---|
| 330 | display: block; |
|---|
| 331 | } |
|---|
| 332 | .warning { |
|---|
| 333 | font-size: 14pt; |
|---|
| 334 | background-color: yellow; |
|---|
| 335 | } |
|---|
| 336 | .feedback { |
|---|
| 337 | position: fixed; |
|---|
| 338 | bottom: 1%; |
|---|
| 339 | right: 1%; |
|---|
| 340 | padding: 3px 5px; |
|---|
| 341 | color: white; |
|---|
| 342 | border-radius: 5px; |
|---|
| 343 | background: #a00000; |
|---|
| 344 | border: 1px solid silver; |
|---|
| 345 | } |
|---|
| 346 | .fbbutton { |
|---|
| 347 | margin-left: 1em; |
|---|
| 348 | color: #303030; |
|---|
| 349 | font-size: small; |
|---|
| 350 | font-weight: normal; |
|---|
| 351 | background: #d0d000; |
|---|
| 352 | padding: 1px 4px; |
|---|
| 353 | border: 1px solid silver; |
|---|
| 354 | border-radius: 5px; |
|---|
| 355 | } |
|---|
| 356 | |
|---|
| 357 | @media print { |
|---|
| 358 | .noprint { |
|---|
| 359 | display: none; |
|---|
| 360 | } |
|---|
| 361 | |
|---|
| 362 | a { |
|---|
| 363 | color: black; |
|---|
| 364 | text-decoration: none; |
|---|
| 365 | } |
|---|
| 366 | |
|---|
| 367 | table.header { |
|---|
| 368 | width: 90%; |
|---|
| 369 | } |
|---|
| 370 | |
|---|
| 371 | td.header { |
|---|
| 372 | width: 50%; |
|---|
| 373 | color: black; |
|---|
| 374 | background-color: white; |
|---|
| 375 | vertical-align: top; |
|---|
| 376 | font-size: 12pt; |
|---|
| 377 | } |
|---|
| 378 | |
|---|
| 379 | ul.toc a:nth-child(2)::after { |
|---|
| 380 | content: leader('.') target-counter(attr(href), page); |
|---|
| 381 | } |
|---|
| 382 | |
|---|
| 383 | ul.ind li li a { |
|---|
| 384 | content: target-counter(attr(href), page); |
|---|
| 385 | } |
|---|
| 386 | |
|---|
| 387 | .print2col { |
|---|
| 388 | column-count: 2; |
|---|
| 389 | -moz-column-count: 2; |
|---|
| 390 | column-fill: auto; |
|---|
| 391 | } |
|---|
| 392 | } |
|---|
| 393 | |
|---|
| 394 | @page { |
|---|
| 395 | @top-left { |
|---|
| 396 | content: "Internet-Draft"; |
|---|
| 397 | } |
|---|
| 398 | @top-right { |
|---|
| 399 | content: "January 2013"; |
|---|
| 400 | } |
|---|
| 401 | @top-center { |
|---|
| 402 | content: "SPDY"; |
|---|
| 403 | } |
|---|
| 404 | @bottom-left { |
|---|
| 405 | content: "Belshe, et al."; |
|---|
| 406 | } |
|---|
| 407 | @bottom-center { |
|---|
| 408 | content: "Expires July 6, 2013"; |
|---|
| 409 | } |
|---|
| 410 | @bottom-right { |
|---|
| 411 | content: "[Page " counter(page) "]"; |
|---|
| 412 | } |
|---|
| 413 | } |
|---|
| 414 | |
|---|
| 415 | @page:first { |
|---|
| 416 | @top-left { |
|---|
| 417 | content: normal; |
|---|
| 418 | } |
|---|
| 419 | @top-right { |
|---|
| 420 | content: normal; |
|---|
| 421 | } |
|---|
| 422 | @top-center { |
|---|
| 423 | content: normal; |
|---|
| 424 | } |
|---|
| 425 | } |
|---|
| 426 | </style><link rel="Contents" href="#rfc.toc"> |
|---|
| 427 | <link rel="Author" href="#rfc.authors"> |
|---|
| 428 | <link rel="Copyright" href="#rfc.copyrightnotice"> |
|---|
| 429 | <link rel="Index" href="#rfc.index"> |
|---|
| 430 | <link rel="Chapter" title="1 Overview" href="#rfc.section.1"> |
|---|
| 431 | <link rel="Chapter" title="2 SPDY Framing Layer" href="#rfc.section.2"> |
|---|
| 432 | <link rel="Chapter" title="3 HTTP Layering over SPDY" href="#rfc.section.3"> |
|---|
| 433 | <link rel="Chapter" title="4 Design Rationale and Notes" href="#rfc.section.4"> |
|---|
| 434 | <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5"> |
|---|
| 435 | <link rel="Chapter" title="6 Privacy Considerations" href="#rfc.section.6"> |
|---|
| 436 | <link rel="Chapter" title="7 Incompatibilities with SPDY draft #2" href="#rfc.section.7"> |
|---|
| 437 | <link rel="Chapter" title="8 Requirements Notation" href="#rfc.section.8"> |
|---|
| 438 | <link rel="Chapter" title="9 Acknowledgements" href="#rfc.section.9"> |
|---|
| 439 | <link rel="Chapter" href="#rfc.section.10" title="10 Normative References"> |
|---|
| 440 | <link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A"> |
|---|
| 441 | <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.589, 2012-11-30 14:23:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> |
|---|
| 442 | <meta name="keywords" content="HTTP"> |
|---|
| 443 | <link rel="schema.dct" href="http://purl.org/dc/terms/"> |
|---|
| 444 | <meta name="dct.creator" content="Belshe, M."> |
|---|
| 445 | <meta name="dct.creator" content="Peon, R."> |
|---|
| 446 | <meta name="dct.creator" content="Thomson, M."> |
|---|
| 447 | <meta name="dct.creator" content="Melnikov, A."> |
|---|
| 448 | <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest"> |
|---|
| 449 | <meta name="dct.issued" scheme="ISO8601" content="2013-01-02"> |
|---|
| 450 | <meta name="dct.abstract" content="This document describes SPDY, a protocol designed for low-latency transport of content over the World Wide Web. SPDY introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP-like RFC2616 semantics for compatibility with existing HTTP application servers."> |
|---|
| 451 | <meta name="description" content="This document describes SPDY, a protocol designed for low-latency transport of content over the World Wide Web. SPDY introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP-like RFC2616 semantics for compatibility with existing HTTP application servers."> |
|---|
| 452 | </head> |
|---|
| 453 | <body onload="init();"> |
|---|
| 454 | <table class="header"> |
|---|
| 455 | <tbody> |
|---|
| 456 | <tr> |
|---|
| 457 | <td class="left">HTTPbis Working Group</td> |
|---|
| 458 | <td class="right">M. Belshe</td> |
|---|
| 459 | </tr> |
|---|
| 460 | <tr> |
|---|
| 461 | <td class="left">Internet-Draft</td> |
|---|
| 462 | <td class="right">Twist</td> |
|---|
| 463 | </tr> |
|---|
| 464 | <tr> |
|---|
| 465 | <td class="left">Intended status: Informational</td> |
|---|
| 466 | <td class="right">R. Peon</td> |
|---|
| 467 | </tr> |
|---|
| 468 | <tr> |
|---|
| 469 | <td class="left">Expires: July 6, 2013</td> |
|---|
| 470 | <td class="right">Google, Inc</td> |
|---|
| 471 | </tr> |
|---|
| 472 | <tr> |
|---|
| 473 | <td class="left"></td> |
|---|
| 474 | <td class="right">M. Thomson, Editor</td> |
|---|
| 475 | </tr> |
|---|
| 476 | <tr> |
|---|
| 477 | <td class="left"></td> |
|---|
| 478 | <td class="right">Microsoft</td> |
|---|
| 479 | </tr> |
|---|
| 480 | <tr> |
|---|
| 481 | <td class="left"></td> |
|---|
| 482 | <td class="right">A. Melnikov, Editor</td> |
|---|
| 483 | </tr> |
|---|
| 484 | <tr> |
|---|
| 485 | <td class="left"></td> |
|---|
| 486 | <td class="right">Isode Ltd</td> |
|---|
| 487 | </tr> |
|---|
| 488 | <tr> |
|---|
| 489 | <td class="left"></td> |
|---|
| 490 | <td class="right">January 2, 2013</td> |
|---|
| 491 | </tr> |
|---|
| 492 | </tbody> |
|---|
| 493 | </table> |
|---|
| 494 | <p class="title">SPDY Protocol<br><span class="filename">draft-ietf-httpbis-http2-latest</span></p> |
|---|
| 495 | <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> |
|---|
| 496 | <p>This document describes SPDY, a protocol designed for low-latency transport of content over the World Wide Web. SPDY introduces |
|---|
| 497 | two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely |
|---|
| 498 | TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol |
|---|
| 499 | provides HTTP-like <a href="#RFC2616">RFC2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> semantics for compatibility with existing HTTP application servers. |
|---|
| 500 | </p> |
|---|
| 501 | <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> |
|---|
| 502 | <p>This draft is a work-in-progress, and does not yet reflect Working Group consensus.</p> |
|---|
| 503 | <p>This first draft uses the SPDY Protocol as a starting point, as per the Working Group's charter. Future drafts will add, remove |
|---|
| 504 | and change text, based upon the Working Group's decisions. |
|---|
| 505 | </p> |
|---|
| 506 | <p>Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at <<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>>. |
|---|
| 507 | </p> |
|---|
| 508 | <p>The current issues list is at <<a href="http://tools.ietf.org/wg/httpbis/trac/report/21">http://tools.ietf.org/wg/httpbis/trac/report/21</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. |
|---|
| 509 | </p> |
|---|
| 510 | <p>The changes in this draft are summarized in <a href="#changes.since.draft-ietf-httpbis-http2-00" title="Since draft-ietf-httpbis-http2-00">Appendix A.1</a>. |
|---|
| 511 | </p> |
|---|
| 512 | <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1> |
|---|
| 513 | <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p> |
|---|
| 514 | <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute |
|---|
| 515 | working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>. |
|---|
| 516 | </p> |
|---|
| 517 | <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other |
|---|
| 518 | documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work |
|---|
| 519 | in progress”. |
|---|
| 520 | </p> |
|---|
| 521 | <p>This Internet-Draft will expire on July 6, 2013.</p> |
|---|
| 522 | <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> |
|---|
| 523 | <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> |
|---|
| 524 | <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights |
|---|
| 525 | and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License |
|---|
| 526 | text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified |
|---|
| 527 | BSD License. |
|---|
| 528 | </p> |
|---|
| 529 | <hr class="noprint"> |
|---|
| 530 | <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> |
|---|
| 531 | <ul class="toc"> |
|---|
| 532 | <li><a href="#rfc.section.1">1.</a> <a href="#intro">Overview</a><ul> |
|---|
| 533 | <li><a href="#rfc.section.1.1">1.1</a> <a href="#rfc.section.1.1">Document Organization</a></li> |
|---|
| 534 | <li><a href="#rfc.section.1.2">1.2</a> <a href="#rfc.section.1.2">Definitions</a></li> |
|---|
| 535 | </ul> |
|---|
| 536 | </li> |
|---|
| 537 | <li><a href="#rfc.section.2">2.</a> <a href="#FramingLayer">SPDY Framing Layer</a><ul> |
|---|
| 538 | <li><a href="#rfc.section.2.1">2.1</a> <a href="#rfc.section.2.1">Session (Connections)</a></li> |
|---|
| 539 | <li><a href="#rfc.section.2.2">2.2</a> <a href="#rfc.section.2.2">Framing</a><ul> |
|---|
| 540 | <li><a href="#rfc.section.2.2.1">2.2.1</a> <a href="#ControlFrames">Control frames</a></li> |
|---|
| 541 | <li><a href="#rfc.section.2.2.2">2.2.2</a> <a href="#DataFrames">Data frames</a></li> |
|---|
| 542 | </ul> |
|---|
| 543 | </li> |
|---|
| 544 | <li><a href="#rfc.section.2.3">2.3</a> <a href="#rfc.section.2.3">Streams</a><ul> |
|---|
| 545 | <li><a href="#rfc.section.2.3.1">2.3.1</a> <a href="#StreamFrames">Stream frames</a></li> |
|---|
| 546 | <li><a href="#rfc.section.2.3.2">2.3.2</a> <a href="#StreamCreation">Stream creation</a><ul> |
|---|
| 547 | <li><a href="#rfc.section.2.3.2.1">2.3.2.1</a> <a href="#rfc.section.2.3.2.1">Unidirectional streams</a></li> |
|---|
| 548 | <li><a href="#rfc.section.2.3.2.2">2.3.2.2</a> <a href="#rfc.section.2.3.2.2">Bidirectional streams</a></li> |
|---|
| 549 | </ul> |
|---|
| 550 | </li> |
|---|
| 551 | <li><a href="#rfc.section.2.3.3">2.3.3</a> <a href="#StreamPriority">Stream priority</a></li> |
|---|
| 552 | <li><a href="#rfc.section.2.3.4">2.3.4</a> <a href="#rfc.section.2.3.4">Stream headers</a></li> |
|---|
| 553 | <li><a href="#rfc.section.2.3.5">2.3.5</a> <a href="#rfc.section.2.3.5">Stream data exchange</a></li> |
|---|
| 554 | <li><a href="#rfc.section.2.3.6">2.3.6</a> <a href="#StreamHalfClose">Stream half-close</a></li> |
|---|
| 555 | <li><a href="#rfc.section.2.3.7">2.3.7</a> <a href="#StreamClose">Stream close</a></li> |
|---|
| 556 | </ul> |
|---|
| 557 | </li> |
|---|
| 558 | <li><a href="#rfc.section.2.4">2.4</a> <a href="#rfc.section.2.4">Error Handling</a><ul> |
|---|
| 559 | <li><a href="#rfc.section.2.4.1">2.4.1</a> <a href="#SessionErrorHandler">Session Error Handling</a></li> |
|---|
| 560 | <li><a href="#rfc.section.2.4.2">2.4.2</a> <a href="#StreamErrorHandler">Stream Error Handling</a></li> |
|---|
| 561 | </ul> |
|---|
| 562 | </li> |
|---|
| 563 | <li><a href="#rfc.section.2.5">2.5</a> <a href="#rfc.section.2.5">Data flow</a></li> |
|---|
| 564 | <li><a href="#rfc.section.2.6">2.6</a> <a href="#rfc.section.2.6">Control frame types</a><ul> |
|---|
| 565 | <li><a href="#rfc.section.2.6.1">2.6.1</a> <a href="#SYN_STREAM">SYN_STREAM</a></li> |
|---|
| 566 | <li><a href="#rfc.section.2.6.2">2.6.2</a> <a href="#SYN_REPLY">SYN_REPLY</a></li> |
|---|
| 567 | <li><a href="#rfc.section.2.6.3">2.6.3</a> <a href="#RST_STREAM">RST_STREAM</a></li> |
|---|
| 568 | <li><a href="#rfc.section.2.6.4">2.6.4</a> <a href="#SETTINGS">SETTINGS</a></li> |
|---|
| 569 | <li><a href="#rfc.section.2.6.5">2.6.5</a> <a href="#PING">PING</a></li> |
|---|
| 570 | <li><a href="#rfc.section.2.6.6">2.6.6</a> <a href="#GOAWAY">GOAWAY</a></li> |
|---|
| 571 | <li><a href="#rfc.section.2.6.7">2.6.7</a> <a href="#HEADERS">HEADERS</a></li> |
|---|
| 572 | <li><a href="#rfc.section.2.6.8">2.6.8</a> <a href="#WINDOW_UPDATE">WINDOW_UPDATE</a></li> |
|---|
| 573 | <li><a href="#rfc.section.2.6.9">2.6.9</a> <a href="#CREDENTIAL">CREDENTIAL</a></li> |
|---|
| 574 | <li><a href="#rfc.section.2.6.10">2.6.10</a> <a href="#HeaderBlock">Name/Value Header Block</a><ul> |
|---|
| 575 | <li><a href="#rfc.section.2.6.10.1">2.6.10.1</a> <a href="#Compression">Compression</a></li> |
|---|
| 576 | </ul> |
|---|
| 577 | </li> |
|---|
| 578 | </ul> |
|---|
| 579 | </li> |
|---|
| 580 | </ul> |
|---|
| 581 | </li> |
|---|
| 582 | <li><a href="#rfc.section.3">3.</a> <a href="#HTTPLayer">HTTP Layering over SPDY</a><ul> |
|---|
| 583 | <li><a href="#rfc.section.3.1">3.1</a> <a href="#rfc.section.3.1">Connection Management</a><ul> |
|---|
| 584 | <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#rfc.section.3.1.1">Use of GOAWAY</a></li> |
|---|
| 585 | </ul> |
|---|
| 586 | </li> |
|---|
| 587 | <li><a href="#rfc.section.3.2">3.2</a> <a href="#rfc.section.3.2">HTTP Request/Response</a><ul> |
|---|
| 588 | <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#rfc.section.3.2.1">Request</a></li> |
|---|
| 589 | <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#rfc.section.3.2.2">Response</a></li> |
|---|
| 590 | <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#Authentication">Authentication</a><ul> |
|---|
| 591 | <li><a href="#rfc.section.3.2.3.1">3.2.3.1</a> <a href="#rfc.section.3.2.3.1">Stateless Authentication</a></li> |
|---|
| 592 | <li><a href="#rfc.section.3.2.3.2">3.2.3.2</a> <a href="#rfc.section.3.2.3.2">Stateful Authentication</a></li> |
|---|
| 593 | </ul> |
|---|
| 594 | </li> |
|---|
| 595 | </ul> |
|---|
| 596 | </li> |
|---|
| 597 | <li><a href="#rfc.section.3.3">3.3</a> <a href="#rfc.section.3.3">Server Push Transactions</a><ul> |
|---|
| 598 | <li><a href="#rfc.section.3.3.1">3.3.1</a> <a href="#rfc.section.3.3.1">Server implementation</a></li> |
|---|
| 599 | <li><a href="#rfc.section.3.3.2">3.3.2</a> <a href="#rfc.section.3.3.2">Client implementation</a></li> |
|---|
| 600 | </ul> |
|---|
| 601 | </li> |
|---|
| 602 | </ul> |
|---|
| 603 | </li> |
|---|
| 604 | <li><a href="#rfc.section.4">4.</a> <a href="#rfc.section.4">Design Rationale and Notes</a><ul> |
|---|
| 605 | <li><a href="#rfc.section.4.1">4.1</a> <a href="#rfc.section.4.1">Separation of Framing Layer and Application Layer</a></li> |
|---|
| 606 | <li><a href="#rfc.section.4.2">4.2</a> <a href="#rfc.section.4.2">Error handling - Framing Layer</a></li> |
|---|
| 607 | <li><a href="#rfc.section.4.3">4.3</a> <a href="#rfc.section.4.3">One Connection Per Domain</a></li> |
|---|
| 608 | <li><a href="#rfc.section.4.4">4.4</a> <a href="#rfc.section.4.4">Fixed vs Variable Length Fields</a></li> |
|---|
| 609 | <li><a href="#rfc.section.4.5">4.5</a> <a href="#rfc.section.4.5">Compression Context(s)</a></li> |
|---|
| 610 | <li><a href="#rfc.section.4.6">4.6</a> <a href="#rfc.section.4.6">Unidirectional streams</a></li> |
|---|
| 611 | <li><a href="#rfc.section.4.7">4.7</a> <a href="#rfc.section.4.7">Data Compression</a></li> |
|---|
| 612 | <li><a href="#rfc.section.4.8">4.8</a> <a href="#rfc.section.4.8">Server Push</a></li> |
|---|
| 613 | </ul> |
|---|
| 614 | </li> |
|---|
| 615 | <li><a href="#rfc.section.5">5.</a> <a href="#rfc.section.5">Security Considerations</a><ul> |
|---|
| 616 | <li><a href="#rfc.section.5.1">5.1</a> <a href="#rfc.section.5.1">Use of Same-origin constraints</a></li> |
|---|
| 617 | <li><a href="#rfc.section.5.2">5.2</a> <a href="#rfc.section.5.2">HTTP Headers and SPDY Headers</a></li> |
|---|
| 618 | <li><a href="#rfc.section.5.3">5.3</a> <a href="#rfc.section.5.3">Cross-Protocol Attacks</a></li> |
|---|
| 619 | <li><a href="#rfc.section.5.4">5.4</a> <a href="#rfc.section.5.4">Server Push Implicit Headers</a></li> |
|---|
| 620 | </ul> |
|---|
| 621 | </li> |
|---|
| 622 | <li><a href="#rfc.section.6">6.</a> <a href="#rfc.section.6">Privacy Considerations</a><ul> |
|---|
| 623 | <li><a href="#rfc.section.6.1">6.1</a> <a href="#rfc.section.6.1">Long Lived Connections</a></li> |
|---|
| 624 | <li><a href="#rfc.section.6.2">6.2</a> <a href="#rfc.section.6.2">SETTINGS frame</a></li> |
|---|
| 625 | </ul> |
|---|
| 626 | </li> |
|---|
| 627 | <li><a href="#rfc.section.7">7.</a> <a href="#rfc.section.7">Incompatibilities with SPDY draft #2</a></li> |
|---|
| 628 | <li><a href="#rfc.section.8">8.</a> <a href="#rfc.section.8">Requirements Notation</a></li> |
|---|
| 629 | <li><a href="#rfc.section.9">9.</a> <a href="#rfc.section.9">Acknowledgements</a></li> |
|---|
| 630 | <li><a href="#rfc.section.10">10.</a> <a href="#rfc.references">Normative References</a></li> |
|---|
| 631 | <li><a href="#rfc.authors">Authors' Addresses</a></li> |
|---|
| 632 | <li><a href="#rfc.section.A">A.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> |
|---|
| 633 | <li><a href="#rfc.section.A.1">A.1</a> <a href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></li> |
|---|
| 634 | <li><a href="#rfc.section.A.2">A.2</a> <a href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></li> |
|---|
| 635 | </ul> |
|---|
| 636 | </li> |
|---|
| 637 | <li><a href="#rfc.index">Index</a></li> |
|---|
| 638 | </ul> |
|---|
| 639 | <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="intro" href="#intro">Overview</a></h1> |
|---|
| 640 | <p id="rfc.section.1.p.1">One of the bottlenecks of HTTP implementations is that HTTP relies on multiple connections for concurrency. This causes several |
|---|
| 641 | problems, including additional round trips for connection setup, slow-start delays, and connection rationing by the client, |
|---|
| 642 | where it tries to avoid opening too many connections to any single server. HTTP pipelining helps some, but only achieves partial |
|---|
| 643 | multiplexing. In addition, pipelining has proven non-deployable in existing browsers due to intermediary interference. |
|---|
| 644 | </p> |
|---|
| 645 | <p id="rfc.section.1.p.2">SPDY adds a framing layer for multiplexing multiple, concurrent streams across a single TCP connection (or any reliable transport |
|---|
| 646 | stream). The framing layer is optimized for HTTP-like request-response streams, such that applications which run over HTTP |
|---|
| 647 | today can work over SPDY with little or no change on behalf of the web application writer. |
|---|
| 648 | </p> |
|---|
| 649 | <p id="rfc.section.1.p.3">The SPDY session offers four improvements over HTTP: </p> |
|---|
| 650 | <ul class="empty"> |
|---|
| 651 | <li>Multiplexed requests: There is no limit to the number of requests that can be issued concurrently over a single SPDY connection.</li> |
|---|
| 652 | <li>Prioritized requests: Clients can request certain resources to be delivered first. This avoids the problem of congesting the |
|---|
| 653 | network channel with non-critical resources when a high-priority request is pending. |
|---|
| 654 | </li> |
|---|
| 655 | <li>Compressed headers: Clients today send a significant amount of redundant data in the form of HTTP headers. Because a single |
|---|
| 656 | web page may require 50 or 100 subrequests, this data is significant. |
|---|
| 657 | </li> |
|---|
| 658 | <li>Server pushed streams: Server Push enables content to be pushed from servers to clients without a request.</li> |
|---|
| 659 | </ul> |
|---|
| 660 | <p id="rfc.section.1.p.4">SPDY attempts to preserve the existing semantics of HTTP. All features such as cookies, ETags, Vary headers, Content-Encoding |
|---|
| 661 | negotiations, etc work as they do with HTTP; SPDY only replaces the way the data is written to the network. |
|---|
| 662 | </p> |
|---|
| 663 | <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> Document Organization |
|---|
| 664 | </h2> |
|---|
| 665 | <p id="rfc.section.1.1.p.1">The SPDY Specification is split into two parts: a framing layer (<a href="#FramingLayer" title="SPDY Framing Layer">Section 2</a>), which multiplexes a TCP connection into independent, length-prefixed frames, and an HTTP layer (<a href="#HTTPLayer" title="HTTP Layering over SPDY">Section 3</a>), which specifies the mechanism for overlaying HTTP request/response pairs on top of the framing layer. While some of the |
|---|
| 666 | framing layer concepts are isolated from the HTTP layer, building a generic framing layer has not been a goal. The framing |
|---|
| 667 | layer is tailored to the needs of the HTTP protocol and server push. |
|---|
| 668 | </p> |
|---|
| 669 | <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> Definitions |
|---|
| 670 | </h2> |
|---|
| 671 | <p id="rfc.section.1.2.p.1"> </p> |
|---|
| 672 | <ul class="empty"> |
|---|
| 673 | <li>client: The endpoint initiating the SPDY session.</li> |
|---|
| 674 | <li>connection: A transport-level connection between two endpoints.</li> |
|---|
| 675 | <li>endpoint: Either the client or server of a connection.</li> |
|---|
| 676 | <li>frame: A header-prefixed sequence of bytes sent over a SPDY session.</li> |
|---|
| 677 | <li>server: The endpoint which did not initiate the SPDY session.</li> |
|---|
| 678 | <li>session: A synonym for a connection.</li> |
|---|
| 679 | <li>session error: An error on the SPDY session.</li> |
|---|
| 680 | <li>stream: A bi-directional flow of bytes across a virtual channel within a SPDY session.</li> |
|---|
| 681 | <li>stream error: An error on an individual SPDY stream.</li> |
|---|
| 682 | </ul> |
|---|
| 683 | <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="FramingLayer" href="#FramingLayer">SPDY Framing Layer</a></h1> |
|---|
| 684 | <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Session (Connections) |
|---|
| 685 | </h2> |
|---|
| 686 | <p id="rfc.section.2.1.p.1">The SPDY framing layer (or "session") runs atop a reliable transport layer such as <a href="#RFC0793">TCP</a> <cite title="Transmission Control Protocol" id="rfc.xref.RFC0793.1">[RFC0793]</cite>. The client is the TCP connection initiator. SPDY connections are persistent connections. |
|---|
| 687 | </p> |
|---|
| 688 | <p id="rfc.section.2.1.p.2">For best performance, it is expected that clients will not close open connections until the user navigates away from all web |
|---|
| 689 | pages referencing a connection, or until the server closes the connection. Servers are encouraged to leave connections open |
|---|
| 690 | for as long as possible, but can terminate idle connections if necessary. When either endpoint closes the transport-level |
|---|
| 691 | connection, it MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section 2.6.6</a>) frame so that the endpoints can reliably determine if requests finished before the close. |
|---|
| 692 | </p> |
|---|
| 693 | <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> Framing |
|---|
| 694 | </h2> |
|---|
| 695 | <p id="rfc.section.2.2.p.1">Once the connection is established, clients and servers exchange framed messages. There are two types of frames: control frames (<a href="#ControlFrames" title="Control frames">Section 2.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section 2.2.2</a>). Frames always have a common header which is 8 bytes in length. |
|---|
| 696 | </p> |
|---|
| 697 | <p id="rfc.section.2.2.p.2">The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version |
|---|
| 698 | number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried |
|---|
| 699 | after the common header. The simple header is designed to make reading and writing of frames easy. |
|---|
| 700 | </p> |
|---|
| 701 | <p id="rfc.section.2.2.p.3">All integer values, including length, version, and type, are in network byte order. SPDY does not enforce alignment of types |
|---|
| 702 | in dynamically sized frames. |
|---|
| 703 | </p> |
|---|
| 704 | <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="ControlFrames" href="#ControlFrames">Control frames</a></h3> |
|---|
| 705 | <div id="rfc.figure.u.1"></div> <pre>+----------------------------------+ |
|---|
| 706 | |C| Version(15bits) | Type(16bits) | |
|---|
| 707 | +----------------------------------+ |
|---|
| 708 | | Flags (8) | Length (24 bits) | |
|---|
| 709 | +----------------------------------+ |
|---|
| 710 | | Data | |
|---|
| 711 | +----------------------------------+ |
|---|
| 712 | </pre> <p id="rfc.section.2.2.1.p.2">Control bit: The 'C' bit is a single bit indicating if this is a control message. For control frames this value is always |
|---|
| 713 | 1. |
|---|
| 714 | </p> |
|---|
| 715 | <p id="rfc.section.2.2.1.p.3">Version: The version number of the SPDY protocol. This document describes SPDY version 3.</p> |
|---|
| 716 | <p id="rfc.section.2.2.1.p.4">Type: The type of control frame. See Control Frames for the complete list of control frames.</p> |
|---|
| 717 | <p id="rfc.section.2.2.1.p.5">Flags: Flags related to this frame. Flags for control frames and data frames are different.</p> |
|---|
| 718 | <p id="rfc.section.2.2.1.p.6">Length: An unsigned 24-bit value representing the number of bytes after the length field.</p> |
|---|
| 719 | <p id="rfc.section.2.2.1.p.7">Data: data associated with this control frame. The format and length of this data is controlled by the control frame type.</p> |
|---|
| 720 | <p id="rfc.section.2.2.1.p.8">Control frame processing requirements: </p> |
|---|
| 721 | <ul class="empty"> |
|---|
| 722 | <li>Note that full length control frames (16MB) can be large for implementations running on resource-limited hardware. In such |
|---|
| 723 | cases, implementations MAY limit the maximum length frame supported. However, all implementations MUST be able to receive |
|---|
| 724 | control frames of at least 8192 octets in length. |
|---|
| 725 | </li> |
|---|
| 726 | </ul> |
|---|
| 727 | <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> <a id="DataFrames" href="#DataFrames">Data frames</a></h3> |
|---|
| 728 | <div id="rfc.figure.u.2"></div> <pre>+----------------------------------+ |
|---|
| 729 | |C| Stream-ID (31bits) | |
|---|
| 730 | +----------------------------------+ |
|---|
| 731 | | Flags (8) | Length (24 bits) | |
|---|
| 732 | +----------------------------------+ |
|---|
| 733 | | Data | |
|---|
| 734 | +----------------------------------+ |
|---|
| 735 | </pre> <p id="rfc.section.2.2.2.p.2">Control bit: For data frames this value is always 0.</p> |
|---|
| 736 | <p id="rfc.section.2.2.2.p.3">Stream-ID: A 31-bit value identifying the stream.</p> |
|---|
| 737 | <p id="rfc.section.2.2.2.p.4">Flags: Flags related to this frame. Valid flags are: </p> |
|---|
| 738 | <ul class="empty"> |
|---|
| 739 | <li>0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream. See Stream Close (<a href="#StreamClose" title="Stream close">Section 2.3.7</a>) below. |
|---|
| 740 | </li> |
|---|
| 741 | <li>0x02 = FLAG_COMPRESS - indicates that the data in this frame has been compressed.</li> |
|---|
| 742 | </ul> |
|---|
| 743 | <p id="rfc.section.2.2.2.p.5">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a data frame is |
|---|
| 744 | 8 bytes + length. It is valid to have a zero-length data frame. |
|---|
| 745 | </p> |
|---|
| 746 | <p id="rfc.section.2.2.2.p.6">Data: The variable-length data payload; the length was defined in the length field.</p> |
|---|
| 747 | <p id="rfc.section.2.2.2.p.7">Data frame processing requirements: </p> |
|---|
| 748 | <ul class="empty"> |
|---|
| 749 | <li>If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section 2.6.6</a>) frame, it MUST send issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the error code INVALID_STREAM for the stream-id. |
|---|
| 750 | </li> |
|---|
| 751 | <li>If the endpoint which created the stream receives a data frame before receiving a SYN_REPLY on that stream, it is a protocol |
|---|
| 752 | error, and the recipient MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id. |
|---|
| 753 | </li> |
|---|
| 754 | <li>Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session.</li> |
|---|
| 755 | <li>All SPDY endpoints MUST accept compressed data frames. Compression of data frames is always done using zlib compression. Each |
|---|
| 756 | stream initializes and uses its own compression context dedicated to use within that stream. Endpoints are encouraged to use |
|---|
| 757 | application level compression rather than SPDY stream level compression. |
|---|
| 758 | </li> |
|---|
| 759 | <li>Each SPDY stream sending compressed frames creates its own zlib context for that stream, and these compression contexts MUST |
|---|
| 760 | be distinct from the compression contexts used with SYN_STREAM/SYN_REPLY/HEADER compression. (Thus, if both endpoints of a |
|---|
| 761 | stream are compressing data on the stream, there will be two zlib contexts, one for sending and one for receiving). |
|---|
| 762 | </li> |
|---|
| 763 | </ul> |
|---|
| 764 | <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Streams |
|---|
| 765 | </h2> |
|---|
| 766 | <p id="rfc.section.2.3.p.1">Streams are independent sequences of bi-directional data divided into frames with several properties: </p> |
|---|
| 767 | <ul class="empty"> |
|---|
| 768 | <li>Streams may be created by either the client or server.</li> |
|---|
| 769 | <li>Streams optionally carry a set of name/value header pairs.</li> |
|---|
| 770 | <li>Streams can concurrently send data interleaved with other streams.</li> |
|---|
| 771 | <li>Streams may be cancelled.</li> |
|---|
| 772 | </ul> |
|---|
| 773 | <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="StreamFrames" href="#StreamFrames">Stream frames</a></h3> |
|---|
| 774 | <p id="rfc.section.2.3.1.p.1">SPDY defines 3 control frames to manage the lifecycle of a stream: </p> |
|---|
| 775 | <ul class="empty"> |
|---|
| 776 | <li>SYN_STREAM - Open a new stream</li> |
|---|
| 777 | <li>SYN_REPLY - Remote acknowledgement of a new, open stream</li> |
|---|
| 778 | <li>RST_STREAM - Close a stream</li> |
|---|
| 779 | </ul> |
|---|
| 780 | <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="StreamCreation" href="#StreamCreation">Stream creation</a></h3> |
|---|
| 781 | <p id="rfc.section.2.3.2.p.1">A stream is created by sending a control frame with the type set to SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section 2.6.1</a>). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID |
|---|
| 782 | must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new streams |
|---|
| 783 | are created. E.g. Stream 2 may be created after stream 3, but stream 7 must not be created after stream 9. Stream IDs do not |
|---|
| 784 | wrap: when a client or server cannot create a new stream id without exceeding a 31 bit value, it MUST NOT create a new stream. |
|---|
| 785 | </p> |
|---|
| 786 | <p id="rfc.section.2.3.2.p.2">The stream-id MUST increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than |
|---|
| 787 | any previously received SYN_STREAM, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section 2.4.1</a>) with the status PROTOCOL_ERROR. |
|---|
| 788 | </p> |
|---|
| 789 | <p id="rfc.section.2.3.2.p.3">It is a protocol error to send two SYN_STREAMs with the same stream-id. If a recipient receives a second SYN_STREAM for the |
|---|
| 790 | same stream, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the status code PROTOCOL_ERROR. |
|---|
| 791 | </p> |
|---|
| 792 | <p id="rfc.section.2.3.2.p.4">Upon receipt of a SYN_STREAM, the recipient can reject the stream by sending a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the error code REFUSED_STREAM. Note, however, that the creating endpoint may have already sent additional frames for |
|---|
| 793 | that stream which cannot be immediately stopped. |
|---|
| 794 | </p> |
|---|
| 795 | <p id="rfc.section.2.3.2.p.5">Once the stream is created, the creator may immediately send HEADERS or DATA frames for that stream, without needing to wait |
|---|
| 796 | for the recipient to acknowledge. |
|---|
| 797 | </p> |
|---|
| 798 | <h4 id="rfc.section.2.3.2.1"><a href="#rfc.section.2.3.2.1">2.3.2.1</a> Unidirectional streams |
|---|
| 799 | </h4> |
|---|
| 800 | <p id="rfc.section.2.3.2.1.p.1">When an endpoint creates a stream with the FLAG_UNIDIRECTIONAL flag set, it creates a unidirectional stream which the creating |
|---|
| 801 | endpoint can use to send frames, but the receiving endpoint cannot. The receiving endpoint is implicitly already in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>) state. |
|---|
| 802 | </p> |
|---|
| 803 | <h4 id="rfc.section.2.3.2.2"><a href="#rfc.section.2.3.2.2">2.3.2.2</a> Bidirectional streams |
|---|
| 804 | </h4> |
|---|
| 805 | <p id="rfc.section.2.3.2.2.p.1">SYN_STREAM frames which do not use the FLAG_UNIDIRECTIONAL flag are bidirectional streams. Both endpoints can send data on |
|---|
| 806 | a bi-directional stream. |
|---|
| 807 | </p> |
|---|
| 808 | <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="StreamPriority" href="#StreamPriority">Stream priority</a></h3> |
|---|
| 809 | <p id="rfc.section.2.3.3.p.1">The creator of a stream assigns a priority for that stream. Priority is represented as an integer from 0 to 7. 0 represents |
|---|
| 810 | the highest priority and 7 represents the lowest priority. |
|---|
| 811 | </p> |
|---|
| 812 | <p id="rfc.section.2.3.3.p.2">The sender and recipient SHOULD use best-effort to process streams in the order of highest priority to lowest priority.</p> |
|---|
| 813 | <h3 id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4</a> Stream headers |
|---|
| 814 | </h3> |
|---|
| 815 | <p id="rfc.section.2.3.4.p.1">Streams carry optional sets of name/value pair headers which carry metadata about the stream. After the stream has been created, |
|---|
| 816 | and as long as the sender is not closed (<a href="#StreamClose" title="Stream close">Section 2.3.7</a>) or half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>), each side may send HEADERS frame(s) containing the header data. Header data can be sent in multiple HEADERS frames, and |
|---|
| 817 | HEADERS frames may be interleaved with data frames. |
|---|
| 818 | </p> |
|---|
| 819 | <h3 id="rfc.section.2.3.5"><a href="#rfc.section.2.3.5">2.3.5</a> Stream data exchange |
|---|
| 820 | </h3> |
|---|
| 821 | <p id="rfc.section.2.3.5.p.1">Once a stream is created, it can be used to send arbitrary amounts of data. Generally this means that a series of data frames |
|---|
| 822 | will be sent on the stream until a frame containing the FLAG_FIN flag is set. The FLAG_FIN can be set on a SYN_STREAM (<a href="#SYN_STREAM" title="SYN_STREAM">Section 2.6.1</a>), SYN_REPLY (<a href="#SYN_REPLY" title="SYN_REPLY">Section 2.6.2</a>), HEADERS (<a href="#HEADERS" title="HEADERS">Section 2.6.7</a>) or a DATA (<a href="#DataFrames" title="Data frames">Section 2.2.2</a>) frame. Once the FLAG_FIN has been sent, the stream is considered to be half-closed. |
|---|
| 823 | </p> |
|---|
| 824 | <h3 id="rfc.section.2.3.6"><a href="#rfc.section.2.3.6">2.3.6</a> <a id="StreamHalfClose" href="#StreamHalfClose">Stream half-close</a></h3> |
|---|
| 825 | <p id="rfc.section.2.3.6.p.1">When one side of the stream sends a frame with the FLAG_FIN flag set, the stream is half-closed from that endpoint. The sender |
|---|
| 826 | of the FLAG_FIN MUST NOT send further frames on that stream. When both sides have half-closed, the stream is closed. |
|---|
| 827 | </p> |
|---|
| 828 | <p id="rfc.section.2.3.6.p.2">If an endpoint receives a data frame after the stream is half-closed from the sender (e.g. the endpoint has already received |
|---|
| 829 | a prior frame for the stream with the FIN flag set), it MUST send a RST_STREAM to the sender with the status STREAM_ALREADY_CLOSED. |
|---|
| 830 | </p> |
|---|
| 831 | <h3 id="rfc.section.2.3.7"><a href="#rfc.section.2.3.7">2.3.7</a> <a id="StreamClose" href="#StreamClose">Stream close</a></h3> |
|---|
| 832 | <p id="rfc.section.2.3.7.p.1">There are 3 ways that streams can be terminated: </p> |
|---|
| 833 | <ul class="empty"> |
|---|
| 834 | <li>Normal termination: Normal stream termination occurs when both sender and recipient have half-closed the stream by sending |
|---|
| 835 | a FLAG_FIN. |
|---|
| 836 | </li> |
|---|
| 837 | <li>Abrupt termination: Either the client or server can send a RST_STREAM control frame at any time. A RST_STREAM contains an |
|---|
| 838 | error code to indicate the reason for failure. When a RST_STREAM is sent from the stream originator, it indicates a failure |
|---|
| 839 | to complete the stream and that no further data will be sent on the stream. When a RST_STREAM is sent from the stream recipient, |
|---|
| 840 | the sender, upon receipt, should stop sending any data on the stream. The stream recipient should be aware that there is a |
|---|
| 841 | race between data already in transit from the sender and the time the RST_STREAM is received. See Stream Error Handling (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) |
|---|
| 842 | </li> |
|---|
| 843 | <li>TCP connection teardown: If the TCP connection is torn down while un-closed streams exist, then the endpoint must assume that |
|---|
| 844 | the stream was abnormally interrupted and may be incomplete. |
|---|
| 845 | </li> |
|---|
| 846 | </ul> |
|---|
| 847 | <p id="rfc.section.2.3.7.p.2">If an endpoint receives a data frame after the stream is closed, it must send a RST_STREAM to the sender with the status PROTOCOL_ERROR.</p> |
|---|
| 848 | <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Error Handling |
|---|
| 849 | </h2> |
|---|
| 850 | <p id="rfc.section.2.4.p.1">The SPDY framing layer has only two types of errors, and they are always handled consistently. Any reference in this specification |
|---|
| 851 | to "issue a session error" refers to <a href="#SessionErrorHandler" title="Session Error Handling">Section 2.4.1</a>. Any reference to "issue a stream error" refers to <a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>. |
|---|
| 852 | </p> |
|---|
| 853 | <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="SessionErrorHandler" href="#SessionErrorHandler">Session Error Handling</a></h3> |
|---|
| 854 | <p id="rfc.section.2.4.1.p.1">A session error is any error which prevents further processing of the framing layer or which corrupts the session compression |
|---|
| 855 | state. When a session error occurs, the endpoint encountering the error MUST first send a GOAWAY (<a href="#GOAWAY" title="GOAWAY">Section 2.6.6</a>) frame with the stream id of most recently received stream from the remote endpoint, and the error code for why the session |
|---|
| 856 | is terminating. After sending the GOAWAY frame, the endpoint MUST close the TCP connection. |
|---|
| 857 | </p> |
|---|
| 858 | <p id="rfc.section.2.4.1.p.2">Note that the session compression state is dependent upon both endpoints always processing all compressed data. If an endpoint |
|---|
| 859 | partially processes a frame containing compressed data without updating compression state properly, future control frames |
|---|
| 860 | which use compression will be always be errored. Implementations SHOULD always try to process compressed data so that errors |
|---|
| 861 | which could be handled as stream errors do not become session errors. |
|---|
| 862 | </p> |
|---|
| 863 | <p id="rfc.section.2.4.1.p.3">Note that because this GOAWAY is sent during a session error case, it is possible that the GOAWAY will not be reliably received |
|---|
| 864 | by the receiving endpoint. It is a best-effort attempt to communicate with the remote about why the session is going down. |
|---|
| 865 | </p> |
|---|
| 866 | <h3 id="rfc.section.2.4.2"><a href="#rfc.section.2.4.2">2.4.2</a> <a id="StreamErrorHandler" href="#StreamErrorHandler">Stream Error Handling</a></h3> |
|---|
| 867 | <p id="rfc.section.2.4.2.p.1">A stream error is an error related to a specific stream-id which does not affect processing of other streams at the framing |
|---|
| 868 | layer. Upon a stream error, the endpoint MUST send a RST_STREAM (<a href="#RST_STREAM" title="RST_STREAM">Section 2.6.3</a>) frame which contains the stream id of the stream where the error occurred and the error status which caused the error. After |
|---|
| 869 | sending the RST_STREAM, the stream is closed to the sending endpoint. After sending the RST_STREAM, if the sender receives |
|---|
| 870 | any frames other than a RST_STREAM for that stream id, it will result in sending additional RST_STREAM frames. An endpoint |
|---|
| 871 | MUST NOT send a RST_STREAM in response to an RST_STREAM, as doing so would lead to RST_STREAM loops. Sending a RST_STREAM |
|---|
| 872 | does not cause the SPDY session to be closed. |
|---|
| 873 | </p> |
|---|
| 874 | <p id="rfc.section.2.4.2.p.2">If an endpoint has multiple RST_STREAM frames to send in succession for the same stream-id and the same error code, it MAY |
|---|
| 875 | coalesce them into a single RST_STREAM frame. (This can happen if a stream is closed, but the remote sends multiple data frames. |
|---|
| 876 | There is no reason to send a RST_STREAM for each frame in succession). |
|---|
| 877 | </p> |
|---|
| 878 | <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Data flow |
|---|
| 879 | </h2> |
|---|
| 880 | <p id="rfc.section.2.5.p.1">Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, clients and servers must |
|---|
| 881 | intelligently interleave data messages for concurrent sessions. |
|---|
| 882 | </p> |
|---|
| 883 | <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> Control frame types |
|---|
| 884 | </h2> |
|---|
| 885 | <h3 id="rfc.section.2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a> <a id="SYN_STREAM" href="#SYN_STREAM">SYN_STREAM</a></h3> |
|---|
| 886 | <p id="rfc.section.2.6.1.p.1">The SYN_STREAM control frame allows the sender to asynchronously create a stream between the endpoints. See Stream Creation (<a href="#StreamCreation" title="Stream creation">Section 2.3.2</a>) |
|---|
| 887 | </p> |
|---|
| 888 | <div id="rfc.figure.u.3"></div> <pre>+------------------------------------+ |
|---|
| 889 | |1| version | 1 | |
|---|
| 890 | +------------------------------------+ |
|---|
| 891 | | Flags (8) | Length (24 bits) | |
|---|
| 892 | +------------------------------------+ |
|---|
| 893 | |X| Stream-ID (31bits) | |
|---|
| 894 | +------------------------------------+ |
|---|
| 895 | |X| Associated-To-Stream-ID (31bits) | |
|---|
| 896 | +------------------------------------+ |
|---|
| 897 | | Pri|Unused | Slot | | |
|---|
| 898 | +-------------------+ | |
|---|
| 899 | | Number of Name/Value pairs (int32) | <+ |
|---|
| 900 | +------------------------------------+ | |
|---|
| 901 | | Length of name (int32) | | This section is the |
|---|
| 902 | +------------------------------------+ | "Name/Value Header |
|---|
| 903 | | Name (string) | | Block", and is |
|---|
| 904 | +------------------------------------+ | compressed. |
|---|
| 905 | | Length of value (int32) | | |
|---|
| 906 | +------------------------------------+ | |
|---|
| 907 | | Value (string) | | |
|---|
| 908 | +------------------------------------+ | |
|---|
| 909 | | (repeats) | <+ |
|---|
| 910 | </pre> <p id="rfc.section.2.6.1.p.3">Flags: Flags related to this frame. Valid flags are: </p> |
|---|
| 911 | <ul class="empty"> |
|---|
| 912 | <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>) state. |
|---|
| 913 | </li> |
|---|
| 914 | <li>0x02 = FLAG_UNIDIRECTIONAL - a stream created with this flag puts the recipient in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>) state. |
|---|
| 915 | </li> |
|---|
| 916 | </ul> |
|---|
| 917 | <p id="rfc.section.2.6.1.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_STREAM frames, this is 10 bytes |
|---|
| 918 | plus the length of the compressed Name/Value block. |
|---|
| 919 | </p> |
|---|
| 920 | <p id="rfc.section.2.6.1.p.5">Stream-ID: The 31-bit identifier for this stream. This stream-id will be used in frames which are part of this stream.</p> |
|---|
| 921 | <p id="rfc.section.2.6.1.p.6">Associated-To-Stream-ID: The 31-bit identifier for a stream which this stream is associated to. If this stream is independent |
|---|
| 922 | of all other streams, it should be 0. |
|---|
| 923 | </p> |
|---|
| 924 | <p id="rfc.section.2.6.1.p.7">Priority: A 3-bit priority (<a href="#StreamPriority" title="Stream priority">Section 2.3.3</a>) field. |
|---|
| 925 | </p> |
|---|
| 926 | <p id="rfc.section.2.6.1.p.8">Unused: 5 bits of unused space, reserved for future use.</p> |
|---|
| 927 | <p id="rfc.section.2.6.1.p.9">Slot: An 8 bit unsigned integer specifying the index in the server's CREDENTIAL vector of the client certificate to be used |
|---|
| 928 | for this request. see CREDENTIAL frame (<a href="#CREDENTIAL" title="CREDENTIAL">Section 2.6.9</a>). The value 0 means no client certificate should be associated with this stream. |
|---|
| 929 | </p> |
|---|
| 930 | <p id="rfc.section.2.6.1.p.10">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section 2.6.10</a>). |
|---|
| 931 | </p> |
|---|
| 932 | <p id="rfc.section.2.6.1.p.11">If an endpoint receives a SYN_STREAM which is larger than the implementation supports, it MAY send a RST_STREAM with error |
|---|
| 933 | code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section 2.2.1</a>). |
|---|
| 934 | </p> |
|---|
| 935 | <h3 id="rfc.section.2.6.2"><a href="#rfc.section.2.6.2">2.6.2</a> <a id="SYN_REPLY" href="#SYN_REPLY">SYN_REPLY</a></h3> |
|---|
| 936 | <p id="rfc.section.2.6.2.p.1">SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame.</p> |
|---|
| 937 | <div id="rfc.figure.u.4"></div> <pre>+------------------------------------+ |
|---|
| 938 | |1| version | 2 | |
|---|
| 939 | +------------------------------------+ |
|---|
| 940 | | Flags (8) | Length (24 bits) | |
|---|
| 941 | +------------------------------------+ |
|---|
| 942 | |X| Stream-ID (31bits) | |
|---|
| 943 | +------------------------------------+ |
|---|
| 944 | | Number of Name/Value pairs (int32) | <+ |
|---|
| 945 | +------------------------------------+ | |
|---|
| 946 | | Length of name (int32) | | This section is the |
|---|
| 947 | +------------------------------------+ | "Name/Value Header |
|---|
| 948 | | Name (string) | | Block", and is |
|---|
| 949 | +------------------------------------+ | compressed. |
|---|
| 950 | | Length of value (int32) | | |
|---|
| 951 | +------------------------------------+ | |
|---|
| 952 | | Value (string) | | |
|---|
| 953 | +------------------------------------+ | |
|---|
| 954 | | (repeats) | <+ |
|---|
| 955 | </pre> <p id="rfc.section.2.6.2.p.3">Flags: Flags related to this frame. Valid flags are: </p> |
|---|
| 956 | <ul class="empty"> |
|---|
| 957 | <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>) state. |
|---|
| 958 | </li> |
|---|
| 959 | </ul> |
|---|
| 960 | <p id="rfc.section.2.6.2.p.4">Length: The length is the number of bytes which follow the length field in the frame. For SYN_REPLY frames, this is 4 bytes |
|---|
| 961 | plus the length of the compressed Name/Value block. |
|---|
| 962 | </p> |
|---|
| 963 | <p id="rfc.section.2.6.2.p.5">Stream-ID: The 31-bit identifier for this stream.</p> |
|---|
| 964 | <p id="rfc.section.2.6.2.p.6">If an endpoint receives multiple SYN_REPLY frames for the same active stream ID, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the error code STREAM_IN_USE. |
|---|
| 965 | </p> |
|---|
| 966 | <p id="rfc.section.2.6.2.p.7">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section 2.6.10</a>). |
|---|
| 967 | </p> |
|---|
| 968 | <p id="rfc.section.2.6.2.p.8">If an endpoint receives a SYN_REPLY which is larger than the implementation supports, it MAY send a RST_STREAM with error |
|---|
| 969 | code FRAME_TOO_LARGE. All implementations MUST support the minimum size limits defined in the Control Frames section (<a href="#ControlFrames" title="Control frames">Section 2.2.1</a>). |
|---|
| 970 | </p> |
|---|
| 971 | <h3 id="rfc.section.2.6.3"><a href="#rfc.section.2.6.3">2.6.3</a> <a id="RST_STREAM" href="#RST_STREAM">RST_STREAM</a></h3> |
|---|
| 972 | <p id="rfc.section.2.6.3.p.1">The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator |
|---|
| 973 | wishes to cancel the stream. When sent by the recipient of a stream, it indicates an error or that the recipient did not want |
|---|
| 974 | to accept the stream, so the stream should be closed. |
|---|
| 975 | </p> |
|---|
| 976 | <div id="rfc.figure.u.5"></div> <pre>+----------------------------------+ |
|---|
| 977 | |1| version | 3 | |
|---|
| 978 | +----------------------------------+ |
|---|
| 979 | | Flags (8) | 8 | |
|---|
| 980 | +----------------------------------+ |
|---|
| 981 | |X| Stream-ID (31bits) | |
|---|
| 982 | +----------------------------------+ |
|---|
| 983 | | Status code | |
|---|
| 984 | +----------------------------------+ |
|---|
| 985 | </pre> <p id="rfc.section.2.6.3.p.3">Flags: Flags related to this frame. RST_STREAM does not define any flags. This value must be 0.</p> |
|---|
| 986 | <p id="rfc.section.2.6.3.p.4">Length: An unsigned 24-bit value representing the number of bytes after the length field. For RST_STREAM control frames, this |
|---|
| 987 | value is always 8. |
|---|
| 988 | </p> |
|---|
| 989 | <p id="rfc.section.2.6.3.p.5">Stream-ID: The 31-bit identifier for this stream.</p> |
|---|
| 990 | <p id="rfc.section.2.6.3.p.6">Status code: (32 bits) An indicator for why the stream is being terminated.The following status codes are defined: </p> |
|---|
| 991 | <ul class="empty"> |
|---|
| 992 | <li>1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available.</li> |
|---|
| 993 | <li>2 - INVALID_STREAM. This is returned when a frame is received for a stream which is not active.</li> |
|---|
| 994 | <li>3 - REFUSED_STREAM. Indicates that the stream was refused before any processing has been done on the stream.</li> |
|---|
| 995 | <li>4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream does not support the SPDY version requested.</li> |
|---|
| 996 | <li>5 - CANCEL. Used by the creator of a stream to indicate that the stream is no longer needed.</li> |
|---|
| 997 | <li>6 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything |
|---|
| 998 | in the protocol. |
|---|
| 999 | </li> |
|---|
| 1000 | <li>7 - FLOW_CONTROL_ERROR. The endpoint detected that its peer violated the flow control protocol.</li> |
|---|
| 1001 | <li>8 - STREAM_IN_USE. The endpoint received a SYN_REPLY for a stream already open.</li> |
|---|
| 1002 | <li>9 - STREAM_ALREADY_CLOSED. The endpoint received a data or SYN_REPLY frame for a stream which is half closed.</li> |
|---|
| 1003 | <li>10 - INVALID_CREDENTIALS. The server received a request for a resource whose origin does not have valid credentials in the |
|---|
| 1004 | client certificate vector. |
|---|
| 1005 | </li> |
|---|
| 1006 | <li>11 - FRAME_TOO_LARGE. The endpoint received a frame which this implementation could not support. If FRAME_TOO_LARGE is sent |
|---|
| 1007 | for a SYN_STREAM, HEADERS, or SYN_REPLY frame without fully processing the compressed portion of those frames, then the compression |
|---|
| 1008 | state will be out-of-sync with the other endpoint. In this case, senders of FRAME_TOO_LARGE MUST close the session. |
|---|
| 1009 | </li> |
|---|
| 1010 | <li>Note: 0 is not a valid status code for a RST_STREAM.</li> |
|---|
| 1011 | </ul> |
|---|
| 1012 | <p id="rfc.section.2.6.3.p.7">After receiving a RST_STREAM on a stream, the recipient must not send additional frames for that stream, and the stream moves |
|---|
| 1013 | into the closed state. |
|---|
| 1014 | </p> |
|---|
| 1015 | <h3 id="rfc.section.2.6.4"><a href="#rfc.section.2.6.4">2.6.4</a> <a id="SETTINGS" href="#SETTINGS">SETTINGS</a></h3> |
|---|
| 1016 | <p id="rfc.section.2.6.4.p.1">A SETTINGS frame contains a set of id/value pairs for communicating configuration data about how the two endpoints may communicate. |
|---|
| 1017 | SETTINGS frames can be sent at any time by either endpoint, are optionally sent, and are fully asynchronous. When the server |
|---|
| 1018 | is the sender, the sender can request that configuration data be persisted by the client across SPDY sessions and returned |
|---|
| 1019 | to the server in future communications. |
|---|
| 1020 | </p> |
|---|
| 1021 | <p id="rfc.section.2.6.4.p.2">Persistence of SETTINGS ID/Value pairs is done on a per origin/IP pair (the "origin" is the set of scheme, host, and port |
|---|
| 1022 | from the URI. See <a href="#RFC6454" id="rfc.xref.RFC6454.1"><cite title="The Web Origin Concept">[RFC6454]</cite></a>). That is, when a client connects to a server, and the server persists settings within the client, the client SHOULD return |
|---|
| 1023 | the persisted settings on future connections to the same origin AND IP address and TCP port. Clients MUST NOT request servers |
|---|
| 1024 | to use the persistence features of the SETTINGS frames, and servers MUST ignore persistence related flags sent by a client. |
|---|
| 1025 | </p> |
|---|
| 1026 | <div id="rfc.figure.u.6"></div> <pre>+----------------------------------+ |
|---|
| 1027 | |1| version | 4 | |
|---|
| 1028 | +----------------------------------+ |
|---|
| 1029 | | Flags (8) | Length (24 bits) | |
|---|
| 1030 | +----------------------------------+ |
|---|
| 1031 | | Number of entries | |
|---|
| 1032 | +----------------------------------+ |
|---|
| 1033 | | ID/Value Pairs | |
|---|
| 1034 | | ... | |
|---|
| 1035 | </pre> <p id="rfc.section.2.6.4.p.4">Control bit: The control bit is always 1 for this message.</p> |
|---|
| 1036 | <p id="rfc.section.2.6.4.p.5">Version: The SPDY version number.</p> |
|---|
| 1037 | <p id="rfc.section.2.6.4.p.6">Type: The message type for a SETTINGS message is 4.</p> |
|---|
| 1038 | <p id="rfc.section.2.6.4.p.7">Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client should clear any previously persisted SETTINGS ID/Value pairs. |
|---|
| 1039 | If this frame contains ID/Value pairs with the FLAG_SETTINGS_PERSIST_VALUE set, then the client will first clear its existing, |
|---|
| 1040 | persisted settings, and then persist the values with the flag set which are contained within this frame. Because persistence |
|---|
| 1041 | is only implemented on the client, this flag can only be used when the sender is the server. |
|---|
| 1042 | </p> |
|---|
| 1043 | <p id="rfc.section.2.6.4.p.8">Length: An unsigned 24-bit value representing the number of bytes after the length field. The total size of a SETTINGS frame |
|---|
| 1044 | is 8 bytes + length. |
|---|
| 1045 | </p> |
|---|
| 1046 | <p id="rfc.section.2.6.4.p.9">Number of entries: A 32-bit value representing the number of ID/value pairs in this message.</p> |
|---|
| 1047 | <p id="rfc.section.2.6.4.p.10">ID: A 32-bit ID number, comprised of 8 bits of flags and 24 bits of unique ID. </p> |
|---|
| 1048 | <ul class="empty"> |
|---|
| 1049 | <li>ID.flags: |
|---|
| 1050 | <ul class="empty"> |
|---|
| 1051 | <li>FLAG_SETTINGS_PERSIST_VALUE (0x1): When set, the sender of this SETTINGS frame is requesting that the recipient persist the |
|---|
| 1052 | ID/Value and return it in future SETTINGS frames sent from the sender to this recipient. Because persistence is only implemented |
|---|
| 1053 | on the client, this flag is only sent by the server. |
|---|
| 1054 | </li> |
|---|
| 1055 | <li>FLAG_SETTINGS_PERSISTED (0x2): When set, the sender is notifying the recipient that this ID/Value pair was previously sent |
|---|
| 1056 | to the sender by the recipient with the FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it. Because persistence is |
|---|
| 1057 | only implemented on the client, this flag is only sent by the client. |
|---|
| 1058 | </li> |
|---|
| 1059 | </ul> |
|---|
| 1060 | </li> |
|---|
| 1061 | <li>Defined IDs: |
|---|
| 1062 | <ul class="empty"> |
|---|
| 1063 | <li>1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its expected upload bandwidth on this channel. This number is an estimate. |
|---|
| 1064 | The value should be the integral number of kilobytes per second that the sender predicts as an expected maximum upload channel |
|---|
| 1065 | capacity. |
|---|
| 1066 | </li> |
|---|
| 1067 | <li>2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its expected download bandwidth on this channel. This number is |
|---|
| 1068 | an estimate. The value should be the integral number of kilobytes per second that the sender predicts as an expected maximum |
|---|
| 1069 | download channel capacity. |
|---|
| 1070 | </li> |
|---|
| 1071 | <li>3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its expected round-trip-time on this channel. The round trip time is |
|---|
| 1072 | defined as the minimum amount of time to send a control frame from this client to the remote and receive a response. The value |
|---|
| 1073 | is represented in milliseconds. |
|---|
| 1074 | </li> |
|---|
| 1075 | <li>4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams |
|---|
| 1076 | which it will allow. By default there is no limit. For implementors it is recommended that this value be no smaller than 100. |
|---|
| 1077 | </li> |
|---|
| 1078 | <li>5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.</li> |
|---|
| 1079 | <li>6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform the remote endpoint the retransmission rate (bytes retransmitted |
|---|
| 1080 | / total bytes transmitted). |
|---|
| 1081 | </li> |
|---|
| 1082 | <li>7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform the remote endpoint the initial window size (in bytes) for new |
|---|
| 1083 | streams. |
|---|
| 1084 | </li> |
|---|
| 1085 | <li>8 - SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE allows the server to inform the client if the new size of the client certificate |
|---|
| 1086 | vector. |
|---|
| 1087 | </li> |
|---|
| 1088 | </ul> |
|---|
| 1089 | </li> |
|---|
| 1090 | </ul> |
|---|
| 1091 | <p id="rfc.section.2.6.4.p.11">Value: A 32-bit value.</p> |
|---|
| 1092 | <p id="rfc.section.2.6.4.p.12">The message is intentionally extensible for future information which may improve client-server communications. The sender |
|---|
| 1093 | does not need to send every type of ID/value. It must only send those for which it has accurate values to convey. When multiple |
|---|
| 1094 | ID/value pairs are sent, they should be sent in order of lowest id to highest id. A single SETTINGS frame MUST not contain |
|---|
| 1095 | multiple values for the same ID. If the recipient of a SETTINGS frame discovers multiple values for the same ID, it MUST ignore |
|---|
| 1096 | all values except the first one. |
|---|
| 1097 | </p> |
|---|
| 1098 | <p id="rfc.section.2.6.4.p.13">A server may send multiple SETTINGS frames containing different ID/Value pairs. When the same ID/Value is sent twice, the |
|---|
| 1099 | most recent value overrides any previously sent values. If the server sends IDs 1, 2, and 3 with the FLAG_SETTINGS_PERSIST_VALUE |
|---|
| 1100 | in a first SETTINGS frame, and then sends IDs 4 and 5 with the FLAG_SETTINGS_PERSIST_VALUE, when the client returns the persisted |
|---|
| 1101 | state on its next SETTINGS frame, it SHOULD send all 5 settings (1, 2, 3, 4, and 5 in this example) to the server. |
|---|
| 1102 | </p> |
|---|
| 1103 | <h3 id="rfc.section.2.6.5"><a href="#rfc.section.2.6.5">2.6.5</a> <a id="PING" href="#PING">PING</a></h3> |
|---|
| 1104 | <p id="rfc.section.2.6.5.p.1">The PING control frame is a mechanism for measuring a minimal round-trip time from the sender. It can be sent from the client |
|---|
| 1105 | or the server. Recipients of a PING frame should send an identical frame to the sender as soon as possible (if there is other |
|---|
| 1106 | pending data waiting to be sent, PING should take highest priority). Each ping sent by a sender should use a unique ID. |
|---|
| 1107 | </p> |
|---|
| 1108 | <div id="rfc.figure.u.7"></div> <pre>+----------------------------------+ |
|---|
| 1109 | |1| version | 6 | |
|---|
| 1110 | +----------------------------------+ |
|---|
| 1111 | | 0 (flags) | 4 (length) | |
|---|
| 1112 | +----------------------------------| |
|---|
| 1113 | | 32-bit ID | |
|---|
| 1114 | +----------------------------------+ |
|---|
| 1115 | </pre> <p id="rfc.section.2.6.5.p.3">Control bit: The control bit is always 1 for this message.</p> |
|---|
| 1116 | <p id="rfc.section.2.6.5.p.4">Version: The SPDY version number.</p> |
|---|
| 1117 | <p id="rfc.section.2.6.5.p.5">Type: The message type for a PING message is 6.</p> |
|---|
| 1118 | <p id="rfc.section.2.6.5.p.6">Length: This frame is always 4 bytes long.</p> |
|---|
| 1119 | <p id="rfc.section.2.6.5.p.7">ID: A unique ID for this ping, represented as an unsigned 32 bit value. When the client initiates a ping, it must use an odd |
|---|
| 1120 | numbered ID. When the server initiates a ping, it must use an even numbered ping. Use of odd/even IDs is required in order |
|---|
| 1121 | to avoid accidental looping on PINGs (where each side initiates an identical PING at the same time). |
|---|
| 1122 | </p> |
|---|
| 1123 | <p id="rfc.section.2.6.5.p.8">Note: If a sender uses all possible PING ids (e.g. has sent all 2^31 possible IDs), it can wrap and start re-using IDs.</p> |
|---|
| 1124 | <p id="rfc.section.2.6.5.p.9">If a server receives an even numbered PING which it did not initiate, it must ignore the PING. If a client receives an odd |
|---|
| 1125 | numbered PING which it did not initiate, it must ignore the PING. |
|---|
| 1126 | </p> |
|---|
| 1127 | <h3 id="rfc.section.2.6.6"><a href="#rfc.section.2.6.6">2.6.6</a> <a id="GOAWAY" href="#GOAWAY">GOAWAY</a></h3> |
|---|
| 1128 | <p id="rfc.section.2.6.6.p.1">The GOAWAY control frame is a mechanism to tell the remote side of the connection to stop creating streams on this session. |
|---|
| 1129 | It can be sent from the client or the server. Once sent, the sender will not respond to any new SYN_STREAMs on this session. |
|---|
| 1130 | Recipients of a GOAWAY frame must not send additional streams on this session, although a new session can be established for |
|---|
| 1131 | new streams. The purpose of this message is to allow an endpoint to gracefully stop accepting new streams (perhaps for a reboot |
|---|
| 1132 | or maintenance), while still finishing processing of previously established streams. |
|---|
| 1133 | </p> |
|---|
| 1134 | <p id="rfc.section.2.6.6.p.2">There is an inherent race condition between an endpoint sending SYN_STREAMs and the remote sending a GOAWAY message. To deal |
|---|
| 1135 | with this case, the GOAWAY contains a last-stream-id indicating the stream-id of the last stream which was created on the |
|---|
| 1136 | sending endpoint in this session. If the receiver of the GOAWAY sent new SYN_STREAMs for sessions after this last-stream-id, |
|---|
| 1137 | they were not processed by the server and the receiver may treat the stream as though it had never been created at all (hence |
|---|
| 1138 | the receiver may want to re-create the stream later on a new session). |
|---|
| 1139 | </p> |
|---|
| 1140 | <p id="rfc.section.2.6.6.p.3">Endpoints should always send a GOAWAY message before closing a connection so that the remote can know whether a stream has |
|---|
| 1141 | been partially processed or not. (For example, if an HTTP client sends a POST at the same time that a server closes a connection, |
|---|
| 1142 | the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate |
|---|
| 1143 | where it stopped working). |
|---|
| 1144 | </p> |
|---|
| 1145 | <p id="rfc.section.2.6.6.p.4">After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams.</p> |
|---|
| 1146 | <div id="rfc.figure.u.8"></div> <pre>+----------------------------------+ |
|---|
| 1147 | |1| version | 7 | |
|---|
| 1148 | +----------------------------------+ |
|---|
| 1149 | | 0 (flags) | 8 (length) | |
|---|
| 1150 | +----------------------------------| |
|---|
| 1151 | |X| Last-good-stream-ID (31 bits) | |
|---|
| 1152 | +----------------------------------+ |
|---|
| 1153 | | Status code | |
|---|
| 1154 | +----------------------------------+ |
|---|
| 1155 | </pre> <p id="rfc.section.2.6.6.p.6">Control bit: The control bit is always 1 for this message.</p> |
|---|
| 1156 | <p id="rfc.section.2.6.6.p.7">Version: The SPDY version number.</p> |
|---|
| 1157 | <p id="rfc.section.2.6.6.p.8">Type: The message type for a GOAWAY message is 7.</p> |
|---|
| 1158 | <p id="rfc.section.2.6.6.p.9">Length: This frame is always 8 bytes long.</p> |
|---|
| 1159 | <p id="rfc.section.2.6.6.p.10">Last-good-stream-Id: The last stream id which was replied to (with either a SYN_REPLY or RST_STREAM) by the sender of the |
|---|
| 1160 | GOAWAY message. If no streams were replied to, this value MUST be 0. |
|---|
| 1161 | </p> |
|---|
| 1162 | <p id="rfc.section.2.6.6.p.11">Status: The reason for closing the session. </p> |
|---|
| 1163 | <ul class="empty"> |
|---|
| 1164 | <li>0 - OK. This is a normal session teardown.</li> |
|---|
| 1165 | <li>1 - PROTOCOL_ERROR. This is a generic error, and should only be used if a more specific error is not available.</li> |
|---|
| 1166 | <li>11 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything |
|---|
| 1167 | in the protocol. |
|---|
| 1168 | </li> |
|---|
| 1169 | </ul> |
|---|
| 1170 | <h3 id="rfc.section.2.6.7"><a href="#rfc.section.2.6.7">2.6.7</a> <a id="HEADERS" href="#HEADERS">HEADERS</a></h3> |
|---|
| 1171 | <p id="rfc.section.2.6.7.p.1">The HEADERS frame augments a stream with additional headers. It may be optionally sent on an existing stream at any time. |
|---|
| 1172 | Specific application of the headers in this frame is application-dependent. The name/value header block within this frame |
|---|
| 1173 | is compressed. |
|---|
| 1174 | </p> |
|---|
| 1175 | <div id="rfc.figure.u.9"></div> <pre>+------------------------------------+ |
|---|
| 1176 | |1| version | 8 | |
|---|
| 1177 | +------------------------------------+ |
|---|
| 1178 | | Flags (8) | Length (24 bits) | |
|---|
| 1179 | +------------------------------------+ |
|---|
| 1180 | |X| Stream-ID (31bits) | |
|---|
| 1181 | +------------------------------------+ |
|---|
| 1182 | | Number of Name/Value pairs (int32) | <+ |
|---|
| 1183 | +------------------------------------+ | |
|---|
| 1184 | | Length of name (int32) | | This section is the |
|---|
| 1185 | +------------------------------------+ | "Name/Value Header |
|---|
| 1186 | | Name (string) | | Block", and is |
|---|
| 1187 | +------------------------------------+ | compressed. |
|---|
| 1188 | | Length of value (int32) | | |
|---|
| 1189 | +------------------------------------+ | |
|---|
| 1190 | | Value (string) | | |
|---|
| 1191 | +------------------------------------+ | |
|---|
| 1192 | | (repeats) | <+ |
|---|
| 1193 | </pre> <p id="rfc.section.2.6.7.p.3">Flags: Flags related to this frame. Valid flags are: </p> |
|---|
| 1194 | <ul class="empty"> |
|---|
| 1195 | <li>0x01 = FLAG_FIN - marks this frame as the last frame to be transmitted on this stream and puts the sender in the half-closed (<a href="#StreamHalfClose" title="Stream half-close">Section 2.3.6</a>) state. |
|---|
| 1196 | </li> |
|---|
| 1197 | </ul> |
|---|
| 1198 | <p id="rfc.section.2.6.7.p.4">Length: An unsigned 24 bit value representing the number of bytes after the length field. The minimum length of the length |
|---|
| 1199 | field is 4 (when the number of name value pairs is 0). |
|---|
| 1200 | </p> |
|---|
| 1201 | <p id="rfc.section.2.6.7.p.5">Stream-ID: The stream this HEADERS block is associated with.</p> |
|---|
| 1202 | <p id="rfc.section.2.6.7.p.6">Name/Value Header Block: A set of name/value pairs carried as part of the SYN_STREAM. see Name/Value Header Block (<a href="#HeaderBlock" title="Name/Value Header Block">Section 2.6.10</a>). |
|---|
| 1203 | </p> |
|---|
| 1204 | <h3 id="rfc.section.2.6.8"><a href="#rfc.section.2.6.8">2.6.8</a> <a id="WINDOW_UPDATE" href="#WINDOW_UPDATE">WINDOW_UPDATE</a></h3> |
|---|
| 1205 | <p id="rfc.section.2.6.8.p.1">The WINDOW_UPDATE control frame is used to implement per stream flow control in SPDY. Flow control in SPDY is per hop, that |
|---|
| 1206 | is, only between the two endpoints of a SPDY connection. If there are one or more intermediaries between the client and the |
|---|
| 1207 | origin server, flow control signals are not explicitly forwarded by the intermediaries. (However, throttling of data transfer |
|---|
| 1208 | by any recipient may have the effect of indirectly propagating flow control information upstream back to the original sender.) |
|---|
| 1209 | Flow control only applies to the data portion of data frames. Recipients must buffer all control frames. If a recipient fails |
|---|
| 1210 | to buffer an entire control frame, it MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the status code FLOW_CONTROL_ERROR for the stream. |
|---|
| 1211 | </p> |
|---|
| 1212 | <p id="rfc.section.2.6.8.p.2">Flow control in SPDY is implemented by a data transfer window kept by the sender of each stream. The data transfer window |
|---|
| 1213 | is a simple uint32 that indicates how many bytes of data the sender can transmit. After a stream is created, but before any |
|---|
| 1214 | data frames have been transmitted, the sender begins with the initial window size. This window size is a measure of the buffering |
|---|
| 1215 | capability of the recipient. The sender must not send a data frame with data length greater than the transfer window size. |
|---|
| 1216 | After sending each data frame, the sender decrements its transfer window size by the amount of data transmitted. When the |
|---|
| 1217 | window size becomes less than or equal to 0, the sender must pause transmitting data frames. At the other end of the stream, |
|---|
| 1218 | the recipient sends a WINDOW_UPDATE control back to notify the sender that it has consumed some data and freed up buffer space |
|---|
| 1219 | to receive more data. |
|---|
| 1220 | </p> |
|---|
| 1221 | <div id="rfc.figure.u.10"></div> <pre>+----------------------------------+ |
|---|
| 1222 | |1| version | 9 | |
|---|
| 1223 | +----------------------------------+ |
|---|
| 1224 | | 0 (flags) | 8 (length) | |
|---|
| 1225 | +----------------------------------+ |
|---|
| 1226 | |X| Stream-ID (31-bits) | |
|---|
| 1227 | +----------------------------------+ |
|---|
| 1228 | |X| Delta-Window-Size (31-bits) | |
|---|
| 1229 | +----------------------------------+ |
|---|
| 1230 | </pre> <p id="rfc.section.2.6.8.p.4">Control bit: The control bit is always 1 for this message.</p> |
|---|
| 1231 | <p id="rfc.section.2.6.8.p.5">Version: The SPDY version number.</p> |
|---|
| 1232 | <p id="rfc.section.2.6.8.p.6">Type: The message type for a WINDOW_UPDATE message is 9.</p> |
|---|
| 1233 | <p id="rfc.section.2.6.8.p.7">Length: The length field is always 8 for this frame (there are 8 bytes after the length field).</p> |
|---|
| 1234 | <p id="rfc.section.2.6.8.p.8">Stream-ID: The stream ID that this WINDOW_UPDATE control frame is for.</p> |
|---|
| 1235 | <p id="rfc.section.2.6.8.p.9">Delta-Window-Size: The additional number of bytes that the sender can transmit in addition to existing remaining window size. |
|---|
| 1236 | The legal range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes. |
|---|
| 1237 | </p> |
|---|
| 1238 | <p id="rfc.section.2.6.8.p.10">The window size as kept by the sender must never exceed 2^31 (although it can become negative in one special case). If a sender |
|---|
| 1239 | receives a WINDOW_UPDATE that causes the its window size to exceed this limit, it must send RST_STREAM with status code FLOW_CONTROL_ERROR |
|---|
| 1240 | to terminate the stream. |
|---|
| 1241 | </p> |
|---|
| 1242 | <p id="rfc.section.2.6.8.p.11">When a SPDY connection is first established, the default initial window size for all streams is 64KB. An endpoint can use |
|---|
| 1243 | the SETTINGS control frame to adjust the initial window size for the connection. That is, its peer can start out using the |
|---|
| 1244 | 64KB default initial window size when sending data frames before receiving the SETTINGS. Because SETTINGS is asynchronous, |
|---|
| 1245 | there may be a race condition if the recipient wants to decrease the initial window size, but its peer immediately sends 64KB |
|---|
| 1246 | on the creation of a new connection, before waiting for the SETTINGS to arrive. This is one case where the window size kept |
|---|
| 1247 | by the sender will become negative. Once the sender detects this condition, it must stop sending data frames and wait for |
|---|
| 1248 | the recipient to catch up. The recipient has two choices: |
|---|
| 1249 | </p> |
|---|
| 1250 | <ul class="empty"> |
|---|
| 1251 | <li>immediately send RST_STREAM with FLOW_CONTROL_ERROR status code.</li> |
|---|
| 1252 | <li>allow the head of line blocking (as there is only one stream for the session and the amount of data in flight is bounded by |
|---|
| 1253 | the default initial window size), and send WINDOW_UPDATE as it consumes data. |
|---|
| 1254 | </li> |
|---|
| 1255 | </ul> |
|---|
| 1256 | <p id="rfc.section.2.6.8.p.12">In the case of option 2, both sides must compute the window size based on the initial window size in the SETTINGS. For example, |
|---|
| 1257 | if the recipient sets the initial window size to be 16KB, and the sender sends 64KB immediately on connection establishment, |
|---|
| 1258 | the sender will discover its window size is -48KB on receipt of the SETTINGS. As the recipient consumes the first 16KB, it |
|---|
| 1259 | must send a WINDOW_UPDATE of 16KB back to the sender. This interaction continues until the sender's window size becomes positive |
|---|
| 1260 | again, and it can resume transmitting data frames. |
|---|
| 1261 | </p> |
|---|
| 1262 | <p id="rfc.section.2.6.8.p.13">After the recipient reads in a data frame with FLAG_FIN that marks the end of the data stream, it should not send WINDOW_UPDATE |
|---|
| 1263 | frames as it consumes the last data frame. A sender should ignore all the WINDOW_UPDATE frames associated with the stream |
|---|
| 1264 | after it send the last frame for the stream. |
|---|
| 1265 | </p> |
|---|
| 1266 | <p id="rfc.section.2.6.8.p.14">The data frames from the sender and the WINDOW_UPDATE frames from the recipient are completely asynchronous with respect to |
|---|
| 1267 | each other. This property allows a recipient to aggressively update the window size kept by the sender to prevent the stream |
|---|
| 1268 | from stalling. |
|---|
| 1269 | </p> |
|---|
| 1270 | <h3 id="rfc.section.2.6.9"><a href="#rfc.section.2.6.9">2.6.9</a> <a id="CREDENTIAL" href="#CREDENTIAL">CREDENTIAL</a></h3> |
|---|
| 1271 | <p id="rfc.section.2.6.9.p.1">The CREDENTIAL control frame is used by the client to send additional client certificates to the server. A SPDY client may |
|---|
| 1272 | decide to send requests for resources from different origins on the same SPDY session if it decides that that server handles |
|---|
| 1273 | both origins. For example if the IP address associated with both hostnames matches and the SSL server certificate presented |
|---|
| 1274 | in the initial handshake is valid for both hostnames. However, because the SSL connection can contain at most one client certificate, |
|---|
| 1275 | the client needs a mechanism to send additional client certificates to the server. |
|---|
| 1276 | </p> |
|---|
| 1277 | <p id="rfc.section.2.6.9.p.2">The server is required to maintain a vector of client certificates associated with a SPDY session. When the client needs to |
|---|
| 1278 | send a client certificate to the server, it will send a CREDENTIAL frame that specifies the index of the slot in which to |
|---|
| 1279 | store the certificate as well as proof that the client posesses the corresponding private key. The initial size of this vector |
|---|
| 1280 | must be 8. If the client provides a client certificate during the first TLS handshake, the contents of this certificate must |
|---|
| 1281 | be copied into the first slot (index 1) in the CREDENTIAL vector, though it may be overwritten by subsequent CREDENTIAL frames. |
|---|
| 1282 | The server must exclusively use the CREDNETIAL vector when evaluating the client certificates associated with an origin. The |
|---|
| 1283 | server may change the size of this vector by sending a SETTINGS frame with the setting SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE |
|---|
| 1284 | value specified. In the event that the new size is smaller than the current size, truncation occurs preserving lower-index |
|---|
| 1285 | slots as possible. |
|---|
| 1286 | </p> |
|---|
| 1287 | <p id="rfc.section.2.6.9.p.3">TLS renegotiation with client authentication is incompatible with SPDY given the multiplexed nature of SPDY. Specifically, |
|---|
| 1288 | imagine that the client has 2 requests outstanding to the server for two different pages (in different tabs). When the renegotiation |
|---|
| 1289 | + client certificate request comes in, the browser is unable to determine which resource triggered the client certificate |
|---|
| 1290 | request, in order to prompt the user accordingly. |
|---|
| 1291 | </p> |
|---|
| 1292 | <div id="rfc.figure.u.11"></div> <pre>+----------------------------------+ |
|---|
| 1293 | |1|000000000000001|0000000000001011| |
|---|
| 1294 | +----------------------------------+ |
|---|
| 1295 | | flags (8) | Length (24 bits) | |
|---|
| 1296 | +----------------------------------+ |
|---|
| 1297 | | Slot (16 bits) | | |
|---|
| 1298 | +-----------------+ | |
|---|
| 1299 | | Proof Length (32 bits) | |
|---|
| 1300 | +----------------------------------+ |
|---|
| 1301 | | Proof | |
|---|
| 1302 | +----------------------------------+ <+ |
|---|
| 1303 | | Certificate Length (32 bits) | | |
|---|
| 1304 | +----------------------------------+ | Repeated until end of frame |
|---|
| 1305 | | Certificate | | |
|---|
| 1306 | +----------------------------------+ <+ |
|---|
| 1307 | </pre> <p id="rfc.section.2.6.9.p.5">Slot: The index in the server's client certificate vector where this certificate should be stored. If there is already a certificate |
|---|
| 1308 | stored at this index, it will be overwritten. The index is one based, not zero based; zero is an invalid slot index. |
|---|
| 1309 | </p> |
|---|
| 1310 | <p id="rfc.section.2.6.9.p.6">Proof: Cryptographic proof that the client has possession of the private key associated with the certificate. The format is |
|---|
| 1311 | a TLS digitally-signed element (<a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>, <a href="http://tools.ietf.org/html/rfc5246#section-4.7">Section 4.7</a>). The signature algorithm must be the same as that used in the CertificateVerify message. However, since the MD5+SHA1 signature |
|---|
| 1312 | type used in TLS 1.0 connections can not be correctly encoded in a digitally-signed element, SHA1 must be used when MD5+SHA1 |
|---|
| 1313 | was used in the SSL connection. The signature is calculated over a 32 byte TLS extractor value (http://tools.ietf.org/html/rfc5705) |
|---|
| 1314 | with a label of "EXPORTER SPDY certificate proof" using the empty string as context. ForRSA certificates the signature would |
|---|
| 1315 | be a PKCS#1 v1.5 signature. For ECDSA, it would be an ECDSA-Sig-Value (http://tools.ietf.org/html/rfc5480#appendix-A). For |
|---|
| 1316 | a 1024-bit RSA key, the CREDENTIAL message would be ~500 bytes. |
|---|
| 1317 | </p> |
|---|
| 1318 | <p id="rfc.section.2.6.9.p.7">Certificate: The certificate chain, starting with the leaf certificate. Each certificate must be encoded as a 32 bit length, |
|---|
| 1319 | followed by a DER encoded certificate. The certificate must be of the same type (RSA, ECDSA, etc) as the client certificate |
|---|
| 1320 | associated with the SSL connection. |
|---|
| 1321 | </p> |
|---|
| 1322 | <p id="rfc.section.2.6.9.p.8">If the server receives a request for a resource with unacceptable credential (either missing or invalid), it must reply with |
|---|
| 1323 | a RST_STREAM frame with the status code INVALID_CREDENTIALS. Upon receipt of a RST_STREAM frame with INVALID_CREDENTIALS, |
|---|
| 1324 | the client should initiate a new stream directly to the requested origin and resend the request. Note, SPDY does not allow |
|---|
| 1325 | the server to request different client authentication for different resources in the same origin. |
|---|
| 1326 | </p> |
|---|
| 1327 | <p id="rfc.section.2.6.9.p.9">If the server receives an invalid CREDENTIAL frame, it MUST respond with a GOAWAY frame and shutdown the session.</p> |
|---|
| 1328 | <h3 id="rfc.section.2.6.10"><a href="#rfc.section.2.6.10">2.6.10</a> <a id="HeaderBlock" href="#HeaderBlock">Name/Value Header Block</a></h3> |
|---|
| 1329 | <p id="rfc.section.2.6.10.p.1">The Name/Value Header Block is found in the SYN_STREAM, SYN_REPLY and HEADERS control frames, and shares a common format:</p> |
|---|
| 1330 | <div id="rfc.figure.u.12"></div> <pre>+------------------------------------+ |
|---|
| 1331 | | Number of Name/Value pairs (int32) | |
|---|
| 1332 | +------------------------------------+ |
|---|
| 1333 | | Length of name (int32) | |
|---|
| 1334 | +------------------------------------+ |
|---|
| 1335 | | Name (string) | |
|---|
| 1336 | +------------------------------------+ |
|---|
| 1337 | | Length of value (int32) | |
|---|
| 1338 | +------------------------------------+ |
|---|
| 1339 | | Value (string) | |
|---|
| 1340 | +------------------------------------+ |
|---|
| 1341 | | (repeats) | |
|---|
| 1342 | </pre> <p id="rfc.section.2.6.10.p.3">Number of Name/Value pairs: The number of repeating name/value pairs following this field.</p> |
|---|
| 1343 | <p id="rfc.section.2.6.10.p.4">List of Name/Value pairs: </p> |
|---|
| 1344 | <ul class="empty"> |
|---|
| 1345 | <li>Length of Name: a 32-bit value containing the number of octets in the name field. Note that in practice, this length must |
|---|
| 1346 | not exceed 2^24, as that is the maximum size of a SPDY frame. |
|---|
| 1347 | </li> |
|---|
| 1348 | <li>Name: 0 or more octets, 8-bit sequences of data, excluding 0.</li> |
|---|
| 1349 | <li>Length of Value: a 32-bit value containing the number of octets in the value field. Note that in practice, this length must |
|---|
| 1350 | not exceed 2^24, as that is the maximum size of a SPDY frame. |
|---|
| 1351 | </li> |
|---|
| 1352 | <li>Value: 0 or more octets, 8-bit sequences of data, excluding 0.</li> |
|---|
| 1353 | </ul> |
|---|
| 1354 | <p id="rfc.section.2.6.10.p.5">Each header name must have at least one value. Header names are encoded using the <a href="#ASCII">US-ASCII character set</a> <cite title="US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986." id="rfc.xref.ASCII.1">[ASCII]</cite> and must be all lower case. The length of each name must be greater than zero. A recipient of a zero-length name MUST issue |
|---|
| 1355 | a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id. |
|---|
| 1356 | </p> |
|---|
| 1357 | <p id="rfc.section.2.6.10.p.6">Duplicate header names are not allowed. To send two identically named headers, send a header with two values, where the values |
|---|
| 1358 | are separated by a single NUL (0) byte. A header value can either be empty (e.g. the length is zero) or it can contain multiple, |
|---|
| 1359 | NUL-separated values, each with length greater than zero. The value never starts nor ends with a NUL character. Recipients |
|---|
| 1360 | of illegal value fields MUST issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with the status code PROTOCOL_ERROR for the stream-id. |
|---|
| 1361 | </p> |
|---|
| 1362 | <h4 id="rfc.section.2.6.10.1"><a href="#rfc.section.2.6.10.1">2.6.10.1</a> <a id="Compression" href="#Compression">Compression</a></h4> |
|---|
| 1363 | <p id="rfc.section.2.6.10.1.p.1">The Name/Value Header Block is a section of the SYN_STREAM, SYN_REPLY, and HEADERS frames used to carry header meta-data. |
|---|
| 1364 | This block is always compressed using zlib compression. Within this specification, any reference to 'zlib' is referring to |
|---|
| 1365 | the <a href="#RFC1950">ZLIB Compressed Data Format Specification Version 3.3 as part of RFC1950.</a> <cite title="ZLIB Compressed Data Format Specification version 3.3" id="rfc.xref.RFC1950.1">[RFC1950]</cite></p> |
|---|
| 1366 | <p id="rfc.section.2.6.10.1.p.2">For each HEADERS compression instance, the initial state is initialized using the following <a href="#UDELCOMPRESSION">dictionary</a> <cite title="A Methodology to Derive SPDY's Initial Dictionary for Zlib Compression" id="rfc.xref.UDELCOMPRESSION.1">[UDELCOMPRESSION]</cite>: |
|---|
| 1367 | </p> |
|---|
| 1368 | <div id="rfc.figure.u.13"></div> <pre class="ccmarker cct"><span><CODE BEGINS></span></pre><pre class="text">const unsigned char SPDY_dictionary_txt[] = { |
|---|
| 1369 | 0x00, 0x00, 0x00, 0x07, 0x6f, 0x70, 0x74, 0x69, \\ - - - - o p t i |
|---|
| 1370 | 0x6f, 0x6e, 0x73, 0x00, 0x00, 0x00, 0x04, 0x68, \\ o n s - - - - h |
|---|
| 1371 | 0x65, 0x61, 0x64, 0x00, 0x00, 0x00, 0x04, 0x70, \\ e a d - - - - p |
|---|
| 1372 | 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x03, 0x70, \\ o s t - - - - p |
|---|
| 1373 | 0x75, 0x74, 0x00, 0x00, 0x00, 0x06, 0x64, 0x65, \\ u t - - - - d e |
|---|
| 1374 | 0x6c, 0x65, 0x74, 0x65, 0x00, 0x00, 0x00, 0x05, \\ l e t e - - - - |
|---|
| 1375 | 0x74, 0x72, 0x61, 0x63, 0x65, 0x00, 0x00, 0x00, \\ t r a c e - - - |
|---|
| 1376 | 0x06, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x00, \\ - a c c e p t - |
|---|
| 1377 | 0x00, 0x00, 0x0e, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p |
|---|
| 1378 | 0x74, 0x2d, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ t - c h a r s e |
|---|
| 1379 | 0x74, 0x00, 0x00, 0x00, 0x0f, 0x61, 0x63, 0x63, \\ t - - - - a c c |
|---|
| 1380 | 0x65, 0x70, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e p t - e n c o |
|---|
| 1381 | 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x0f, \\ d i n g - - - - |
|---|
| 1382 | 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x2d, 0x6c, \\ a c c e p t - l |
|---|
| 1383 | 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, 0x00, \\ a n g u a g e - |
|---|
| 1384 | 0x00, 0x00, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, \\ - - - a c c e p |
|---|
| 1385 | 0x74, 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x73, \\ t - r a n g e s |
|---|
| 1386 | 0x00, 0x00, 0x00, 0x03, 0x61, 0x67, 0x65, 0x00, \\ - - - - a g e - |
|---|
| 1387 | 0x00, 0x00, 0x05, 0x61, 0x6c, 0x6c, 0x6f, 0x77, \\ - - - a l l o w |
|---|
| 1388 | 0x00, 0x00, 0x00, 0x0d, 0x61, 0x75, 0x74, 0x68, \\ - - - - a u t h |
|---|
| 1389 | 0x6f, 0x72, 0x69, 0x7a, 0x61, 0x74, 0x69, 0x6f, \\ o r i z a t i o |
|---|
| 1390 | 0x6e, 0x00, 0x00, 0x00, 0x0d, 0x63, 0x61, 0x63, \\ n - - - - c a c |
|---|
| 1391 | 0x68, 0x65, 0x2d, 0x63, 0x6f, 0x6e, 0x74, 0x72, \\ h e - c o n t r |
|---|
| 1392 | 0x6f, 0x6c, 0x00, 0x00, 0x00, 0x0a, 0x63, 0x6f, \\ o l - - - - c o |
|---|
| 1393 | 0x6e, 0x6e, 0x65, 0x63, 0x74, 0x69, 0x6f, 0x6e, \\ n n e c t i o n |
|---|
| 1394 | 0x00, 0x00, 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t |
|---|
| 1395 | 0x65, 0x6e, 0x74, 0x2d, 0x62, 0x61, 0x73, 0x65, \\ e n t - b a s e |
|---|
| 1396 | 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t |
|---|
| 1397 | 0x65, 0x6e, 0x74, 0x2d, 0x65, 0x6e, 0x63, 0x6f, \\ e n t - e n c o |
|---|
| 1398 | 0x64, 0x69, 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, \\ d i n g - - - - |
|---|
| 1399 | 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, \\ c o n t e n t - |
|---|
| 1400 | 0x6c, 0x61, 0x6e, 0x67, 0x75, 0x61, 0x67, 0x65, \\ l a n g u a g e |
|---|
| 1401 | 0x00, 0x00, 0x00, 0x0e, 0x63, 0x6f, 0x6e, 0x74, \\ - - - - c o n t |
|---|
| 1402 | 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x65, 0x6e, 0x67, \\ e n t - l e n g |
|---|
| 1403 | 0x74, 0x68, 0x00, 0x00, 0x00, 0x10, 0x63, 0x6f, \\ t h - - - - c o |
|---|
| 1404 | 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x6c, 0x6f, \\ n t e n t - l o |
|---|
| 1405 | 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ c a t i o n - - |
|---|
| 1406 | 0x00, 0x0b, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n |
|---|
| 1407 | 0x74, 0x2d, 0x6d, 0x64, 0x35, 0x00, 0x00, 0x00, \\ t - m d 5 - - - |
|---|
| 1408 | 0x0d, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, \\ - c o n t e n t |
|---|
| 1409 | 0x2d, 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, \\ - r a n g e - - |
|---|
| 1410 | 0x00, 0x0c, 0x63, 0x6f, 0x6e, 0x74, 0x65, 0x6e, \\ - - c o n t e n |
|---|
| 1411 | 0x74, 0x2d, 0x74, 0x79, 0x70, 0x65, 0x00, 0x00, \\ t - t y p e - - |
|---|
| 1412 | 0x00, 0x04, 0x64, 0x61, 0x74, 0x65, 0x00, 0x00, \\ - - d a t e - - |
|---|
| 1413 | 0x00, 0x04, 0x65, 0x74, 0x61, 0x67, 0x00, 0x00, \\ - - e t a g - - |
|---|
| 1414 | 0x00, 0x06, 0x65, 0x78, 0x70, 0x65, 0x63, 0x74, \\ - - e x p e c t |
|---|
| 1415 | 0x00, 0x00, 0x00, 0x07, 0x65, 0x78, 0x70, 0x69, \\ - - - - e x p i |
|---|
| 1416 | 0x72, 0x65, 0x73, 0x00, 0x00, 0x00, 0x04, 0x66, \\ r e s - - - - f |
|---|
| 1417 | 0x72, 0x6f, 0x6d, 0x00, 0x00, 0x00, 0x04, 0x68, \\ r o m - - - - h |
|---|
| 1418 | 0x6f, 0x73, 0x74, 0x00, 0x00, 0x00, 0x08, 0x69, \\ o s t - - - - i |
|---|
| 1419 | 0x66, 0x2d, 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, \\ f - m a t c h - |
|---|
| 1420 | 0x00, 0x00, 0x11, 0x69, 0x66, 0x2d, 0x6d, 0x6f, \\ - - - i f - m o |
|---|
| 1421 | 0x64, 0x69, 0x66, 0x69, 0x65, 0x64, 0x2d, 0x73, \\ d i f i e d - s |
|---|
| 1422 | 0x69, 0x6e, 0x63, 0x65, 0x00, 0x00, 0x00, 0x0d, \\ i n c e - - - - |
|---|
| 1423 | 0x69, 0x66, 0x2d, 0x6e, 0x6f, 0x6e, 0x65, 0x2d, \\ i f - n o n e - |
|---|
| 1424 | 0x6d, 0x61, 0x74, 0x63, 0x68, 0x00, 0x00, 0x00, \\ m a t c h - - - |
|---|
| 1425 | 0x08, 0x69, 0x66, 0x2d, 0x72, 0x61, 0x6e, 0x67, \\ - i f - r a n g |
|---|
| 1426 | 0x65, 0x00, 0x00, 0x00, 0x13, 0x69, 0x66, 0x2d, \\ e - - - - i f - |
|---|
| 1427 | 0x75, 0x6e, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, \\ u n m o d i f i |
|---|
| 1428 | 0x65, 0x64, 0x2d, 0x73, 0x69, 0x6e, 0x63, 0x65, \\ e d - s i n c e |
|---|
| 1429 | 0x00, 0x00, 0x00, 0x0d, 0x6c, 0x61, 0x73, 0x74, \\ - - - - l a s t |
|---|
| 1430 | 0x2d, 0x6d, 0x6f, 0x64, 0x69, 0x66, 0x69, 0x65, \\ - m o d i f i e |
|---|
| 1431 | 0x64, 0x00, 0x00, 0x00, 0x08, 0x6c, 0x6f, 0x63, \\ d - - - - l o c |
|---|
| 1432 | 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, \\ a t i o n - - - |
|---|
| 1433 | 0x0c, 0x6d, 0x61, 0x78, 0x2d, 0x66, 0x6f, 0x72, \\ - m a x - f o r |
|---|
| 1434 | 0x77, 0x61, 0x72, 0x64, 0x73, 0x00, 0x00, 0x00, \\ w a r d s - - - |
|---|
| 1435 | 0x06, 0x70, 0x72, 0x61, 0x67, 0x6d, 0x61, 0x00, \\ - p r a g m a - |
|---|
| 1436 | 0x00, 0x00, 0x12, 0x70, 0x72, 0x6f, 0x78, 0x79, \\ - - - p r o x y |
|---|
| 1437 | 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, 0x74, \\ - a u t h e n t |
|---|
| 1438 | 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, 0x00, \\ i c a t e - - - |
|---|
| 1439 | 0x13, 0x70, 0x72, 0x6f, 0x78, 0x79, 0x2d, 0x61, \\ - p r o x y - a |
|---|
| 1440 | 0x75, 0x74, 0x68, 0x6f, 0x72, 0x69, 0x7a, 0x61, \\ u t h o r i z a |
|---|
| 1441 | 0x74, 0x69, 0x6f, 0x6e, 0x00, 0x00, 0x00, 0x05, \\ t i o n - - - - |
|---|
| 1442 | 0x72, 0x61, 0x6e, 0x67, 0x65, 0x00, 0x00, 0x00, \\ r a n g e - - - |
|---|
| 1443 | 0x07, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x72, \\ - r e f e r e r |
|---|
| 1444 | 0x00, 0x00, 0x00, 0x0b, 0x72, 0x65, 0x74, 0x72, \\ - - - - r e t r |
|---|
| 1445 | 0x79, 0x2d, 0x61, 0x66, 0x74, 0x65, 0x72, 0x00, \\ y - a f t e r - |
|---|
| 1446 | 0x00, 0x00, 0x06, 0x73, 0x65, 0x72, 0x76, 0x65, \\ - - - s e r v e |
|---|
| 1447 | 0x72, 0x00, 0x00, 0x00, 0x02, 0x74, 0x65, 0x00, \\ r - - - - t e - |
|---|
| 1448 | 0x00, 0x00, 0x07, 0x74, 0x72, 0x61, 0x69, 0x6c, \\ - - - t r a i l |
|---|
| 1449 | 0x65, 0x72, 0x00, 0x00, 0x00, 0x11, 0x74, 0x72, \\ e r - - - - t r |
|---|
| 1450 | 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x2d, 0x65, \\ a n s f e r - e |
|---|
| 1451 | 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, 0x00, \\ n c o d i n g - |
|---|
| 1452 | 0x00, 0x00, 0x07, 0x75, 0x70, 0x67, 0x72, 0x61, \\ - - - u p g r a |
|---|
| 1453 | 0x64, 0x65, 0x00, 0x00, 0x00, 0x0a, 0x75, 0x73, \\ d e - - - - u s |
|---|
| 1454 | 0x65, 0x72, 0x2d, 0x61, 0x67, 0x65, 0x6e, 0x74, \\ e r - a g e n t |
|---|
| 1455 | 0x00, 0x00, 0x00, 0x04, 0x76, 0x61, 0x72, 0x79, \\ - - - - v a r y |
|---|
| 1456 | 0x00, 0x00, 0x00, 0x03, 0x76, 0x69, 0x61, 0x00, \\ - - - - v i a - |
|---|
| 1457 | 0x00, 0x00, 0x07, 0x77, 0x61, 0x72, 0x6e, 0x69, \\ - - - w a r n i |
|---|
| 1458 | 0x6e, 0x67, 0x00, 0x00, 0x00, 0x10, 0x77, 0x77, \\ n g - - - - w w |
|---|
| 1459 | 0x77, 0x2d, 0x61, 0x75, 0x74, 0x68, 0x65, 0x6e, \\ w - a u t h e n |
|---|
| 1460 | 0x74, 0x69, 0x63, 0x61, 0x74, 0x65, 0x00, 0x00, \\ t i c a t e - - |
|---|
| 1461 | 0x00, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, \\ - - m e t h o d |
|---|
| 1462 | 0x00, 0x00, 0x00, 0x03, 0x67, 0x65, 0x74, 0x00, \\ - - - - g e t - |
|---|
| 1463 | 0x00, 0x00, 0x06, 0x73, 0x74, 0x61, 0x74, 0x75, \\ - - - s t a t u |
|---|
| 1464 | 0x73, 0x00, 0x00, 0x00, 0x06, 0x32, 0x30, 0x30, \\ s - - - - 2 0 0 |
|---|
| 1465 | 0x20, 0x4f, 0x4b, 0x00, 0x00, 0x00, 0x07, 0x76, \\ - O K - - - - v |
|---|
| 1466 | 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x00, 0x00, \\ e r s i o n - - |
|---|
| 1467 | 0x00, 0x08, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, \\ - - H T T P - 1 |
|---|
| 1468 | 0x2e, 0x31, 0x00, 0x00, 0x00, 0x03, 0x75, 0x72, \\ - 1 - - - - u r |
|---|
| 1469 | 0x6c, 0x00, 0x00, 0x00, 0x06, 0x70, 0x75, 0x62, \\ l - - - - p u b |
|---|
| 1470 | 0x6c, 0x69, 0x63, 0x00, 0x00, 0x00, 0x0a, 0x73, \\ l i c - - - - s |
|---|
| 1471 | 0x65, 0x74, 0x2d, 0x63, 0x6f, 0x6f, 0x6b, 0x69, \\ e t - c o o k i |
|---|
| 1472 | 0x65, 0x00, 0x00, 0x00, 0x0a, 0x6b, 0x65, 0x65, \\ e - - - - k e e |
|---|
| 1473 | 0x70, 0x2d, 0x61, 0x6c, 0x69, 0x76, 0x65, 0x00, \\ p - a l i v e - |
|---|
| 1474 | 0x00, 0x00, 0x06, 0x6f, 0x72, 0x69, 0x67, 0x69, \\ - - - o r i g i |
|---|
| 1475 | 0x6e, 0x31, 0x30, 0x30, 0x31, 0x30, 0x31, 0x32, \\ n 1 0 0 1 0 1 2 |
|---|
| 1476 | 0x30, 0x31, 0x32, 0x30, 0x32, 0x32, 0x30, 0x35, \\ 0 1 2 0 2 2 0 5 |
|---|
| 1477 | 0x32, 0x30, 0x36, 0x33, 0x30, 0x30, 0x33, 0x30, \\ 2 0 6 3 0 0 3 0 |
|---|
| 1478 | 0x32, 0x33, 0x30, 0x33, 0x33, 0x30, 0x34, 0x33, \\ 2 3 0 3 3 0 4 3 |
|---|
| 1479 | 0x30, 0x35, 0x33, 0x30, 0x36, 0x33, 0x30, 0x37, \\ 0 5 3 0 6 3 0 7 |
|---|
| 1480 | 0x34, 0x30, 0x32, 0x34, 0x30, 0x35, 0x34, 0x30, \\ 4 0 2 4 0 5 4 0 |
|---|
| 1481 | 0x36, 0x34, 0x30, 0x37, 0x34, 0x30, 0x38, 0x34, \\ 6 4 0 7 4 0 8 4 |
|---|
| 1482 | 0x30, 0x39, 0x34, 0x31, 0x30, 0x34, 0x31, 0x31, \\ 0 9 4 1 0 4 1 1 |
|---|
| 1483 | 0x34, 0x31, 0x32, 0x34, 0x31, 0x33, 0x34, 0x31, \\ 4 1 2 4 1 3 4 1 |
|---|
| 1484 | 0x34, 0x34, 0x31, 0x35, 0x34, 0x31, 0x36, 0x34, \\ 4 4 1 5 4 1 6 4 |
|---|
| 1485 | 0x31, 0x37, 0x35, 0x30, 0x32, 0x35, 0x30, 0x34, \\ 1 7 5 0 2 5 0 4 |
|---|
| 1486 | 0x35, 0x30, 0x35, 0x32, 0x30, 0x33, 0x20, 0x4e, \\ 5 0 5 2 0 3 - N |
|---|
| 1487 | 0x6f, 0x6e, 0x2d, 0x41, 0x75, 0x74, 0x68, 0x6f, \\ o n - A u t h o |
|---|
| 1488 | 0x72, 0x69, 0x74, 0x61, 0x74, 0x69, 0x76, 0x65, \\ r i t a t i v e |
|---|
| 1489 | 0x20, 0x49, 0x6e, 0x66, 0x6f, 0x72, 0x6d, 0x61, \\ - I n f o r m a |
|---|
| 1490 | 0x74, 0x69, 0x6f, 0x6e, 0x32, 0x30, 0x34, 0x20, \\ t i o n 2 0 4 - |
|---|
| 1491 | 0x4e, 0x6f, 0x20, 0x43, 0x6f, 0x6e, 0x74, 0x65, \\ N o - C o n t e |
|---|
| 1492 | 0x6e, 0x74, 0x33, 0x30, 0x31, 0x20, 0x4d, 0x6f, \\ n t 3 0 1 - M o |
|---|
| 1493 | 0x76, 0x65, 0x64, 0x20, 0x50, 0x65, 0x72, 0x6d, \\ v e d - P e r m |
|---|
| 1494 | 0x61, 0x6e, 0x65, 0x6e, 0x74, 0x6c, 0x79, 0x34, \\ a n e n t l y 4 |
|---|
| 1495 | 0x30, 0x30, 0x20, 0x42, 0x61, 0x64, 0x20, 0x52, \\ 0 0 - B a d - R |
|---|
| 1496 | 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x34, 0x30, \\ e q u e s t 4 0 |
|---|
| 1497 | 0x31, 0x20, 0x55, 0x6e, 0x61, 0x75, 0x74, 0x68, \\ 1 - U n a u t h |
|---|
| 1498 | 0x6f, 0x72, 0x69, 0x7a, 0x65, 0x64, 0x34, 0x30, \\ o r i z e d 4 0 |
|---|
| 1499 | 0x33, 0x20, 0x46, 0x6f, 0x72, 0x62, 0x69, 0x64, \\ 3 - F o r b i d |
|---|
| 1500 | 0x64, 0x65, 0x6e, 0x34, 0x30, 0x34, 0x20, 0x4e, \\ d e n 4 0 4 - N |
|---|
| 1501 | 0x6f, 0x74, 0x20, 0x46, 0x6f, 0x75, 0x6e, 0x64, \\ o t - F o u n d |
|---|
| 1502 | 0x35, 0x30, 0x30, 0x20, 0x49, 0x6e, 0x74, 0x65, \\ 5 0 0 - I n t e |
|---|
| 1503 | 0x72, 0x6e, 0x61, 0x6c, 0x20, 0x53, 0x65, 0x72, \\ r n a l - S e r |
|---|
| 1504 | 0x76, 0x65, 0x72, 0x20, 0x45, 0x72, 0x72, 0x6f, \\ v e r - E r r o |
|---|
| 1505 | 0x72, 0x35, 0x30, 0x31, 0x20, 0x4e, 0x6f, 0x74, \\ r 5 0 1 - N o t |
|---|
| 1506 | 0x20, 0x49, 0x6d, 0x70, 0x6c, 0x65, 0x6d, 0x65, \\ - I m p l e m e |
|---|
| 1507 | 0x6e, 0x74, 0x65, 0x64, 0x35, 0x30, 0x33, 0x20, \\ n t e d 5 0 3 - |
|---|
| 1508 | 0x53, 0x65, 0x72, 0x76, 0x69, 0x63, 0x65, 0x20, \\ S e r v i c e - |
|---|
| 1509 | 0x55, 0x6e, 0x61, 0x76, 0x61, 0x69, 0x6c, 0x61, \\ U n a v a i l a |
|---|
| 1510 | 0x62, 0x6c, 0x65, 0x4a, 0x61, 0x6e, 0x20, 0x46, \\ b l e J a n - F |
|---|
| 1511 | 0x65, 0x62, 0x20, 0x4d, 0x61, 0x72, 0x20, 0x41, \\ e b - M a r - A |
|---|
| 1512 | 0x70, 0x72, 0x20, 0x4d, 0x61, 0x79, 0x20, 0x4a, \\ p r - M a y - J |
|---|
| 1513 | 0x75, 0x6e, 0x20, 0x4a, 0x75, 0x6c, 0x20, 0x41, \\ u n - J u l - A |
|---|
| 1514 | 0x75, 0x67, 0x20, 0x53, 0x65, 0x70, 0x74, 0x20, \\ u g - S e p t - |
|---|
| 1515 | 0x4f, 0x63, 0x74, 0x20, 0x4e, 0x6f, 0x76, 0x20, \\ O c t - N o v - |
|---|
| 1516 | 0x44, 0x65, 0x63, 0x20, 0x30, 0x30, 0x3a, 0x30, \\ D e c - 0 0 - 0 |
|---|
| 1517 | 0x30, 0x3a, 0x30, 0x30, 0x20, 0x4d, 0x6f, 0x6e, \\ 0 - 0 0 - M o n |
|---|
| 1518 | 0x2c, 0x20, 0x54, 0x75, 0x65, 0x2c, 0x20, 0x57, \\ - - T u e - - W |
|---|
| 1519 | 0x65, 0x64, 0x2c, 0x20, 0x54, 0x68, 0x75, 0x2c, \\ e d - - T h u - |
|---|
| 1520 | 0x20, 0x46, 0x72, 0x69, 0x2c, 0x20, 0x53, 0x61, \\ - F r i - - S a |
|---|
| 1521 | 0x74, 0x2c, 0x20, 0x53, 0x75, 0x6e, 0x2c, 0x20, \\ t - - S u n - - |
|---|
| 1522 | 0x47, 0x4d, 0x54, 0x63, 0x68, 0x75, 0x6e, 0x6b, \\ G M T c h u n k |
|---|
| 1523 | 0x65, 0x64, 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, \\ e d - t e x t - |
|---|
| 1524 | 0x68, 0x74, 0x6d, 0x6c, 0x2c, 0x69, 0x6d, 0x61, \\ h t m l - i m a |
|---|
| 1525 | 0x67, 0x65, 0x2f, 0x70, 0x6e, 0x67, 0x2c, 0x69, \\ g e - p n g - i |
|---|
| 1526 | 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x6a, 0x70, 0x67, \\ m a g e - j p g |
|---|
| 1527 | 0x2c, 0x69, 0x6d, 0x61, 0x67, 0x65, 0x2f, 0x67, \\ - i m a g e - g |
|---|
| 1528 | 0x69, 0x66, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ i f - a p p l i |
|---|
| 1529 | 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x |
|---|
| 1530 | 0x6d, 0x6c, 0x2c, 0x61, 0x70, 0x70, 0x6c, 0x69, \\ m l - a p p l i |
|---|
| 1531 | 0x63, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x2f, 0x78, \\ c a t i o n - x |
|---|
| 1532 | 0x68, 0x74, 0x6d, 0x6c, 0x2b, 0x78, 0x6d, 0x6c, \\ h t m l - x m l |
|---|
| 1533 | 0x2c, 0x74, 0x65, 0x78, 0x74, 0x2f, 0x70, 0x6c, \\ - t e x t - p l |
|---|
| 1534 | 0x61, 0x69, 0x6e, 0x2c, 0x74, 0x65, 0x78, 0x74, \\ a i n - t e x t |
|---|
| 1535 | 0x2f, 0x6a, 0x61, 0x76, 0x61, 0x73, 0x63, 0x72, \\ - j a v a s c r |
|---|
| 1536 | 0x69, 0x70, 0x74, 0x2c, 0x70, 0x75, 0x62, 0x6c, \\ i p t - p u b l |
|---|
| 1537 | 0x69, 0x63, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, \\ i c p r i v a t |
|---|
| 1538 | 0x65, 0x6d, 0x61, 0x78, 0x2d, 0x61, 0x67, 0x65, \\ e m a x - a g e |
|---|
| 1539 | 0x3d, 0x67, 0x7a, 0x69, 0x70, 0x2c, 0x64, 0x65, \\ - g z i p - d e |
|---|
| 1540 | 0x66, 0x6c, 0x61, 0x74, 0x65, 0x2c, 0x73, 0x64, \\ f l a t e - s d |
|---|
| 1541 | 0x63, 0x68, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65, \\ c h c h a r s e |
|---|
| 1542 | 0x74, 0x3d, 0x75, 0x74, 0x66, 0x2d, 0x38, 0x63, \\ t - u t f - 8 c |
|---|
| 1543 | 0x68, 0x61, 0x72, 0x73, 0x65, 0x74, 0x3d, 0x69, \\ h a r s e t - i |
|---|
| 1544 | 0x73, 0x6f, 0x2d, 0x38, 0x38, 0x35, 0x39, 0x2d, \\ s o - 8 8 5 9 - |
|---|
| 1545 | 0x31, 0x2c, 0x75, 0x74, 0x66, 0x2d, 0x2c, 0x2a, \\ 1 - u t f - - - |
|---|
| 1546 | 0x2c, 0x65, 0x6e, 0x71, 0x3d, 0x30, 0x2e \\ - e n q - 0 - |
|---|
| 1547 | }; |
|---|
| 1548 | </pre><pre class="ccmarker ccb"><span><CODE ENDS></span></pre> <p id="rfc.section.2.6.10.1.p.4">The entire contents of the name/value header block is compressed using zlib. There is a single zlib stream for all name value |
|---|
| 1549 | pairs in one direction on a connection. SPDY uses a SYNC_FLUSH between each compressed frame. |
|---|
| 1550 | </p> |
|---|
| 1551 | <p id="rfc.section.2.6.10.1.p.5">Implementation notes: the compression engine can be tuned to favor speed or size. Optimizing for size increases memory use |
|---|
| 1552 | and CPU consumption. Because header blocks are generally small, implementors may want to reduce the window-size of the compression |
|---|
| 1553 | engine from the default 15bits (a 32KB window) to more like 11bits (a 2KB window). The exact setting is chosen by the compressor, |
|---|
| 1554 | the decompressor will work with any setting. |
|---|
| 1555 | </p> |
|---|
| 1556 | <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="HTTPLayer" href="#HTTPLayer">HTTP Layering over SPDY</a></h1> |
|---|
| 1557 | <p id="rfc.section.3.p.1">SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective |
|---|
| 1558 | of the server business logic or application API, the features of HTTP are unchanged. To achieve this, all of the application |
|---|
| 1559 | request and response header semantics are preserved, although the syntax of conveying those semantics has changed. Thus, the |
|---|
| 1560 | rules from the <a href="#RFC2616">HTTP/1.1 specification in RFC2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]</cite> apply with the changes in the sections below. |
|---|
| 1561 | </p> |
|---|
| 1562 | <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> Connection Management |
|---|
| 1563 | </h2> |
|---|
| 1564 | <p id="rfc.section.3.1.p.1">Clients SHOULD NOT open more than one SPDY session to a given <a href="#RFC6454">origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.2">[RFC6454]</cite> concurrently. |
|---|
| 1565 | </p> |
|---|
| 1566 | <p id="rfc.section.3.1.p.2">Note that it is possible for one SPDY session to be finishing (e.g. a GOAWAY message has been sent, but not all streams have |
|---|
| 1567 | finished), while another SPDY session is starting. |
|---|
| 1568 | </p> |
|---|
| 1569 | <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> Use of GOAWAY |
|---|
| 1570 | </h3> |
|---|
| 1571 | <p id="rfc.section.3.1.1.p.1">SPDY provides a GOAWAY message which can be used when closing a connection from either the client or server. Without a server |
|---|
| 1572 | GOAWAY message, HTTP has a race condition where the client sends a request (a new SYN_STREAM) just as the server is closing |
|---|
| 1573 | the connection, and the client cannot know if the server received the stream or not. By using the last-stream-id in the GOAWAY, |
|---|
| 1574 | servers can indicate to the client if a request was processed or not. |
|---|
| 1575 | </p> |
|---|
| 1576 | <p id="rfc.section.3.1.1.p.2">Note that some servers will choose to send the GOAWAY and immediately terminate the connection without waiting for active |
|---|
| 1577 | streams to finish. The client will be able to determine this because SPDY streams are determinstically closed. This abrupt |
|---|
| 1578 | termination will force the client to heuristically decide whether to retry the pending requests. Clients always need to be |
|---|
| 1579 | capable of dealing with this case because they must deal with accidental connection termination cases, which are the same |
|---|
| 1580 | as the server never having sent a GOAWAY. |
|---|
| 1581 | </p> |
|---|
| 1582 | <p id="rfc.section.3.1.1.p.3">More sophisticated servers will use GOAWAY to implement a graceful teardown. They will send the GOAWAY and provide some time |
|---|
| 1583 | for the active streams to finish before terminating the connection. |
|---|
| 1584 | </p> |
|---|
| 1585 | <p id="rfc.section.3.1.1.p.4">If a SPDY client closes the connection, it should also send a GOAWAY message. This allows the server to know if any server-push |
|---|
| 1586 | streams were received by the client. |
|---|
| 1587 | </p> |
|---|
| 1588 | <p id="rfc.section.3.1.1.p.5">If the endpoint closing the connection has not received any SYN_STREAMs from the remote, the GOAWAY will contain a last-stream-id |
|---|
| 1589 | of 0. |
|---|
| 1590 | </p> |
|---|
| 1591 | <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> HTTP Request/Response |
|---|
| 1592 | </h2> |
|---|
| 1593 | <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> Request |
|---|
| 1594 | </h3> |
|---|
| 1595 | <p id="rfc.section.3.2.1.p.1">The client initiates a request by sending a SYN_STREAM frame. For requests which do not contain a body, the SYN_STREAM frame |
|---|
| 1596 | MUST set the FLAG_FIN, indicating that the client intends to send no further data on this stream. For requests which do contain |
|---|
| 1597 | a body, the SYN_STREAM will not contain the FLAG_FIN, and the body will follow the SYN_STREAM in a series of DATA frames. |
|---|
| 1598 | The last DATA frame will set the FLAG_FIN to indicate the end of the body. |
|---|
| 1599 | </p> |
|---|
| 1600 | <p id="rfc.section.3.2.1.p.2">The SYN_STREAM Name/Value section will contain all of the HTTP headers which are associated with an HTTP request. The header |
|---|
| 1601 | block in SPDY is mostly unchanged from today's HTTP header block, with the following differences: |
|---|
| 1602 | </p> |
|---|
| 1603 | <ul class="empty"> |
|---|
| 1604 | <li>The first line of the request is unfolded into name/value pairs like other HTTP headers and MUST be present: |
|---|
| 1605 | <ul class="empty"> |
|---|
| 1606 | <li>":method" - the HTTP method for this request (e.g. "GET", "POST", "HEAD", etc)</li> |
|---|
| 1607 | <li>":path" - the url-path for this url with "/" prefixed. (See <a href="#RFC1738">RFC1738</a> <cite title="Uniform Resource Locators (URL)" id="rfc.xref.RFC1738.1">[RFC1738]</cite>). For example, for "http://www.google.com/search?q=dogs" the path would be "/search?q=dogs". |
|---|
| 1608 | </li> |
|---|
| 1609 | <li>":version" - the HTTP version of this request (e.g. "HTTP/1.1")</li> |
|---|
| 1610 | </ul> |
|---|
| 1611 | </li> |
|---|
| 1612 | <li>In addition, the following two name/value pairs must also be present in every request: |
|---|
| 1613 | <ul class="empty"> |
|---|
| 1614 | <li>":host" - the hostport (See <a href="#RFC1738">RFC1738</a> <cite title="Uniform Resource Locators (URL)" id="rfc.xref.RFC1738.2">[RFC1738]</cite>) portion of the URL for this request (e.g. "www.google.com:1234"). This header is the same as the HTTP 'Host' header. |
|---|
| 1615 | </li> |
|---|
| 1616 | <li>":scheme" - the scheme portion of the URL for this request (e.g. "https"))</li> |
|---|
| 1617 | </ul> |
|---|
| 1618 | </li> |
|---|
| 1619 | <li>Header names are all lowercase.</li> |
|---|
| 1620 | <li>The Connection, Host, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers are not valid and MUST not be sent.</li> |
|---|
| 1621 | <li>User-agents MUST support gzip compression. Regardless of the Accept-Encoding sent by the user-agent, the server may always |
|---|
| 1622 | send content encoded with gzip or deflate encoding. |
|---|
| 1623 | </li> |
|---|
| 1624 | <li>If a server receives a request where the sum of the data frame payload lengths does not equal the size of the Content-Length |
|---|
| 1625 | header, the server MUST return a 400 (Bad Request) error. |
|---|
| 1626 | </li> |
|---|
| 1627 | <li>POST-specific changes: |
|---|
| 1628 | <ul class="empty"> |
|---|
| 1629 | <li>Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header. There are two |
|---|
| 1630 | reasons for this: First, it assists with upload progress meters for an improved user experience. But second, we know from |
|---|
| 1631 | early versions of SPDY that failure to send a content length header is incompatible with many existing HTTP server implementations. |
|---|
| 1632 | Existing user-agents do not omit the Content-Length header, and server implementations have come to depend upon this. |
|---|
| 1633 | </li> |
|---|
| 1634 | </ul> |
|---|
| 1635 | </li> |
|---|
| 1636 | </ul> |
|---|
| 1637 | <p id="rfc.section.3.2.1.p.3">The user-agent is free to prioritize requests as it sees fit. If the user-agent cannot make progress without receiving a resource, |
|---|
| 1638 | it should attempt to raise the priority of that resource. Resources such as images, SHOULD generally use the lowest priority. |
|---|
| 1639 | </p> |
|---|
| 1640 | <p id="rfc.section.3.2.1.p.4">If a client sends a SYN_STREAM without all of the method, host, path, scheme, and version headers, the server MUST reply with |
|---|
| 1641 | a HTTP 400 Bad Request reply. |
|---|
| 1642 | </p> |
|---|
| 1643 | <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> Response |
|---|
| 1644 | </h3> |
|---|
| 1645 | <p id="rfc.section.3.2.2.p.1">The server responds to a client request with a SYN_REPLY frame. Symmetric to the client's upload stream, server will send |
|---|
| 1646 | data after the SYN_REPLY frame via a series of DATA frames, and the last data frame will contain the FLAG_FIN to indicate |
|---|
| 1647 | successful end-of-stream. If a response (like a 202 or 204 response) contains no body, the SYN_REPLY frame may contain the |
|---|
| 1648 | FLAG_FIN flag to indicate no further data will be sent on the stream. |
|---|
| 1649 | </p> |
|---|
| 1650 | <p id="rfc.section.3.2.2.p.2"> </p> |
|---|
| 1651 | <ul class="empty"> |
|---|
| 1652 | <li>The response status line is unfolded into name/value pairs like other HTTP headers and must be present: |
|---|
| 1653 | <ul class="empty"> |
|---|
| 1654 | <li>":status" - The HTTP response status code (e.g. "200" or "200 OK")</li> |
|---|
| 1655 | <li>":version" - The HTTP response version (e.g. "HTTP/1.1")</li> |
|---|
| 1656 | </ul> |
|---|
| 1657 | </li> |
|---|
| 1658 | <li>All header names must be lowercase.</li> |
|---|
| 1659 | <li>The Connection, Keep-Alive, Proxy-Connection, and Transfer-Encoding headers are not valid and MUST not be sent.</li> |
|---|
| 1660 | <li>Responses MAY be accompanied by a Content-Length header for advisory purposes. (e.g. for UI progress meters)</li> |
|---|
| 1661 | <li>If a client receives a response where the sum of the data frame payload lengths does not equal the size of the Content-Length |
|---|
| 1662 | header, the client MUST ignore the content length header. |
|---|
| 1663 | </li> |
|---|
| 1664 | </ul> |
|---|
| 1665 | <p id="rfc.section.3.2.2.p.3">If a client receives a SYN_REPLY without a status or without a version header, the client must reply with a RST_STREAM frame |
|---|
| 1666 | indicating a PROTOCOL ERROR. |
|---|
| 1667 | </p> |
|---|
| 1668 | <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="Authentication" href="#Authentication">Authentication</a></h3> |
|---|
| 1669 | <p id="rfc.section.3.2.3.p.1">When a client sends a request to an origin server that requires authentication, the server can reply with a "401 Unauthorized" |
|---|
| 1670 | response, and include a WWW-Authenticate challenge header that defines the authentication scheme to be used. The client then |
|---|
| 1671 | retries the request with an Authorization header appropriate to the specified authentication scheme. |
|---|
| 1672 | </p> |
|---|
| 1673 | <p id="rfc.section.3.2.3.p.2">There are four options for proxy authentication, Basic, Digest, NTLM and Negotiate (SPNEGO). The first two options were defined |
|---|
| 1674 | in <a href="#RFC2617">RFC2617</a> <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.1">[RFC2617]</cite>, and are stateless. The second two options were developed by Microsoft and specified in <a href="#RFC4559">RFC4559</a> <cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" id="rfc.xref.RFC4559.1">[RFC4559]</cite>, and are stateful; otherwise known as multi-round authentication, or connection authentication. |
|---|
| 1675 | </p> |
|---|
| 1676 | <h4 id="rfc.section.3.2.3.1"><a href="#rfc.section.3.2.3.1">3.2.3.1</a> Stateless Authentication |
|---|
| 1677 | </h4> |
|---|
| 1678 | <p id="rfc.section.3.2.3.1.p.1">Stateless Authentication over SPDY is identical to how it is performed over HTTP. If multiple SPDY streams are concurrently |
|---|
| 1679 | sent to a single server, each will authenticate independently, similar to how two HTTP connections would independently authenticate |
|---|
| 1680 | to a proxy server. |
|---|
| 1681 | </p> |
|---|
| 1682 | <h4 id="rfc.section.3.2.3.2"><a href="#rfc.section.3.2.3.2">3.2.3.2</a> Stateful Authentication |
|---|
| 1683 | </h4> |
|---|
| 1684 | <p id="rfc.section.3.2.3.2.p.1">Unfortunately, the stateful authentication mechanisms were implemented and defined in a such a way that directly violates |
|---|
| 1685 | RFC2617 - they do not include a "realm" as part of the request. This is problematic in SPDY because it makes it impossible |
|---|
| 1686 | for a client to disambiguate two concurrent server authentication challenges. |
|---|
| 1687 | </p> |
|---|
| 1688 | <p id="rfc.section.3.2.3.2.p.2">To deal with this case, SPDY servers using Stateful Authentication MUST implement one of two changes: </p> |
|---|
| 1689 | <ul class="empty"> |
|---|
| 1690 | <li>Servers can add a "realm=<desired realm>" header so that the two authentication requests can be disambiguated and run concurrently. |
|---|
| 1691 | Unfortunately, given how these mechanisms work, this is probably not practical. |
|---|
| 1692 | </li> |
|---|
| 1693 | <li>Upon sending the first stateful challenge response, the server MUST buffer and defer all further frames which are not part |
|---|
| 1694 | of completing the challenge until the challenge has completed. Completing the authentication challenge may take multiple round |
|---|
| 1695 | trips. Once the client receives a "401 Authenticate" response for a stateful authentication type, it MUST stop sending new |
|---|
| 1696 | requests to the server until the authentication has completed by receiving a non-401 response on at least one stream. |
|---|
| 1697 | </li> |
|---|
| 1698 | </ul> |
|---|
| 1699 | <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> Server Push Transactions |
|---|
| 1700 | </h2> |
|---|
| 1701 | <p id="rfc.section.3.3.p.1">SPDY enables a server to send multiple replies to a client for a single request. The rationale for this feature is that sometimes |
|---|
| 1702 | a server knows that it will need to send multiple resources in response to a single request. Without server push features, |
|---|
| 1703 | the client must first download the primary resource, then discover the secondary resource(s), and request them. Pushing of |
|---|
| 1704 | resources avoids the round-trip delay, but also creates a potential race where a server can be pushing content which a user-agent |
|---|
| 1705 | is in the process of requesting. The following mechanics attempt to prevent the race condition while enabling the performance |
|---|
| 1706 | benefit. |
|---|
| 1707 | </p> |
|---|
| 1708 | <p id="rfc.section.3.3.p.2">Browsers receiving a pushed response MUST validate that the server is authorized to push the URL using the <a href="#RFC6454">browser same-origin</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.3">[RFC6454]</cite> policy. For example, a SPDY connection to www.foo.com is generally not permitted to push a response for www.evil.com. |
|---|
| 1709 | </p> |
|---|
| 1710 | <p id="rfc.section.3.3.p.3">If the browser accepts a pushed response (e.g. it does not send a RST_STREAM), the browser MUST attempt to cache the pushed |
|---|
| 1711 | response in same way that it would cache any other response. This means validating the response headers and inserting into |
|---|
| 1712 | the disk cache. |
|---|
| 1713 | </p> |
|---|
| 1714 | <p id="rfc.section.3.3.p.4">Because pushed responses have no request, they have no request headers associated with them. At the framing layer, SPDY pushed |
|---|
| 1715 | streams contain an "associated-stream-id" which indicates the requested stream for which the pushed stream is related. The |
|---|
| 1716 | pushed stream inherits all of the headers from the associated-stream-id with the exception of ":host", ":scheme", and ":path", |
|---|
| 1717 | which are provided as part of the pushed response stream headers. The browser MUST store these inherited and implied request |
|---|
| 1718 | headers with the cached resource. |
|---|
| 1719 | </p> |
|---|
| 1720 | <p id="rfc.section.3.3.p.5">Implementation note: With server push, it is theoretically possible for servers to push unreasonable amounts of content or |
|---|
| 1721 | resources to the user-agent. Browsers MUST implement throttles to protect against unreasonable push attacks. |
|---|
| 1722 | </p> |
|---|
| 1723 | <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> Server implementation |
|---|
| 1724 | </h3> |
|---|
| 1725 | <p id="rfc.section.3.3.1.p.1">When the server intends to push a resource to the user-agent, it opens a new stream by sending a unidirectional SYN_STREAM. |
|---|
| 1726 | The SYN_STREAM MUST include an Associated-To-Stream-ID, and MUST set the FLAG_UNIDIRECTIONAL flag. The SYN_STREAM MUST include |
|---|
| 1727 | headers for ":scheme", ":host", ":path", which represent the URL for the resource being pushed. Subsequent headers may follow |
|---|
| 1728 | in HEADERS frames. The purpose of the association is so that the user-agent can differentiate which request induced the pushed |
|---|
| 1729 | stream; without it, if the user-agent had two tabs open to the same page, each pushing unique content under a fixed URL, the |
|---|
| 1730 | user-agent would not be able to differentiate the requests. |
|---|
| 1731 | </p> |
|---|
| 1732 | <p id="rfc.section.3.3.1.p.2">The Associated-To-Stream-ID must be the ID of an existing, open stream. The reason for this restriction is to have a clear |
|---|
| 1733 | endpoint for pushed content. If the user-agent requested a resource on stream 11, the server replies on stream 11. It can |
|---|
| 1734 | push any number of additional streams to the client before sending a FLAG_FIN on stream 11. However, once the originating |
|---|
| 1735 | stream is closed no further push streams may be associated with it. The pushed streams do not need to be closed (FIN set) |
|---|
| 1736 | before the originating stream is closed, they only need to be created before the originating stream closes. |
|---|
| 1737 | </p> |
|---|
| 1738 | <p id="rfc.section.3.3.1.p.3">It is illegal for a server to push a resource with the Associated-To-Stream-ID of 0.</p> |
|---|
| 1739 | <p id="rfc.section.3.3.1.p.4">To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content |
|---|
| 1740 | which could allow the client to discover the pushed resource and request it. |
|---|
| 1741 | </p> |
|---|
| 1742 | <p id="rfc.section.3.3.1.p.5">The server MUST only push resources which would have been returned from a GET request.</p> |
|---|
| 1743 | <p id="rfc.section.3.3.1.p.6">Note: If the server does not have all of the Name/Value Response headers available at the time it issues the HEADERS frame |
|---|
| 1744 | for the pushed resource, it may later use an additional HEADERS frame to augment the name/value pairs to be associated with |
|---|
| 1745 | the pushed stream. The subsequent HEADERS frame(s) must not contain a header for ':host', ':scheme', or ':path' (e.g. the |
|---|
| 1746 | server can't change the identity of the resource to be pushed). The HEADERS frame must not contain duplicate headers with |
|---|
| 1747 | a previously sent HEADERS frame. The server must send a HEADERS frame including the scheme/host/port headers before sending |
|---|
| 1748 | any data frames on the stream. |
|---|
| 1749 | </p> |
|---|
| 1750 | <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> Client implementation |
|---|
| 1751 | </h3> |
|---|
| 1752 | <p id="rfc.section.3.3.2.p.1">When fetching a resource the client has 3 possibilities: </p> |
|---|
| 1753 | <ul class="empty"> |
|---|
| 1754 | <li>the resource is not being pushed</li> |
|---|
| 1755 | <li>the resource is being pushed, but the data has not yet arrived</li> |
|---|
| 1756 | <li>the resource is being pushed, and the data has started to arrive</li> |
|---|
| 1757 | </ul> |
|---|
| 1758 | <p id="rfc.section.3.3.2.p.2">When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests |
|---|
| 1759 | for the resource in the pushed stream, and instead wait for the pushed stream to arrive. |
|---|
| 1760 | </p> |
|---|
| 1761 | <p id="rfc.section.3.3.2.p.3">If a client receives a server push stream with stream-id 0, it MUST issue a session error (<a href="#SessionErrorHandler" title="Session Error Handling">Section 2.4.1</a>) with the status code PROTOCOL_ERROR. |
|---|
| 1762 | </p> |
|---|
| 1763 | <p id="rfc.section.3.3.2.p.4">When a client receives a SYN_STREAM from the server without a the ':host', ':scheme', and ':path' headers in the Name/Value |
|---|
| 1764 | section, it MUST reply with a RST_STREAM with error code HTTP_PROTOCOL_ERROR. |
|---|
| 1765 | </p> |
|---|
| 1766 | <p id="rfc.section.3.3.2.p.5">To cancel individual server push streams, the client can issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with error code CANCEL. Upon receipt, the server MUST stop sending on this stream immediately (this is an Abrupt termination). |
|---|
| 1767 | </p> |
|---|
| 1768 | <p id="rfc.section.3.3.2.p.6">To cancel all server push streams related to a request, the client may issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames |
|---|
| 1769 | for any streams with in-association-to for the original stream. |
|---|
| 1770 | </p> |
|---|
| 1771 | <p id="rfc.section.3.3.2.p.7">If the server sends a HEADER frame containing duplicate headers with a previous HEADERS frame for the same stream, the client |
|---|
| 1772 | must issue a stream error (<a href="#StreamErrorHandler" title="Stream Error Handling">Section 2.4.2</a>) with error code PROTOCOL ERROR. |
|---|
| 1773 | </p> |
|---|
| 1774 | <p id="rfc.section.3.3.2.p.8">If the server sends a HEADERS frame after sending a data frame for the same stream, the client MAY ignore the HEADERS frame. |
|---|
| 1775 | Ignoring the HEADERS frame after a data frame prevents handling of HTTP's trailing headers (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.40). |
|---|
| 1776 | </p> |
|---|
| 1777 | <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Design Rationale and Notes |
|---|
| 1778 | </h1> |
|---|
| 1779 | <p id="rfc.section.4.p.1">Authors' notes: The notes in this section have no bearing on the SPDY protocol as specified within this document, and none |
|---|
| 1780 | of these notes should be considered authoritative about how the protocol works. However, these notes may prove useful in future |
|---|
| 1781 | debates about how to resolve protocol ambiguities or how to evolve the protocol going forward. They may be removed before |
|---|
| 1782 | the final draft. |
|---|
| 1783 | </p> |
|---|
| 1784 | <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> Separation of Framing Layer and Application Layer |
|---|
| 1785 | </h2> |
|---|
| 1786 | <p id="rfc.section.4.1.p.1">Readers may note that this specification sometimes blends the framing layer (<a href="#FramingLayer" title="SPDY Framing Layer">Section 2</a>) with requirements of a specific application - HTTP (<a href="#HTTPLayer" title="HTTP Layering over SPDY">Section 3</a>). This is reflected in the request/response nature of the streams, the definition of the HEADERS and compression contexts |
|---|
| 1787 | which are very similar to HTTP, and other areas as well. |
|---|
| 1788 | </p> |
|---|
| 1789 | <p id="rfc.section.4.1.p.2">This blending is intentional - the primary goal of this protocol is to create a low-latency protocol for use with HTTP. Isolating |
|---|
| 1790 | the two layers is convenient for description of the protocol and how it relates to existing HTTP implementations. However, |
|---|
| 1791 | the ability to reuse the SPDY framing layer is a non goal. |
|---|
| 1792 | </p> |
|---|
| 1793 | <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> Error handling - Framing Layer |
|---|
| 1794 | </h2> |
|---|
| 1795 | <p id="rfc.section.4.2.p.1">Error handling at the SPDY layer splits errors into two groups: Those that affect an individual SPDY stream, and those that |
|---|
| 1796 | do not. |
|---|
| 1797 | </p> |
|---|
| 1798 | <p id="rfc.section.4.2.p.2">When an error is confined to a single stream, but general framing is in tact, SPDY attempts to use the RST_STREAM as a mechanism |
|---|
| 1799 | to invalidate the stream but move forward without aborting the connection altogether. |
|---|
| 1800 | </p> |
|---|
| 1801 | <p id="rfc.section.4.2.p.3">For errors occuring outside of a single stream context, SPDY assumes the entire session is hosed. In this case, the endpoint |
|---|
| 1802 | detecting the error should initiate a connection close. |
|---|
| 1803 | </p> |
|---|
| 1804 | <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> One Connection Per Domain |
|---|
| 1805 | </h2> |
|---|
| 1806 | <p id="rfc.section.4.3.p.1">SPDY attempts to use fewer connections than other protocols have traditionally used. The rationale for this behavior is because |
|---|
| 1807 | it is very difficult to provide a consistent level of service (e.g. TCP slow-start), prioritization, or optimal compression |
|---|
| 1808 | when the client is connecting to the server through multiple channels. |
|---|
| 1809 | </p> |
|---|
| 1810 | <p id="rfc.section.4.3.p.2">Through lab measurements, we have seen consistent latency benefits by using fewer connections from the client. The overall |
|---|
| 1811 | number of packets sent by SPDY can be as much as 40% less than HTTP. Handling large numbers of concurrent connections on the |
|---|
| 1812 | server also does become a scalability problem, and SPDY reduces this load. |
|---|
| 1813 | </p> |
|---|
| 1814 | <p id="rfc.section.4.3.p.3">The use of multiple connections is not without benefit, however. Because SPDY multiplexes multiple, independent streams onto |
|---|
| 1815 | a single stream, it creates a potential for head-of-line blocking problems at the transport level. In tests so far, the negative |
|---|
| 1816 | effects of head-of-line blocking (especially in the presence of packet loss) is outweighed by the benefits of compression |
|---|
| 1817 | and prioritization. |
|---|
| 1818 | </p> |
|---|
| 1819 | <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> Fixed vs Variable Length Fields |
|---|
| 1820 | </h2> |
|---|
| 1821 | <p id="rfc.section.4.4.p.1">SPDY favors use of fixed length 32bit fields in cases where smaller, variable length encodings could have been used. To some, |
|---|
| 1822 | this seems like a tragic waste of bandwidth. SPDY choses the simple encoding for speed and simplicity. |
|---|
| 1823 | </p> |
|---|
| 1824 | <p id="rfc.section.4.4.p.2">The goal of SPDY is to reduce latency on the network. The overhead of SPDY frames is generally quite low. Each data frame |
|---|
| 1825 | is only an 8 byte overhead for a 1452 byte payload (~0.6%). At the time of this writing, bandwidth is already plentiful, and |
|---|
| 1826 | there is a strong trend indicating that bandwidth will continue to increase. With an average worldwide bandwidth of 1Mbps, |
|---|
| 1827 | and assuming that a variable length encoding could reduce the overhead by 50%, the latency saved by using a variable length |
|---|
| 1828 | encoding would be less than 100 nanoseconds. More interesting are the effects when the larger encodings force a packet boundary, |
|---|
| 1829 | in which case a round-trip could be induced. However, by addressing other aspects of SPDY and TCP interactions, we believe |
|---|
| 1830 | this is completely mitigated. |
|---|
| 1831 | </p> |
|---|
| 1832 | <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> Compression Context(s) |
|---|
| 1833 | </h2> |
|---|
| 1834 | <p id="rfc.section.4.5.p.1">When isolating the compression contexts used for communicating with multiple origins, we had a few choices to make. We could |
|---|
| 1835 | have maintained a map (or list) of compression contexts usable for each origin. The basic case is easy - each HEADERS frame |
|---|
| 1836 | would need to identify the context to use for that frame. However, compression contexts are not cheap, so the lifecycle of |
|---|
| 1837 | each context would need to be bounded. For proxy servers, where we could churn through many contexts, this would be a concern. |
|---|
| 1838 | We considered using a static set of contexts, say 16 of them, which would bound the memory use. We also considered dynamic |
|---|
| 1839 | contexts, which could be created on the fly, and would need to be subsequently destroyed. All of these are complicated, and |
|---|
| 1840 | ultimately we decided that such a mechanism creates too many problems to solve. |
|---|
| 1841 | </p> |
|---|
| 1842 | <p id="rfc.section.4.5.p.2">Alternatively, we've chosen the simple approach, which is to simply provide a flag for resetting the compression context. |
|---|
| 1843 | For the common case (no proxy), this fine because most requests are to the same origin and we never need to reset the context. |
|---|
| 1844 | For cases where we are using two different origins over a single SPDY session, we simply reset the compression state between |
|---|
| 1845 | each transition. |
|---|
| 1846 | </p> |
|---|
| 1847 | <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a> Unidirectional streams |
|---|
| 1848 | </h2> |
|---|
| 1849 | <p id="rfc.section.4.6.p.1">Many readers notice that unidirectional streams are both a bit confusing in concept and also somewhat redundant. If the recipient |
|---|
| 1850 | of a stream doesn't wish to send data on a stream, it could simply send a SYN_REPLY with the FLAG_FIN bit set. The FLAG_UNIDIRECTIONAL |
|---|
| 1851 | is, therefore, not necessary. |
|---|
| 1852 | </p> |
|---|
| 1853 | <p id="rfc.section.4.6.p.2">It is true that we don't need the UNIDIRECTIONAL markings. It is added because it avoids the recipient of pushed streams from |
|---|
| 1854 | needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose. |
|---|
| 1855 | </p> |
|---|
| 1856 | <h2 id="rfc.section.4.7"><a href="#rfc.section.4.7">4.7</a> Data Compression |
|---|
| 1857 | </h2> |
|---|
| 1858 | <p id="rfc.section.4.7.p.1">Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content |
|---|
| 1859 | of the stream is redundant. There is no value in compressing a stream which is already compressed. Because of this, SPDY does |
|---|
| 1860 | allow data compression to be optional. We included it because study of existing websites shows that many sites are not using |
|---|
| 1861 | compression as they should, and users suffer because of it. We wanted a mechanism where, at the SPDY layer, site administrators |
|---|
| 1862 | could simply force compression - it is better to compress twice than to not compress. |
|---|
| 1863 | </p> |
|---|
| 1864 | <p id="rfc.section.4.7.p.2">Overall, however, with this feature being optional and sometimes redundant, it is unclear if it is useful at all. We will |
|---|
| 1865 | likely remove it from the specification. |
|---|
| 1866 | </p> |
|---|
| 1867 | <h2 id="rfc.section.4.8"><a href="#rfc.section.4.8">4.8</a> Server Push |
|---|
| 1868 | </h2> |
|---|
| 1869 | <p id="rfc.section.4.8.p.1">A subtle but important point is that server push streams must be declared before the associated stream is closed. The reason |
|---|
| 1870 | for this is so that proxies have a lifetime for which they can discard information about previous streams. If a pushed stream |
|---|
| 1871 | could associate itself with an already-closed stream, then endpoints would not have a specific lifecycle for when they could |
|---|
| 1872 | disavow knowledge of the streams which went before. |
|---|
| 1873 | </p> |
|---|
| 1874 | <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Security Considerations |
|---|
| 1875 | </h1> |
|---|
| 1876 | <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> Use of Same-origin constraints |
|---|
| 1877 | </h2> |
|---|
| 1878 | <p id="rfc.section.5.1.p.1">This specification uses the <a href="#RFC6454">same-origin policy</a> <cite title="The Web Origin Concept" id="rfc.xref.RFC6454.4">[RFC6454]</cite> in all cases where verification of content is required. |
|---|
| 1879 | </p> |
|---|
| 1880 | <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> HTTP Headers and SPDY Headers |
|---|
| 1881 | </h2> |
|---|
| 1882 | <p id="rfc.section.5.2.p.1">At the application level, HTTP uses name/value pairs in its headers. Because SPDY merges the existing HTTP headers with SPDY |
|---|
| 1883 | headers, there is a possibility that some HTTP applications already use a particular header name. To avoid any conflicts, |
|---|
| 1884 | all headers introduced for layering HTTP over SPDY are prefixed with ":". ":" is not a valid sequence in HTTP header naming, |
|---|
| 1885 | preventing any possible conflict. |
|---|
| 1886 | </p> |
|---|
| 1887 | <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> Cross-Protocol Attacks |
|---|
| 1888 | </h2> |
|---|
| 1889 | <p id="rfc.section.5.3.p.1">By utilizing TLS, we believe that SPDY introduces no new cross-protocol attacks. TLS encrypts the contents of all transmission |
|---|
| 1890 | (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol |
|---|
| 1891 | attack. |
|---|
| 1892 | </p> |
|---|
| 1893 | <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> Server Push Implicit Headers |
|---|
| 1894 | </h2> |
|---|
| 1895 | <p id="rfc.section.5.4.p.1">Pushed resources do not have an associated request. In order for existing HTTP cache control validations (such as the Vary |
|---|
| 1896 | header) to work, however, all cached resources must have a set of request headers. For this reason, browsers MUST be careful |
|---|
| 1897 | to inherit request headers from the associated stream for the push. This includes the 'Cookie' header. |
|---|
| 1898 | </p> |
|---|
| 1899 | <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> Privacy Considerations |
|---|
| 1900 | </h1> |
|---|
| 1901 | <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> Long Lived Connections |
|---|
| 1902 | </h2> |
|---|
| 1903 | <p id="rfc.section.6.1.p.1">SPDY aims to keep connections open longer between clients and servers in order to reduce the latency when a user makes a request. |
|---|
| 1904 | The maintenance of these connections over time could be used to expose private information. For example, a user using a browser |
|---|
| 1905 | hours after the previous user stopped using that browser may be able to learn about what the previous user was doing. This |
|---|
| 1906 | is a problem with HTTP in its current form as well, however the short lived connections make it less of a risk. |
|---|
| 1907 | </p> |
|---|
| 1908 | <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> SETTINGS frame |
|---|
| 1909 | </h2> |
|---|
| 1910 | <p id="rfc.section.6.2.p.1">The SPDY SETTINGS frame allows servers to store out-of-band transmitted information about the communication between client |
|---|
| 1911 | and server on the client. Although this is intended only to be used to reduce latency, renegade servers could use it as a |
|---|
| 1912 | mechanism to store identifying information about the client in future requests. |
|---|
| 1913 | </p> |
|---|
| 1914 | <p id="rfc.section.6.2.p.2">Clients implementing privacy modes, such as Google Chrome's "incognito mode", may wish to disable client-persisted SETTINGS |
|---|
| 1915 | storage. |
|---|
| 1916 | </p> |
|---|
| 1917 | <p id="rfc.section.6.2.p.3">Clients MUST clear persisted SETTINGS information when clearing the cookies.</p> |
|---|
| 1918 | <p id="rfc.section.6.2.p.4">TODO: Put range maximums on each type of setting to limit inappropriate uses.</p> |
|---|
| 1919 | <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Incompatibilities with SPDY draft #2 |
|---|
| 1920 | </h1> |
|---|
| 1921 | <p id="rfc.section.7.p.1">Here is a list of the major changes between this draft and draft #2. </p> |
|---|
| 1922 | <ul class="empty"> |
|---|
| 1923 | <li>Addition of flow control</li> |
|---|
| 1924 | <li>Increased 16 bit length fields in SYN_STREAM and SYN_REPLY to 32 bits.</li> |
|---|
| 1925 | <li>Changed definition of compression for DATA frames</li> |
|---|
| 1926 | <li>Updated compression dictionary</li> |
|---|
| 1927 | <li>Fixed off-by-one on the compression dictionary for headers</li> |
|---|
| 1928 | <li>Increased priority field from 2bits to 3bits.</li> |
|---|
| 1929 | <li>Removed NOOP frame</li> |
|---|
| 1930 | <li>Split the request "url" into "scheme", "host", and "path"</li> |
|---|
| 1931 | <li>Added the requirement that POSTs contain content-length.</li> |
|---|
| 1932 | <li>Removed wasted 16bits of unused space from the end of the SYN_REPLY and HEADERS frames.</li> |
|---|
| 1933 | <li>Fixed bug: Priorities were described backward (0 was lowest instead of highest).</li> |
|---|
| 1934 | <li>Fixed bug: Name/Value header counts were duplicated in both the Name Value header block and also the containing frame.</li> |
|---|
| 1935 | </ul> |
|---|
| 1936 | <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> Requirements Notation |
|---|
| 1937 | </h1> |
|---|
| 1938 | <p id="rfc.section.8.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" |
|---|
| 1939 | in this document are to be interpreted as described in <a href="#RFC2119">RFC 2119</a> <cite title="Key words for use in RFCs to Indicate Requirement Levels" id="rfc.xref.RFC2119.1">[RFC2119]</cite>. |
|---|
| 1940 | </p> |
|---|
| 1941 | <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Acknowledgements |
|---|
| 1942 | </h1> |
|---|
| 1943 | <p id="rfc.section.9.p.1">Many individuals have contributed to the design and evolution of SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, |
|---|
| 1944 | Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, |
|---|
| 1945 | Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton. |
|---|
| 1946 | </p> |
|---|
| 1947 | <h1 id="rfc.references"><a href="#rfc.section.10" id="rfc.section.10">10.</a> Normative References |
|---|
| 1948 | </h1> |
|---|
| 1949 | <table> |
|---|
| 1950 | <tr> |
|---|
| 1951 | <td class="reference"><b id="ASCII">[ASCII]</b></td> |
|---|
| 1952 | <td class="top">“US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.”.</td> |
|---|
| 1953 | </tr> |
|---|
| 1954 | <tr> |
|---|
| 1955 | <td class="reference"><b id="RFC0793">[RFC0793]</b></td> |
|---|
| 1956 | <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc793">Transmission Control Protocol</a>”, STD 7, RFC 793, September 1981. |
|---|
| 1957 | </td> |
|---|
| 1958 | </tr> |
|---|
| 1959 | <tr> |
|---|
| 1960 | <td class="reference"><b id="RFC1738">[RFC1738]</b></td> |
|---|
| 1961 | <td class="top">Berners-Lee, T., Masinter, L., and M. McCahill, “<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>”, RFC 1738, December 1994. |
|---|
| 1962 | </td> |
|---|
| 1963 | </tr> |
|---|
| 1964 | <tr> |
|---|
| 1965 | <td class="reference"><b id="RFC1950">[RFC1950]</b></td> |
|---|
| 1966 | <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996. |
|---|
| 1967 | </td> |
|---|
| 1968 | </tr> |
|---|
| 1969 | <tr> |
|---|
| 1970 | <td class="reference"><b id="RFC2119">[RFC2119]</b></td> |
|---|
| 1971 | <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. |
|---|
| 1972 | </td> |
|---|
| 1973 | </tr> |
|---|
| 1974 | <tr> |
|---|
| 1975 | <td class="reference"><b id="RFC2285">[RFC2285]</b></td> |
|---|
| 1976 | <td class="top">Mandeville, R., “<a href="http://tools.ietf.org/html/rfc2285">Benchmarking Terminology for LAN Switching Devices</a>”, RFC 2285, February 1998. |
|---|
| 1977 | </td> |
|---|
| 1978 | </tr> |
|---|
| 1979 | <tr> |
|---|
| 1980 | <td class="reference"><b id="RFC2616">[RFC2616]</b></td> |
|---|
| 1981 | <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. |
|---|
| 1982 | </td> |
|---|
| 1983 | </tr> |
|---|
| 1984 | <tr> |
|---|
| 1985 | <td class="reference"><b id="RFC2617">[RFC2617]</b></td> |
|---|
| 1986 | <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. |
|---|
| 1987 | </td> |
|---|
| 1988 | </tr> |
|---|
| 1989 | <tr> |
|---|
| 1990 | <td class="reference"><b id="RFC4366">[RFC4366]</b></td> |
|---|
| 1991 | <td class="top">Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “<a href="http://tools.ietf.org/html/rfc4366">Transport Layer Security (TLS) Extensions</a>”, RFC 4366, April 2006. |
|---|
| 1992 | </td> |
|---|
| 1993 | </tr> |
|---|
| 1994 | <tr> |
|---|
| 1995 | <td class="reference"><b id="RFC4559">[RFC4559]</b></td> |
|---|
| 1996 | <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="http://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC 4559, June 2006. |
|---|
| 1997 | </td> |
|---|
| 1998 | </tr> |
|---|
| 1999 | <tr> |
|---|
| 2000 | <td class="reference"><b id="RFC5246">[RFC5246]</b></td> |
|---|
| 2001 | <td class="top">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>”, RFC 5246, August 2008. |
|---|
| 2002 | </td> |
|---|
| 2003 | </tr> |
|---|
| 2004 | <tr> |
|---|
| 2005 | <td class="reference"><b id="RFC6454">[RFC6454]</b></td> |
|---|
| 2006 | <td class="top">Barth, A., “<a href="http://tools.ietf.org/html/rfc6454">The Web Origin Concept</a>”, RFC 6454, December 2011. |
|---|
| 2007 | </td> |
|---|
| 2008 | </tr> |
|---|
| 2009 | <tr> |
|---|
| 2010 | <td class="reference"><b id="TLSNPN">[TLSNPN]</b></td> |
|---|
| 2011 | <td class="top">Langley, A., “<a href="http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-01">TLS Next Protocol Negotiation</a>”, Internet-Draft draft-agl-tls-nextprotoneg-01 (work in progress), August 2010. |
|---|
| 2012 | </td> |
|---|
| 2013 | </tr> |
|---|
| 2014 | <tr> |
|---|
| 2015 | <td class="reference"><b id="UDELCOMPRESSION">[UDELCOMPRESSION]</b></td> |
|---|
| 2016 | <td class="top">Yang, F., Amer, P., and J. Leighton, “<a href="http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf">A Methodology to Derive SPDY's Initial Dictionary for Zlib Compression</a>”, <<a href="http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf">http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf</a>>. |
|---|
| 2017 | </td> |
|---|
| 2018 | </tr> |
|---|
| 2019 | </table> |
|---|
| 2020 | <div class="avoidbreak"> |
|---|
| 2021 | <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> |
|---|
| 2022 | <address class="vcard"><span class="vcardline"><span class="fn">Mike Belshe</span><span class="n hidden"><span class="family-name">Belshe</span><span class="given-name">Mike</span></span></span><span class="org vcardline">Twist</span><span class="vcardline">Email: <a href="mailto:mbelshe@chromium.org"><span class="email">mbelshe@chromium.org</span></a></span></address> |
|---|
| 2023 | <address class="vcard"><span class="vcardline"><span class="fn">Roberto Peon</span><span class="n hidden"><span class="family-name">Peon</span><span class="given-name">Roberto</span></span></span><span class="org vcardline">Google, Inc</span><span class="vcardline">Email: <a href="mailto:fenix@google.com"><span class="email">fenix@google.com</span></a></span></address> |
|---|
| 2024 | <address class="vcard"><span class="vcardline"><span class="fn">Martin Thomson</span> |
|---|
| 2025 | (editor) |
|---|
| 2026 | <span class="n hidden"><span class="family-name">Thomson</span><span class="given-name">Martin</span></span></span><span class="org vcardline">Microsoft</span><span class="adr"><span class="street-address vcardline">3210 Porter Drive</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="postal-code">94043</span></span><span class="country-name vcardline">US</span></span><span class="vcardline">Email: <a href="mailto:martin.thomson@skype.net"><span class="email">martin.thomson@skype.net</span></a></span></address> |
|---|
| 2027 | <address class="vcard"><span class="vcardline"><span class="fn">Alexey Melnikov</span> |
|---|
| 2028 | (editor) |
|---|
| 2029 | <span class="n hidden"><span class="family-name">Melnikov</span><span class="given-name">Alexey</span></span></span><span class="org vcardline">Isode Ltd</span><span class="adr"><span class="street-address vcardline">5 Castle Business Village</span><span class="street-address vcardline">36 Station Road</span><span class="vcardline"><span class="locality">Hampton</span>, <span class="region">Middlesex</span> <span class="postal-code">TW12 2BX</span></span><span class="country-name vcardline">UK</span></span><span class="vcardline">Email: <a href="mailto:Alexey.Melnikov@isode.com"><span class="email">Alexey.Melnikov@isode.com</span></a></span></address> |
|---|
| 2030 | </div> |
|---|
| 2031 | <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> |
|---|
| 2032 | <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.since.draft-ietf-httpbis-http2-00" href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></h2> |
|---|
| 2033 | <p id="rfc.section.A.1.p.1">None yet.</p> |
|---|
| 2034 | <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2> |
|---|
| 2035 | <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p> |
|---|
| 2036 | <p id="rfc.section.A.2.p.2">Updated authors/editors list.</p> |
|---|
| 2037 | <p id="rfc.section.A.2.p.3">Added status note.</p> |
|---|
| 2038 | <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> |
|---|
| 2039 | <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> |
|---|
| 2040 | </p> |
|---|
| 2041 | <div class="print2col"> |
|---|
| 2042 | <ul class="ind"> |
|---|
| 2043 | <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> |
|---|
| 2044 | <li><em>ASCII</em> <a href="#rfc.xref.ASCII.1">2.6.10</a>, <a href="#ASCII"><b>10</b></a></li> |
|---|
| 2045 | </ul> |
|---|
| 2046 | </li> |
|---|
| 2047 | <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> |
|---|
| 2048 | <li><em>RFC0793</em> <a href="#rfc.xref.RFC0793.1">2.1</a>, <a href="#RFC0793"><b>10</b></a></li> |
|---|
| 2049 | <li><em>RFC1738</em> <a href="#rfc.xref.RFC1738.1">3.2.1</a>, <a href="#rfc.xref.RFC1738.2">3.2.1</a>, <a href="#RFC1738"><b>10</b></a></li> |
|---|
| 2050 | <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">2.6.10.1</a>, <a href="#RFC1950"><b>10</b></a></li> |
|---|
| 2051 | <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">8</a>, <a href="#RFC2119"><b>10</b></a></li> |
|---|
| 2052 | <li><em>RFC2285</em> <a href="#RFC2285"><b>10</b></a></li> |
|---|
| 2053 | <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">§</a>, <a href="#rfc.xref.RFC2616.2">3</a>, <a href="#RFC2616"><b>10</b></a></li> |
|---|
| 2054 | <li><em>RFC2617</em> <a href="#rfc.xref.RFC2617.1">3.2.3</a>, <a href="#RFC2617"><b>10</b></a></li> |
|---|
| 2055 | <li><em>RFC4366</em> <a href="#RFC4366"><b>10</b></a></li> |
|---|
| 2056 | <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">3.2.3</a>, <a href="#RFC4559"><b>10</b></a></li> |
|---|
| 2057 | <li><em>RFC5246</em> <a href="#rfc.xref.RFC5246.1">2.6.9</a>, <a href="#RFC5246"><b>10</b></a><ul> |
|---|
| 2058 | <li><em>Section 4.7</em> <a href="#rfc.xref.RFC5246.1">2.6.9</a></li> |
|---|
| 2059 | </ul> |
|---|
| 2060 | </li> |
|---|
| 2061 | <li><em>RFC6454</em> <a href="#rfc.xref.RFC6454.1">2.6.4</a>, <a href="#rfc.xref.RFC6454.2">3.1</a>, <a href="#rfc.xref.RFC6454.3">3.3</a>, <a href="#rfc.xref.RFC6454.4">5.1</a>, <a href="#RFC6454"><b>10</b></a></li> |
|---|
| 2062 | </ul> |
|---|
| 2063 | </li> |
|---|
| 2064 | <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> |
|---|
| 2065 | <li><em>TLSNPN</em> <a href="#TLSNPN"><b>10</b></a></li> |
|---|
| 2066 | </ul> |
|---|
| 2067 | </li> |
|---|
| 2068 | <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> |
|---|
| 2069 | <li><em>UDELCOMPRESSION</em> <a href="#rfc.xref.UDELCOMPRESSION.1">2.6.10.1</a>, <a href="#UDELCOMPRESSION"><b>10</b></a></li> |
|---|
| 2070 | </ul> |
|---|
| 2071 | </li> |
|---|
| 2072 | </ul> |
|---|
| 2073 | </div> |
|---|
| 2074 | </body> |
|---|
| 2075 | </html> |
|---|
![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
