HTTP 2

11/02/2015
HypertextTransferProtocolversion2
HTTPbisWorkingGroup
InternetDraft
Intendedstatus:StandardsTrack
Expires:August14,2015
M.Belshe
Twist
R.Peon
Google,Inc
M.Thomson,Editor
Mozilla
February10,2015
draftietfhttpbishttp2latest
Abstract
ThisspecificationdescribesanoptimizedexpressionofthesemanticsoftheHypertextTransfer
Protocol(HTTP).HTTP/2enablesamoreefficientuseofnetworkresourcesandareducedperception
oflatencybyintroducingheaderfieldcompressionandallowingmultipleconcurrentexchangesonthe
sameconnection.Italsointroducesunsolicitedpushofrepresentationsfromserverstoclients.
Thisspecificationisanalternativeto,butdoesnotobsolete,theHTTP/1.1messagesyntax.HTTP's
existingsemanticsremainunchanged.
EditorialNote(ToberemovedbyRFCEditor)
DiscussionofthisdrafttakesplaceontheHTTPBISworkinggroupmailinglist(ietfhttpwg@w3.org),
whichisarchivedat<https://lists.w3.org/Archives/Public/ietfhttpwg/>.
WorkingGroupinformationcanbefoundat<https://tools.ietf.org/wg/httpbis/>;thatspecificto
HTTP/2areat<https://http2.github.io/>.
ThechangesinthisdraftaresummarizedinAppendixB.
StatusofThisMemo
ThisInternetDraftissubmittedinfullconformancewiththeprovisionsofBCP78andBCP79.
InternetDraftsareworkingdocumentsoftheInternetEngineeringTaskForce(IETF).Notethatother
groupsmayalsodistributeworkingdocumentsasInternetDrafts.ThelistofcurrentInternetDraftsis
athttp://datatracker.ietf.org/drafts/current/.
InternetDraftsaredraftdocumentsvalidforamaximumofsixmonthsandmaybeupdated,replaced,
orobsoletedbyotherdocumentsatanytime.ItisinappropriatetouseInternetDraftsasreference
materialortocitethemotherthanasworkinprogress.
ThisInternetDraftwillexpireonAugust14,2015.
CopyrightNotice
Copyright2015IETFTrustandthepersonsidentifiedasthedocumentauthors.Allrightsreserved.
https://http2.github.io/http2spec/
1/65
11/02/2015
ThisdocumentissubjecttoBCP78andtheIETFTrust'sLegalProvisionsRelatingtoIETFDocuments
(http://trustee.ietf.org/licenseinfo)ineffectonthedateofpublicationofthisdocument.Please
reviewthesedocumentscarefully,astheydescribeyourrightsandrestrictionswithrespecttothis
document.CodeComponentsextractedfromthisdocumentmustincludeSimplifiedBSDLicensetext
asdescribedinSection4.eoftheTrustLegalProvisionsandareprovidedwithoutwarrantyas
describedintheSimplifiedBSDLicense.
2/65
11/02/2015
TableofContents
1. Introduction
2. HTTP/2ProtocolOverview
3.
4.
5.
6.
7.
8.
2.1DocumentOrganization
2.2ConventionsandTerminology
StartingHTTP/2
3.1HTTP/2VersionIdentification
3.2StartingHTTP/2for"http"URIs
3.2.1HTTP2SettingsHeaderField
3.3StartingHTTP/2for"https"URIs
3.4StartingHTTP/2withPriorKnowledge
3.5HTTP/2ConnectionPreface
HTTPFrames
4.1FrameFormat
4.2FrameSize
4.3HeaderCompressionandDecompression
StreamsandMultiplexing
5.1StreamStates
5.1.1StreamIdentifiers
5.1.2StreamConcurrency
5.2FlowControl
5.2.1FlowControlPrinciples
5.2.2AppropriateUseofFlowControl
5.3Streampriority
5.3.1StreamDependencies
5.3.2DependencyWeighting
5.3.3Reprioritization
5.3.4PrioritizationStateManagement
5.3.5DefaultPriorities
5.4ErrorHandling
5.4.1ConnectionErrorHandling
5.4.2StreamErrorHandling
5.4.3ConnectionTermination
5.5ExtendingHTTP/2
FrameDefinitions
6.1DATA
6.2HEADERS
6.3PRIORITY
6.4RST_STREAM
6.5SETTINGS
6.5.1SETTINGSFormat
6.5.2DefinedSETTINGSParameters
6.5.3SettingsSynchronization
6.6PUSH_PROMISE
6.7PING
6.8GOAWAY
6.9WINDOW_UPDATE
6.9.1TheFlowControlWindow
6.9.2InitialFlowControlWindowSize
6.9.3ReducingtheStreamWindowSize
6.10CONTINUATION
ErrorCodes
HTTPMessageExchanges
8.1HTTPRequest/ResponseExchange
3/65
11/02/2015
8.1.1UpgradingFromHTTP/2
8.1.2HTTPHeaderFields
8.1.3Examples
8.1.4RequestReliabilityMechanismsinHTTP/2
8.2ServerPush
8.2.1PushRequests
8.2.2PushResponses
8.3TheCONNECTMethod
9. AdditionalHTTPRequirements/Considerations
9.1ConnectionManagement
9.1.1ConnectionReuse
9.1.2The421(MisdirectedRequest)StatusCode
9.2UseofTLSFeatures
9.2.1TLS1.2Features
9.2.2TLS1.2CipherSuites
10.SecurityConsiderations
10.1ServerAuthority
10.2CrossProtocolAttacks
10.3IntermediaryEncapsulationAttacks
10.4CacheabilityofPushedResponses
10.5DenialofServiceConsiderations
10.5.1LimitsonHeaderBlockSize
10.5.2CONNECTIssues
10.6UseofCompression
10.7UseofPadding
10.8PrivacyConsiderations
11.IANAConsiderations
11.1RegistrationofHTTP/2IdentificationStrings
11.2FrameTypeRegistry
11.3SettingsRegistry
11.4ErrorCodeRegistry
11.5HTTP2SettingsHeaderFieldRegistration
11.6PRIMethodRegistration
11.7The421(MisdirectedRequest)HTTPStatusCode
12.Acknowledgements
13.References
13.1NormativeReferences
13.2InformativeReferences
A. TLS1.2CipherSuiteBlackList
B. ChangeLog
B.1Sincedraftietfhttpbishttp215
4/65
11/02/2015
B.17Sincedraftmbelshehttpbisspdy00
Authors'Addresses
Figures
Figure1:FrameLayout
Figure2:StreamStates
Figure3:ExampleofDefaultDependencyCreation
Figure4:ExampleofExclusiveDependencyCreation
Figure5:ExampleofDependencyReordering
Figure6:DATAFramePayload
Figure7:HEADERSFramePayload
Figure8:PRIORITYFramePayload
Figure9:RST_STREAMFramePayload
Figure10:SettingFormat
Figure11:PUSH_PROMISEPayloadFormat
Figure12:PINGPayloadFormat
Figure13:GOAWAYPayloadFormat
Figure14:WINDOW_UPDATEPayloadFormat
Figure15:CONTINUATIONFramePayload
5/65
11/02/2015
1.Introduction
TheHypertextTransferProtocol(HTTP)isawildlysuccessfulprotocol.However,howHTTP/1.1uses
theunderlyingtransport([RFC7230],Section6)hasseveralcharacteristicsthathaveanegative
overalleffectonapplicationperformancetoday.
Inparticular,HTTP/1.0allowedonlyonerequesttobeoutstandingatatimeonagivenTCP
connection.HTTP/1.1addedrequestpipelining,butthisonlypartiallyaddressedrequestconcurrency
andstillsuffersfromheadoflineblocking.Therefore,HTTP/1.0andHTTP/1.1clientsthatneedto
makemanyrequestsusemultipleconnectionstoaserverinordertoachieveconcurrencyandthereby
reducelatency.
Furthermore,HTTPheaderfieldsareoftenrepetitiveandverbose,causingunnecessarynetwork
traffic,aswellascausingtheinitialTCP[TCP]congestionwindowtoquicklyfill.Thiscanresultin
excessivelatencywhenmultiplerequestsaremadeonanewTCPconnection.
HTTP/2addressestheseissuesbydefininganoptimizedmappingofHTTP'ssemanticstoan
underlyingconnection.Specifically,itallowsinterleavingofrequestandresponsemessagesonthe
sameconnectionandusesanefficientcodingforHTTPheaderfields.Italsoallowsprioritizationof
requests,lettingmoreimportantrequestscompletemorequickly,furtherimprovingperformance.
Theresultingprotocolismorefriendlytothenetwork,becausefewerTCPconnectionscanbeusedin
comparisontoHTTP/1.x.Thismeanslesscompetitionwithotherflows,andlongerlivedconnections,
whichinturnleadstobetterutilizationofavailablenetworkcapacity.
Finally,HTTP/2alsoenablesmoreefficientprocessingofmessagesthroughuseofbinarymessage
framing.
2.HTTP/2ProtocolOverview
HTTP/2providesanoptimizedtransportforHTTPsemantics.HTTP/2supportsallofthecorefeatures
ofHTTP/1.1,butaimstobemoreefficientinseveralways.
ThebasicprotocolunitinHTTP/2isaframe(Section4.1).Eachframetypeservesadifferentpurpose.
Forexample,HEADERSandDATAframesformthebasisofHTTPrequestsandresponses(Section8.1);
otherframetypeslikeSETTINGS,WINDOW_UPDATE,andPUSH_PROMISEareusedinsupportofother
HTTP/2features.
MultiplexingofrequestsisachievedbyhavingeachHTTPrequestresponseexchangeassociatedwith
itsownstream(Section5).Streamsarelargelyindependentofeachother,soablockedorstalled
requestorresponsedoesnotpreventprogressonotherstreams.
Flowcontrolandprioritizationensurethatitispossibletoefficientlyusemultiplexedstreams.Flow
control(Section5.2)helpstoensurethatonlydatathatcanbeusedbyareceiveristransmitted.
Prioritization(Section5.3)ensuresthatlimitedresourcescanbedirectedtothemostimportant
streamsfirst.
HTTP/2addsanewinteractionmode,wherebyaservercanpushresponsestoaclient(Section8.2).
Serverpushallowsaservertospeculativelysenddatatoaclientthattheserveranticipatestheclient
willneed,tradingoffsomenetworkusageagainstapotentiallatencygain.Theserverdoesthisby
synthesizingarequest,whichitsendsasaPUSH_PROMISEframe.Theserveristhenabletosenda
responsetothesyntheticrequestonaseparatestream.
6/65
11/02/2015
BecauseHTTPheaderfieldsusedinaconnectioncancontainlargeamountsofredundantdata,frames
thatcontainthemarecompressed(Section4.3).Thishasespeciallyadvantageousimpactuponrequest
sizesinthecommoncase,allowingmanyrequeststobecompressedintoonepacket.
2.1DocumentOrganization
TheHTTP/2specificationissplitintofourparts:
StartingHTTP/2(Section3)covershowanHTTP/2connectionisinitiated.
Theframing(Section4)andstreams(Section5)layersdescribethewayHTTP/2framesare
structuredandformedintomultiplexedstreams.
Frame(Section6)anderror(Section7)definitionsincludedetailsoftheframeanderrortypes
usedinHTTP/2.
HTTPmappings(Section8)andadditionalrequirements(Section9)describehowHTTP
semanticsareexpressedusingframesandstreams.
WhilesomeoftheframeandstreamlayerconceptsareisolatedfromHTTP,thisspecificationdoesnot
defineacompletelygenericframinglayer.Theframingandstreamslayersaretailoredtotheneedsof
theHTTPprotocolandserverpush.
2.2ConventionsandTerminology
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SHOULD
NOT","RECOMMENDED","MAY",and"OPTIONAL"inthisdocumentaretobeinterpretedasdescribed
inRFC2119[RFC2119].
Allnumericvaluesareinnetworkbyteorder.Valuesareunsignedunlessotherwiseindicated.Literal
valuesareprovidedindecimalorhexadecimalasappropriate.Hexadecimalliteralsareprefixedwith
0xtodistinguishthemfromdecimalliterals.
Thefollowingtermsareused:
client: TheendpointthatinitiatesanHTTP/2connection.ClientssendHTTPrequestsandreceive
HTTPresponses.
connection: Atransportlayerconnectionbetweentwoendpoints.
connectionerror: AnerrorthataffectstheentireHTTP/2connection.
endpoint: Eithertheclientorserveroftheconnection.
frame: ThesmallestunitofcommunicationwithinanHTTP/2connection,consistingofaheaderanda
variablelengthsequenceofoctetsstructuredaccordingtotheframetype.
peer: Anendpoint.Whendiscussingaparticularendpoint,"peer"referstotheendpointthatisremote
totheprimarysubjectofdiscussion.
receiver: Anendpointthatisreceivingframes.
sender: Anendpointthatistransmittingframes.
server: TheendpointthatacceptsanHTTP/2connection.ServersreceiveHTTPrequestsandserve
HTTPresponses.
stream: AbidirectionalflowofframeswithintheHTTP/2connection.
streamerror: AnerrorontheindividualHTTP/2stream.
Finally,theterms"gateway","intermediary","proxy",and"tunnel"aredefinedinSection2.3of
7/65
11/02/2015
[RFC7230].Intermediariesactasbothclientandserveratdifferenttimes.
Theterm"payloadbody"isdefinedinSection3.3of[RFC7230].
3.StartingHTTP/2
AnHTTP/2connectionisanapplicationlayerprotocolrunningontopofaTCPconnection([TCP]).
TheclientistheTCPconnectioninitiator.
HTTP/2usesthesame"http"and"https"URIschemesusedbyHTTP/1.1.HTTP/2sharesthesame
defaultportnumbers:80for"http"URIsand443for"https"URIs.Asaresult,implementations
processingrequestsfortargetresourceURIslikehttp://example.org/fooor
https://example.com/bararerequiredtofirstdiscoverwhethertheupstreamserver(the
immediatepeertowhichtheclientwishestoestablishaconnection)supportsHTTP/2.
ThemeansbywhichsupportforHTTP/2isdeterminedisdifferentfor"http"and"https"URIs.
Discoveryfor"http"URIsisdescribedinSection3.2.Discoveryfor"https"URIsisdescribedin
Section3.3.
3.1HTTP/2VersionIdentification
Theprotocoldefinedinthisdocumenthastwoidentifiers.
Thestring"h2"identifiestheprotocolwhereHTTP/2usesTLS[TLS12].Thisidentifierisusedin
theTLSapplicationlayerprotocolnegotiationextension(ALPN)[TLSALPN]fieldandinanyplace
whereHTTP/2overTLSisidentified.
The"h2"stringisserializedintoanALPNprotocolidentifierasthetwooctetsequence:0x68,
0x32.
Thestring"h2c"identifiestheprotocolwhereHTTP/2isrunovercleartextTCP.Thisidentifieris
usedintheHTTP/1.1UpgradeheaderfieldandinanyplacewhereHTTP/2overTCPisidentified.
The"h2c"stringisreservedfromtheALPNidentifierspace,butdescribesaprotocolthatdoesnot
useTLS.
Negotiating"h2"or"h2c"impliestheuseofthetransport,security,framingandmessagesemantics
describedinthisdocument.
[rfc.comment.1:RFCEditor'sNote:pleaseremovetheremainderofthissectionpriortothepublication
ofafinalversionofthisdocument.]
Onlyimplementationsofthefinal,publishedRFCcanidentifythemselvesas"h2"or"h2c".Untilsuch
anRFCexists,implementationsMUSTNOTidentifythemselvesusingthesestrings.
ImplementationsofdraftversionsoftheprotocolMUSTaddthestring""andthecorrespondingdraft
numbertotheidentifier.Forexample,draftietfhttpbishttp211overTLSisidentifiedusingthestring
"h211".
NoncompatibleexperimentsthatarebasedonthesedraftversionsMUSTappendthestring""andan
experimentnametotheidentifier.Forexample,anexperimentalimplementationofpacketmood
basedencodingbasedondraftietfhttpbishttp209mightidentifyitselfas"h209emo".Notethatany
labelMUSTconformtothe"token"syntaxdefinedinSection3.2.6of[RFC7230].Experimentersare
encouragedtocoordinatetheirexperimentsontheietfhttpwg@w3.orgmailinglist.
8/65
11/02/2015
3.2StartingHTTP/2for"http"URIs
Aclientthatmakesarequestforan"http"URIwithoutpriorknowledgeaboutsupportforHTTP/2on
thenexthopusestheHTTPUpgrademechanism(Section6.7of[RFC7230]).Theclientdoessoby
makinganHTTP/1.1requestthatincludesanUpgradeheaderfieldwiththe"h2c"token.Suchan
HTTP/1.1requestMUSTincludeexactlyoneHTTP2Settings(Section3.2.1)headerfield.
Forexample:
GET/HTTP/1.1
Host:server.example.com
Connection:Upgrade,HTTP2Settings
Upgrade:h2c
HTTP2Settings:<base64urlencodingofHTTP/2SETTINGSpayload>
RequeststhatcontainanpayloadbodyMUSTbesentintheirentiretybeforetheclientcansend
HTTP/2frames.Thismeansthatalargerequestcanblocktheuseoftheconnectionuntilitis
completelysent.
Ifconcurrencyofaninitialrequestwithsubsequentrequestsisimportant,anOPTIONSrequestcanbe
usedtoperformtheupgradetoHTTP/2,atthecostofanadditionalroundtrip.
AserverthatdoesnotsupportHTTP/2canrespondtotherequestasthoughtheUpgradeheaderfield
wereabsent:
HTTP/1.1200OK
ContentLength:243
ContentType:text/html
...
AserverMUSTignorean"h2"tokeninanUpgradeheaderfield.Presenceofatokenwith"h2"implies
HTTP/2overTLS,whichisinsteadnegotiatedasdescribedinSection3.3.
AserverthatsupportsHTTP/2acceptstheupgradewitha101(SwitchingProtocols)response.After
theemptylinethatterminatesthe101response,theservercanbeginsendingHTTP/2frames.These
framesMUSTincludearesponsetotherequestthatinitiatedtheUpgrade.
Forexample:
HTTP/1.1101SwitchingProtocols
Connection:Upgrade
Upgrade:h2c
[HTTP/2connection...
ThefirstHTTP/2framesentbytheserverMUSTbeaSETTINGSframe(Section6.5)astheserver
connectionpreface(Section3.5).Uponreceivingthe101response,theclientMUSTsendaconnection
preface(Section3.5),whichincludesaSETTINGSframe.
TheHTTP/1.1requestthatissentpriortoupgradeisassignedastreamidentifierof1(see
Section5.1.1)withdefaultpriorityvalues(Section5.3.5).Stream1isimplicitly"halfclosed"fromthe
clienttowardtheserver(seeSection5.1),sincetherequestiscompletedasanHTTP/1.1request.After
9/65
11/02/2015
commencingtheHTTP/2connection,stream1isusedfortheresponse.
3.2.1HTTP2SettingsHeaderField
ArequestthatupgradesfromHTTP/1.1toHTTP/2MUSTincludeexactlyoneHTTP2Settings
headerfield.TheHTTP2Settingsheaderfieldisaconnectionspecificheaderfieldthatincludes
parametersthatgoverntheHTTP/2connection,providedinanticipationoftheserveracceptingthe
requesttoupgrade.
HTTP2Settings=token68
AserverMUSTNOTupgradetheconnectiontoHTTP/2ifthisheaderfieldisnotpresent,orifmore
thanoneispresent.AserverMUSTNOTsendthisheaderfield.
ThecontentoftheHTTP2SettingsheaderfieldisthepayloadofaSETTINGSframe(Section6.5),
encodedasabase64urlstring(thatis,theURLandfilenamesafeBase64encodingdescribedin
Section5of[RFC4648],withanytrailing'='charactersomitted).TheABNF[RFC5234]productionfor
token68isdefinedinSection2.1of[RFC7235].
Sincetheupgradeisonlyintendedtoapplytotheimmediateconnection,aclientsendingHTTP2
SettingsMUSTalsosendHTTP2SettingsasaconnectionoptionintheConnectionheaderfieldto
preventitfrombeingforwarded(seeSection6.1of[RFC7230]).
AserverdecodesandinterpretsthesevaluesasitwouldanyotherSETTINGSframe.Explicit
acknowledgementofthesesettings(Section6.5.3)isnotnecessary,sincea101responseservesas
implicitacknowledgment.ProvidingthesevaluesintheUpgraderequestgivesaclientanopportunity
toprovideparameterspriortoreceivinganyframesfromtheserver.
3.3StartingHTTP/2for"https"URIs
Aclientthatmakesarequesttoan"https"URIusesTLS[TLS12]withtheapplicationlayerprotocol
negotiation(ALPN)extension[TLSALPN].
HTTP/2overTLSusesthe"h2"protocolidentifier.The"h2c"protocolidentifierMUSTNOTbesentby
aclientorselectedbyaserver;the"h2c"protocolidentifierdescribesaprotocolthatdoesnotuseTLS.
OnceTLSnegotiationiscomplete,boththeclientandtheserverMUSTsendaconnectionpreface
(Section3.5).
3.4StartingHTTP/2withPriorKnowledge
AclientcanlearnthataparticularserversupportsHTTP/2byothermeans.Forexample,[ALTSVC]
describesamechanismforadvertisingthiscapability.
AclientMUSTsendtheconnectionpreface(Section3.5),andthenMAYimmediatelysendHTTP/2
framestosuchaserver;serverscanidentifytheseconnectionsbythepresenceoftheconnection
preface.ThisonlyaffectstheestablishmentofHTTP/2connectionsovercleartextTCP;
implementationsthatsupportHTTP/2overTLSMUSTuseprotocolnegotiationinTLS[TLSALPN].
Likewise,theserverMUSTsendaconnectionpreface(Section3.5).
Withoutadditionalinformation,priorsupportforHTTP/2isnotastrongsignalthatagivenserverwill
supportHTTP/2forfutureconnections.Forexample,itispossibleforserverconfigurationstochange,
forconfigurationstodifferbetweeninstancesinclusteredservers,orfornetworkconditionsto
change.
10/65
11/02/2015
3.5HTTP/2ConnectionPreface
InHTTP/2,eachendpointisrequiredtosendaconnectionprefaceasafinalconfirmationofthe
protocolinuse,andtoestablishtheinitialsettingsfortheHTTP/2connection.Theclientandserver
eachsendadifferentconnectionpreface.
Theclientconnectionprefacestartswithasequenceof24octets,whichinhexnotationare:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
(thestringPRI*HTTP/2.0\r\n\r\nSM\r\n\r\n).ThissequenceMUSTbefollowedbyaSETTINGS
frame(Section6.5),whichMAYbeempty.Theclientsendstheclientconnectionprefaceimmediately
uponreceiptofa101SwitchingProtocolsresponse(indicatingasuccessfulupgrade),orasthefirst
applicationdataoctetsofaTLSconnection.IfstartinganHTTP/2connectionwithpriorknowledgeof
serversupportfortheprotocol,theclientconnectionprefaceissentuponconnectionestablishment.
TheclientconnectionprefaceisselectedsothatalargeproportionofHTTP/1.1orHTTP/1.0
serversandintermediariesdonotattempttoprocessfurtherframes.Notethatthisdoesnot
addresstheconcernsraisedin[TALKING].
TheserverconnectionprefaceconsistsofapotentiallyemptySETTINGSframe(Section6.5)thatMUST
bethefirstframetheserversendsintheHTTP/2connection.
TheSETTINGSframesreceivedfromapeeraspartoftheconnectionprefaceMUSTbeacknowledged
(seeSection6.5.3)aftersendingtheconnectionpreface.
Toavoidunnecessarylatency,clientsarepermittedtosendadditionalframestotheserver
immediatelyaftersendingtheclientconnectionpreface,withoutwaitingtoreceivetheserver
connectionpreface.Itisimportanttonote,however,thattheserverconnectionprefaceSETTINGS
framemightincludeparametersthatnecessarilyalterhowaclientisexpectedtocommunicatewith
theserver.UponreceivingtheSETTINGSframe,theclientisexpectedtohonoranyparameters
established.Insomeconfigurations,itispossiblefortheservertotransmitSETTINGSbeforetheclient
sendsadditionalframes,providinganopportunitytoavoidthisissue.
ClientsandserversMUSTtreataninvalidconnectionprefaceasaconnectionerror(Section5.4.1)of
typePROTOCOL_ERROR.AGOAWAYframe(Section6.8)MAYbeomittedinthiscase,sinceaninvalid
prefaceindicatesthatthepeerisnotusingHTTP/2.
4.HTTPFrames
OncetheHTTP/2connectionisestablished,endpointscanbeginexchangingframes.
4.1FrameFormat
Allframesbeginwithafixed9octetheaderfollowedbyavariablelengthpayload.
++
|Length(24)|
++++
|Type(8)|Flags(8)|
+++++
|R|StreamIdentifier(31)|
+=+=============================================================+
|FramePayload(0...)...
++
11/65
11/02/2015
Figure1:FrameLayout
Thefieldsoftheframeheaderaredefinedas:
Length: Thelengthoftheframepayloadexpressedasanunsigned24bitinteger.Valuesgreaterthan
214(16,384)MUSTNOTbesentunlessthereceiverhassetalargervaluefor
SETTINGS_MAX_FRAME_SIZE.
The9octetsoftheframeheaderarenotincludedinthisvalue.
Type: The8bittypeoftheframe.Theframetypedeterminestheformatandsemanticsoftheframe.
ImplementationsMUSTignoreanddiscardanyframethathasatypethatisunknown.
Flags: An8bitfieldreservedforframetypespecificbooleanflags.
Flagsareassignedsemanticsspecifictotheindicatedframetype.Flagsthathavenodefined
semanticsforaparticularframetypeMUSTbeignored,andMUSTbeleftunset(0x0)when
sending.
R:
Areserved1bitfield.ThesemanticsofthisbitareundefinedandthebitMUSTremainunset
(0x0)whensendingandMUSTbeignoredwhenreceiving.
StreamIdentifier: Astreamidentifier(seeSection5.1.1)expressedasanunsigned31bitinteger.The
value0x0isreservedforframesthatareassociatedwiththeconnectionasawholeasopposedto
anindividualstream.
Thestructureandcontentoftheframepayloadisdependententirelyontheframetype.
4.2FrameSize
Thesizeofaframepayloadislimitedbythemaximumsizethatareceiveradvertisesinthe
SETTINGS_MAX_FRAME_SIZEsetting.Thissettingcanhaveanyvaluebetween214(16,384)and2241
(16,777,215)octets,inclusive.
AllimplementationsMUSTbecapableofreceivingandminimallyprocessingframesupto214octetsin
length,plusthe9octetframeheader(Section4.1).Thesizeoftheframeheaderisnotincludedwhen
describingframesizes.
Note: Certainframetypes,suchasPING(Section6.7),imposeadditionallimitsontheamountof
payloaddataallowed.
AnendpointMUSTsendaFRAME_SIZE_ERRORerrorifaframeexceedsthesizedefinedin
SETTINGS_MAX_FRAME_SIZE,anylimitdefinedfortheframetype,oritistoosmalltocontain
mandatoryframedata.Aframesizeerrorinaframethatcouldalterthestateoftheentireconnection
MUSTbetreatedasaconnectionerror(Section5.4.1);thisincludesanyframecarryingaheaderblock
(Section4.3)(thatis,HEADERS,PUSH_PROMISE,andCONTINUATION),SETTINGS,andanyframewith
astreamidentifierof0.
Endpointsarenotobligatedtouseallavailablespaceinaframe.Responsivenesscanbeimprovedby
usingframesthataresmallerthanthepermittedmaximumsize.Sendinglargeframescanresultin
delaysinsendingtimesensitiveframes(suchasRST_STREAM,WINDOW_UPDATE,orPRIORITY)
whichifblockedbythetransmissionofalargeframe,couldaffectperformance.
4.3HeaderCompressionandDecompression
JustasinHTTP/1,aheaderfieldinHTTP/2isanamewithoneormoreassociatedvalues.Theyare
usedwithinHTTPrequestandresponsemessagesaswellasserverpushoperations(seeSection8.2).
12/65
11/02/2015
Headerlistsarecollectionsofzeroormoreheaderfields.Whentransmittedoveraconnection,a
headerlistisserializedintoaheaderblockusingHTTPHeaderCompression[COMPRESSION].The
serializedheaderblockisthendividedintooneormoreoctetsequences,calledheaderblock
fragments,andtransmittedwithinthepayloadofHEADERS(Section6.2),PUSH_PROMISE
(Section6.6)orCONTINUATION(Section6.10)frames.
TheCookieheaderfield[COOKIE]istreatedspeciallybytheHTTPmapping(seeSection8.1.2.5).
Areceivingendpointreassemblestheheaderblockbyconcatenatingitsfragments,thendecompresses
theblocktoreconstructtheheaderlist.
Acompleteheaderblockconsistsofeither:
asingleHEADERSorPUSH_PROMISEframe,withtheEND_HEADERSflagset,or
aHEADERSorPUSH_PROMISEframewiththeEND_HEADERSflagclearedandoneormore
CONTINUATIONframes,wherethelastCONTINUATIONframehastheEND_HEADERSflagset.
Headercompressionisstateful.Onecompressioncontextandonedecompressioncontextisusedfor
theentireconnection.AdecodingerrorinaheaderblockMUSTbetreatedasaconnectionerror
(Section5.4.1)oftypeCOMPRESSION_ERROR.
Eachheaderblockisprocessedasadiscreteunit.HeaderblocksMUSTbetransmittedasacontiguous
sequenceofframes,withnointerleavedframesofanyothertypeorfromanyotherstream.Thelast
frameinasequenceofHEADERSorCONTINUATIONframeshastheEND_HEADERSflagset.Thelast
frameinasequenceofPUSH_PROMISEorCONTINUATIONframeshastheEND_HEADERSflagset.This
allowsaheaderblocktobelogicallyequivalenttoasingleframe.
HeaderblockfragmentscanonlybesentasthepayloadofHEADERS,PUSH_PROMISEor
CONTINUATIONframes,becausetheseframescarrydatathatcanmodifythecompressioncontext
maintainedbyareceiver.AnendpointreceivingHEADERS,PUSH_PROMISEorCONTINUATIONframes
needstoreassembleheaderblocksandperformdecompressioneveniftheframesaretobediscarded.
AreceiverMUSTterminatetheconnectionwithaconnectionerror(Section5.4.1)oftype
COMPRESSION_ERRORifitdoesnotdecompressaheaderblock.
5.StreamsandMultiplexing
A"stream"isanindependent,bidirectionalsequenceofframesexchangedbetweentheclientand
serverwithinanHTTP/2connection.Streamshaveseveralimportantcharacteristics:
AsingleHTTP/2connectioncancontainmultipleconcurrentlyopenstreams,witheitherendpoint
interleavingframesfrommultiplestreams.
Streamscanbeestablishedandusedunilaterallyorsharedbyeithertheclientorserver.
Streamscanbeclosedbyeitherendpoint.
Theorderinwhichframesaresentonastreamissignificant.Recipientsprocessframesinthe
ordertheyarereceived.Inparticular,theorderofHEADERS,andDATAframesissemantically
significant.
Streamsareidentifiedbyaninteger.Streamidentifiersareassignedtostreamsbytheendpoint
initiatingthestream.
5.1StreamStates
ThelifecycleofastreamisshowninFigure2.
13/65
11/02/2015
++
sendPP||recvPP
,|idle|.
/||\
v++v
++|++
|||sendH/||
,|reserved||recvH|reserved|.
||(local)|||(remote)||
|++v++|
||++||
||recvES||sendES||
|sendH|,|open|.|recvH|
||/||\||
|vv++vv|
|++|++|
||half|||half||
||closed||sendR/|closed||
||(remote)||recvR|(local)||
|++|++|
|||||
||sendES/|recvES/||
||sendR/vsendR/||
||recvR++recvR||
|sendR/`>||<'sendR/|
|recvR|closed|recvR|
`>||<'
++
send:endpointsendsthisframe
recv:endpointreceivesthisframe
H:HEADERSframe(withimpliedCONTINUATIONs)
PP:PUSH_PROMISEframe(withimpliedCONTINUATIONs)
ES:END_STREAMflag
R:RST_STREAMframe
Figure2:StreamStates
Notethatthisdiagramshowsstreamstatetransitionsandtheframesandflagsthataffectthose
transitionsonly.Inthisregard,CONTINUATIONframesdonotresultinstatetransitions;theyare
effectivelypartoftheHEADERSorPUSH_PROMISEthattheyfollow.Forthepurposeofstate
transitions,theEND_STREAMflagisprocessedasaseparateeventtotheframethatbearsit;a
HEADERSframewiththeEND_STREAMflagsetcancausetwostatetransitions.
Bothendpointshaveasubjectiveviewofthestateofastreamthatcouldbedifferentwhenframesare
intransit.Endpointsdonotcoordinatethecreationofstreams;theyarecreatedunilaterallybyeither
endpoint.Thenegativeconsequencesofamismatchinstatesarelimitedtothe"closed"stateafter
sendingRST_STREAM,whereframesmightbereceivedforsometimeafterclosing.
14/65
11/02/2015
Streamshavethefollowingstates:
idle:
Allstreamsstartinthe"idle"state.
Thefollowingtransitionsarevalidfromthisstate:
SendingorreceivingaHEADERSframecausesthestreamtobecome"open".Thestream
identifierisselectedasdescribedinSection5.1.1.ThesameHEADERSframecanalso
causeastreamtoimmediatelybecome"halfclosed".
SendingaPUSH_PROMISEframeonanotherstreamreservestheidlestreamthatis
identifiedforlateruse.Thestreamstateforthereservedstreamtransitionsto"reserved
(local)".
ReceivingaPUSH_PROMISEframeonanotherstreamreservesanidlestreamthatis
identifiedforlateruse.Thestreamstateforthereservedstreamtransitionsto"reserved
(remote)".
NotethatthePUSH_PROMISEframeisnotsentontheidlestream,butreferencesthe
newlyreservedstreaminthePromisedStreamIDfield.
ReceivinganyframeotherthanHEADERSorPRIORITYonastreaminthisstateMUSTbetreated
asaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
reserved(local):
Astreaminthe"reserved(local)"stateisonethathasbeenpromisedbysendinga
PUSH_PROMISEframe.APUSH_PROMISEframereservesanidlestreambyassociatingthestream
withanopenstreamthatwasinitiatedbytheremotepeer(seeSection8.2).
Inthisstate,onlythefollowingtransitionsarepossible:
TheendpointcansendaHEADERSframe.Thiscausesthestreamtoopenina"half
closed(remote)"state.
EitherendpointcansendaRST_STREAMframetocausethestreamtobecome"closed".
Thisreleasesthestreamreservation.
AnendpointMUSTNOTsendanytypeofframeotherthanHEADERS,RST_STREAM,orPRIORITY
inthisstate.
APRIORITYorWINDOW_UPDATEframeMAYbereceivedinthisstate.Receivinganytypeof
frameotherthanRST_STREAM,PRIORITYorWINDOW_UPDATEonastreaminthisstateMUST
betreatedasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
reserved(remote):
Astreaminthe"reserved(remote)"statehasbeenreservedbyaremotepeer.
Inthisstate,onlythefollowingtransitionsarepossible:
ReceivingaHEADERSframecausesthestreamtotransitionto"halfclosed(local)".
EitherendpointcansendaRST_STREAMframetocausethestreamtobecome"closed".
Thisreleasesthestreamreservation.
AnendpointMAYsendaPRIORITYframeinthisstatetoreprioritizethereservedstream.An
endpointMUSTNOTsendanytypeofframeotherthanRST_STREAM,WINDOW_UPDATE,or
PRIORITYinthisstate.
ReceivinganytypeofframeotherthanHEADERS,RST_STREAMorPRIORITYonastreaminthis
stateMUSTbetreatedasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
open:
Astreaminthe"open"statemaybeusedbybothpeerstosendframesofanytype.Inthisstate,
sendingpeersobserveadvertisedstreamlevelflowcontrollimits(Section5.2).
FromthisstateeitherendpointcansendaframewithanEND_STREAMflagset,whichcausesthe
15/65
11/02/2015
streamtotransitionintooneofthe"halfclosed"states:anendpointsendinganEND_STREAMflag
causesthestreamstatetobecome"halfclosed(local)";anendpointreceivinganEND_STREAM
flagcausesthestreamstatetobecome"halfclosed(remote)".
EitherendpointcansendaRST_STREAMframefromthisstate,causingittotransition
immediatelyto"closed".
halfclosed(local):
Astreamthatisinthe"halfclosed(local)"statecannotbeusedforsendingframesotherthan
WINDOW_UPDATE,PRIORITYandRST_STREAM.
Astreamtransitionsfromthisstateto"closed"whenaframethatcontainsanEND_STREAMflag
isreceived,orwheneitherpeersendsaRST_STREAMframe.
Anendpointcanreceiveanytypeofframeinthisstate.Providingflowcontrolcreditusing
WINDOW_UPDATEframesisnecessarytocontinuereceivingflowcontrolledframes.Areceiver
canignoreWINDOW_UPDATEframesinthisstate,whichmightarriveforashortperiodaftera
framebearingtheEND_STREAMflagissent.
PRIORITYframesreceivedinthisstateareusedtoreprioritizestreamsthatdependonthe
identifiedstream.
halfclosed(remote):
Astreamthatis"halfclosed(remote)"isnolongerbeingusedbythepeertosendframes.Inthis
state,anendpointisnolongerobligatedtomaintainareceiverflowcontrolwindow.
Ifanendpointreceivesadditionalframesforastreamthatisinthisstate,otherthan
WINDOW_UPDATE,PRIORITYorRST_STREAM,itMUSTrespondwithastreamerror
(Section5.4.2)oftypeSTREAM_CLOSED.
Astreamthatis"halfclosed(remote)"canbeusedbytheendpointtosendframesofanytype.In
thisstate,theendpointcontinuestoobserveadvertisedstreamlevelflowcontrollimits
(Section5.2).
Astreamcantransitionfromthisstateto"closed"bysendingaframethatcontainsan
END_STREAMflag,orwheneitherpeersendsaRST_STREAMframe.
closed:
The"closed"stateistheterminalstate.
AnendpointMUSTNOTsendframesotherthanPRIORITYonaclosedstream.Anendpointthat
receivesanyframeotherthanPRIORITYafterreceivingaRST_STREAMMUSTtreatthatasa
streamerror(Section5.4.2)oftypeSTREAM_CLOSED.Similarly,anendpointthatreceivesany
framesafterreceivingaframewiththeEND_STREAMflagsetMUSTtreatthatasaconnection
error(Section5.4.1)oftypeSTREAM_CLOSED,unlesstheframeispermittedasdescribedbelow.
WINDOW_UPDATEorRST_STREAMframescanbereceivedinthisstateforashortperiodaftera
DATAorHEADERSframecontaininganEND_STREAMflagissent.Untiltheremotepeerreceives
andprocessesRST_STREAMortheframebearingtheEND_STREAMflag,itmightsendframesof
thesetypes.EndpointsMUSTignoreWINDOW_UPDATEorRST_STREAMframesreceivedinthis
state,thoughendpointsMAYchoosetotreatframesthatarriveasignificanttimeaftersending
END_STREAMasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
PRIORITYframescanbesentonclosedstreamstoprioritizestreamsthataredependentonthe
closedstream.EndpointsSHOULDprocessPRIORITYframes,thoughtheycanbeignoredifthe
streamhasbeenremovedfromthedependencytree(seeSection5.3.4).
IfthisstateisreachedasaresultofsendingaRST_STREAMframe,thepeerthatreceivesthe
RST_STREAMmighthavealreadysentorenqueuedforsendingframesonthestreamthat
cannotbewithdrawn.AnendpointMUSTignoreframesthatitreceivesonclosedstreamsafterit
16/65
11/02/2015
hassentaRST_STREAMframe.AnendpointMAYchoosetolimittheperiodoverwhichitignores
framesandtreatframesthatarriveafterthistimeasbeinginerror.
Flowcontrolledframes(i.e.,DATA)receivedaftersendingRST_STREAMarecountedtowardthe
connectionflowcontrolwindow.Eventhoughtheseframesmightbeignored,becausetheyare
sentbeforethesenderreceivestheRST_STREAM,thesenderwillconsidertheframestocount
againsttheflowcontrolwindow.
AnendpointmightreceiveaPUSH_PROMISEframeafteritsendsRST_STREAM.PUSH_PROMISE
causesastreamtobecome"reserved"eveniftheassociatedstreamhasbeenreset.Therefore,a
RST_STREAMisneededtocloseanunwantedpromisedstream.
Intheabsenceofmorespecificguidanceelsewhereinthisdocument,implementationsSHOULDtreat
thereceiptofaframethatisnotexpresslypermittedinthedescriptionofastateasaconnectionerror
(Section5.4.1)oftypePROTOCOL_ERROR.NotethatPRIORITYcanbesentandreceivedinanystream
state.Framesofunknowntypesareignored.
AnexampleofthestatetransitionsforanHTTPrequest/responseexchangecanbefoundin
Section8.1.AnexampleofthestatetransitionsforserverpushcanbefoundinSection8.2.1and
Section8.2.2.
5.1.1StreamIdentifiers
Streamsareidentifiedwithanunsigned31bitinteger.StreamsinitiatedbyaclientMUSTuseodd
numberedstreamidentifiers;thoseinitiatedbytheserverMUSTuseevennumberedstream
identifiers.Astreamidentifierofzero(0x0)isusedforconnectioncontrolmessages;thestream
identifierzerocannotbeusedtoestablishanewstream.
HTTP/1.1requeststhatareupgradedtoHTTP/2(seeSection3.2)arerespondedtowithastream
identifierofone(0x1).Aftertheupgradecompletes,stream0x1is"halfclosed(local)"totheclient.
Therefore,stream0x1cannotbeselectedasanewstreamidentifierbyaclientthatupgradesfrom
HTTP/1.1.
TheidentifierofanewlyestablishedstreamMUSTbenumericallygreaterthanallstreamsthatthe
initiatingendpointhasopenedorreserved.ThisgovernsstreamsthatareopenedusingaHEADERS
frameandstreamsthatarereservedusingPUSH_PROMISE.Anendpointthatreceivesanunexpected
streamidentifierMUSTrespondwithaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
Thefirstuseofanewstreamidentifierimplicitlyclosesallstreamsinthe"idle"statethatmighthave
beeninitiatedbythatpeerwithalowervaluedstreamidentifier.Forexample,ifaclientsendsa
HEADERSframeonstream7withouteversendingaframeonstream5,thenstream5transitionsto
the"closed"statewhenthefirstframeforstream7issentorreceived.
Streamidentifierscannotbereused.Longlivedconnectionscanresultinanendpointexhaustingthe
availablerangeofstreamidentifiers.Aclientthatisunabletoestablishanewstreamidentifiercan
establishanewconnectionfornewstreams.Aserverthatisunabletoestablishanewstream
identifiercansendaGOAWAYframesothattheclientisforcedtoopenanewconnectionfornew
streams.
5.1.2StreamConcurrency
Apeercanlimitthenumberofconcurrentlyactivestreamsusingthe
SETTINGS_MAX_CONCURRENT_STREAMSparameter(seeSection6.5.2)withinaSETTINGSframe.The
maximumconcurrentstreamssettingisspecifictoeachendpointandappliesonlytothepeerthat
17/65
11/02/2015
receivesthesetting.Thatis,clientsspecifythemaximumnumberofconcurrentstreamstheservercan
initiate,andserversspecifythemaximumnumberofconcurrentstreamstheclientcaninitiate.
Streamsthatareinthe"open"state,oreitherofthe"halfclosed"statescounttowardthemaximum
numberofstreamsthatanendpointispermittedtoopen.Streamsinanyofthesethreestatescount
towardthelimitadvertisedintheSETTINGS_MAX_CONCURRENT_STREAMSsetting.Streamsineither
ofthe"reserved"statesdonotcounttowardthestreamlimit.
EndpointsMUSTNOTexceedthelimitsetbytheirpeer.AnendpointthatreceivesaHEADERSframe
thatcausestheiradvertisedconcurrentstreamlimittobeexceededMUSTtreatthisasastreamerror
(Section5.4.2)oftypePROTOCOL_ERRORorREFUSED_STREAM.Thechoiceoferrorcodedetermines
whethertheendpointwishestoenableautomaticretry,seeSection8.1.4)fordetails.
AnendpointthatwishestoreducethevalueofSETTINGS_MAX_CONCURRENT_STREAMStoavalue
thatisbelowthecurrentnumberofopenstreamscaneitherclosestreamsthatexceedthenewvalue
orallowstreamstocomplete.
5.2FlowControl
UsingstreamsformultiplexingintroducescontentionoveruseoftheTCPconnection,resultingin
blockedstreams.Aflowcontrolschemeensuresthatstreamsonthesameconnectiondonot
destructivelyinterferewitheachother.Flowcontrolisusedforbothindividualstreamsandforthe
connectionasawhole.
HTTP/2providesforflowcontrolthroughuseoftheWINDOW_UPDATEframe(Section6.9).
5.2.1FlowControlPrinciples
HTTP/2streamflowcontrolaimstoallowavarietyofflowcontrolalgorithmstobeusedwithout
requiringprotocolchanges.FlowcontrolinHTTP/2hasthefollowingcharacteristics:
1. Flowcontrolisspecifictoaconnection.Bothtypesofflowcontrolarebetweentheendpointsofa
singlehop,andnotovertheentireendtoendpath.
2. Flowcontrolisbasedonwindowupdateframes.Receiversadvertisehowmanyoctetstheyare
preparedtoreceiveonastreamandfortheentireconnection.Thisisacreditbasedscheme.
3. Flowcontrolisdirectionalwithoverallcontrolprovidedbythereceiver.AreceiverMAYchooseto
setanywindowsizethatitdesiresforeachstreamandfortheentireconnection.AsenderMUST
respectflowcontrollimitsimposedbyareceiver.Clients,serversandintermediariesall
independentlyadvertisetheirflowcontrolwindowasareceiverandabidebytheflowcontrol
limitssetbytheirpeerwhensending.
4. Theinitialvaluefortheflowcontrolwindowis65,535octetsforbothnewstreamsandtheoverall
connection.
5. Theframetypedetermineswhetherflowcontrolappliestoaframe.Oftheframesspecifiedinthis
document,onlyDATAframesaresubjecttoflowcontrol;allotherframetypesdonotconsume
spaceintheadvertisedflowcontrolwindow.Thisensuresthatimportantcontrolframesarenot
blockedbyflowcontrol.
6. Flowcontrolcannotbedisabled.
7. HTTP/2definesonlytheformatandsemanticsoftheWINDOW_UPDATEframe(Section6.9).This
documentdoesnotstipulatehowareceiverdecideswhentosendthisframeorthevaluethatit
sends,nordoesitspecifyhowasenderchoosestosendpackets.Implementationsareableto
selectanyalgorithmthatsuitstheirneeds.
Implementationsarealsoresponsibleformanaginghowrequestsandresponsesaresentbasedon
18/65
11/02/2015
priority;choosinghowtoavoidheadoflineblockingforrequests;andmanagingthecreationofnew
streams.Algorithmchoicesforthesecouldinteractwithanyflowcontrolalgorithm.
5.2.2AppropriateUseofFlowControl
Flowcontrolisdefinedtoprotectendpointsthatareoperatingunderresourceconstraints.For
example,aproxyneedstosharememorybetweenmanyconnections,andalsomighthaveaslow
upstreamconnectionandafastdownstreamone.Flowcontroladdressescaseswherethereceiveris
unabletoprocessdataononestream,yetwantstocontinuetoprocessotherstreamsinthesame
connection.
Deploymentsthatdonotrequirethiscapabilitycanadvertiseaflowcontrolwindowofthemaximum
size(2311),andbymaintainingthiswindowbysendingaWINDOW_UPDATEframewhenanydatais
received.Thiseffectivelydisablesflowcontrolforthatreceiver.Conversely,asenderisalwayssubject
totheflowcontrolwindowadvertisedbythereceiver.
Deploymentswithconstrainedresources(forexample,memory)canemployflowcontroltolimitthe
amountofmemoryapeercanconsume.Note,however,thatthiscanleadtosuboptimaluseof
availablenetworkresourcesifflowcontrolisenabledwithoutknowledgeofthebandwidthdelay
product(see[RFC7323]).
Evenwithfullawarenessofthecurrentbandwidthdelayproduct,implementationofflowcontrolcan
bedifficult.Whenusingflowcontrol,thereceiverMUSTreadfromtheTCPreceivebufferinatimely
fashion.Failuretodosocouldleadtoadeadlockwhencriticalframes,suchasWINDOW_UPDATE,are
notreadandactedupon.
5.3Streampriority
AclientcanassignapriorityforanewstreambyincludingprioritizationinformationintheHEADERS
frame(Section6.2)thatopensthestream.Atanyothertime,thePRIORITYframe(Section6.3)canbe
usedtochangethepriorityofastream.
Thepurposeofprioritizationistoallowanendpointtoexpresshowitwouldpreferitspeerallocate
resourceswhenmanagingconcurrentstreams.Mostimportantly,prioritycanbeusedtoselect
streamsfortransmittingframeswhenthereislimitedcapacityforsending.
Streamscanbeprioritizedbymarkingthemasdependentonthecompletionofotherstreams
(Section5.3.1).Eachdependencyisassignedarelativeweight,anumberthatisusedtodeterminethe
relativeproportionofavailableresourcesthatareassignedtostreamsdependentonthesamestream.
Explicitlysettingthepriorityforastreamisinputtoaprioritizationprocess.Itdoesnotguaranteeany
particularprocessingortransmissionorderforthestreamrelativetoanyotherstream.Anendpoint
cannotforceapeertoprocessconcurrentstreamsinaparticularorderusingpriority.Expressing
priorityisthereforeonlyeverasuggestion.
Prioritizationinformationcanbeomittedfrommessages.Defaultsareusedpriortoanyexplicitvalues
beingprovided(Section5.3.5).
5.3.1StreamDependencies
Eachstreamcanbegivenanexplicitdependencyonanotherstream.Includingadependency
expressesapreferencetoallocateresourcestotheidentifiedstreamratherthantothedependent
stream.
19/65
11/02/2015
Astreamthatisnotdependentonanyotherstreamisgivenastreamdependencyof0x0.Inother
words,thenonexistentstream0formstherootofthetree.
Astreamthatdependsonanotherstreamisadependentstream.Thestreamuponwhichastreamis
dependentisaparentstream.Adependencyonastreamthatisnotcurrentlyinthetreesuchasa
streaminthe"idle"stateresultsinthatstreambeinggivenadefaultpriority(Section5.3.5).
Whenassigningadependencyonanotherstream,thestreamisaddedasanewdependencyofthe
parentstream.Dependentstreamsthatsharethesameparentarenotorderedwithrespecttoeach
other.Forexample,ifstreamsBandCaredependentonstreamA,andifstreamDiscreatedwitha
dependencyonstreamA,thisresultsinadependencyorderofAfollowedbyB,C,andDinanyorder.
AA
/\==>/|\
BCBDC
Figure3:ExampleofDefaultDependencyCreation
Anexclusiveflagallowsfortheinsertionofanewlevelofdependencies.Theexclusiveflagcausesthe
streamtobecomethesoledependencyofitsparentstream,causingotherdependenciestobecome
dependentontheexclusivestream.Inthepreviousexample,ifstreamDiscreatedwithanexclusive
dependencyonstreamA,thisresultsinDbecomingthedependencyparentofBandC.
A
A|
/\==>D
BC/\
BC
Figure4:ExampleofExclusiveDependencyCreation
Insidethedependencytree,adependentstreamSHOULDonlybeallocatedresourcesifallofthe
streamsthatitdependson(thechainofparentstreamsupto0x0)areeitherclosed,oritisnot
possibletomakeprogressonthem.
Astreamcannotdependonitself.AnendpointMUSTtreatthisasastreamerror(Section5.4.2)oftype
PROTOCOL_ERROR.
5.3.2DependencyWeighting
Alldependentstreamsareallocatedanintegerweightbetween1and256(inclusive).
StreamswiththesameparentSHOULDbeallocatedresourcesproportionallybasedontheirweight.
Thus,ifstreamBdependsonstreamAwithweight4,andCdependsonstreamAwithweight12,and
ifnoprogresscanbemadeonA,streamBideallyreceivesonethirdoftheresourcesallocatedto
streamC.
5.3.3Reprioritization
StreamprioritiesarechangedusingthePRIORITYframe.Settingadependencycausesastreamto
becomedependentontheidentifiedparentstream.
Dependentstreamsmovewiththeirparentstreamiftheparentisreprioritized.Settingadependency
withtheexclusiveflagforareprioritizedstreammovesallthedependenciesofthenewparentstream
tobecomedependentonthereprioritizedstream.
20/65
11/02/2015
Ifastreamismadedependentononeofitsowndependencies,theformerlydependentstreamisfirst
movedtobedependentonthereprioritizedstream'spreviousparent.Themoveddependencyretains
itsweight.
Forexample,consideranoriginaldependencytreewhereBandCdependonA,DandEdependonC,
andFdependsonD.IfAismadedependentonD,thenDtakestheplaceofA.Allotherdependency
relationshipsstaythesame,exceptforF,whichbecomesdependentonAifthereprioritizationis
exclusive.
????
|/\||
ADADD
/\//\/\|
BC==>FBC==>FAORA
/\|/\/|\
DEEBCBCF
|||
FEE
(intermediate)(nonexclusive)(exclusive)
Figure5:ExampleofDependencyReordering
5.3.4PrioritizationStateManagement
Whenastreamisremovedfromthedependencytree,itsdependenciescanbemovedtobecome
dependentontheparentoftheclosedstream.Theweightsofnewdependenciesarerecalculatedby
distributingtheweightofthedependencyoftheclosedstreamproportionallybasedontheweightsof
itsdependencies.
Streamsthatareremovedfromthedependencytreecausesomeprioritizationinformationtobelost.
Resourcesaresharedbetweenstreamswiththesameparentstream,whichmeansthatifastreamin
thatsetclosesorbecomesblocked,anysparecapacityallocatedtoastreamisdistributedtothe
immediateneighborsofthestream.However,ifthecommondependencyisremovedfromthetree,
thosestreamsshareresourceswithstreamsatthenexthighestlevel.
Forexample,assumestreamsAandBshareaparent,andstreamsCandDbothdependonstreamA.
PriortotheremovalofstreamA,ifstreamsAandDareunabletoproceed,thenstreamCreceivesall
theresourcesdedicatedtostreamA.IfstreamAisremovedfromthetree,theweightofstreamAis
dividedbetweenstreamsCandD.IfstreamDisstillunabletoproceed,thisresultsinstreamC
receivingareducedproportionofresources.Forequalstartingweights,Creceivesonethird,rather
thanonehalf,ofavailableresources.
Itispossibleforastreamtobecomeclosedwhileprioritizationinformationthatcreatesadependency
onthatstreamisintransit.Ifastreamidentifiedinadependencyhasnoassociatedpriority
information,thenthedependentstreamisinsteadassignedadefaultpriority(Section5.3.5).This
potentiallycreatessuboptimalprioritization,sincethestreamcouldbegivenaprioritythatisdifferent
towhatisintended.
Toavoidtheseproblems,anendpointSHOULDretainstreamprioritizationstateforaperiodafter
streamsbecomeclosed.Thelongerstateisretained,thelowerthechancethatstreamsareassigned
incorrectordefaultpriorityvalues.
Similarly,streamsthatareinthe"idle"statecanbeassignedpriorityorbecomeaparentofother
streams.Thisallowsforthecreationofagroupingnodeinthedependencytree,whichenablesmore
21/65
11/02/2015
flexibleexpressionsofpriority.Idlestreamsbeginwithadefaultpriority(Section5.3.5).
Theretentionofpriorityinformationforstreamsthatarenotcountedtowardthelimitsetby
SETTINGS_MAX_CONCURRENT_STREAMScouldcreatealargestateburdenforanendpoint.Therefore
theamountofprioritizationstatethatisretainedMAYbelimited.
Theamountofadditionalstateanendpointmaintainsforprioritizationcouldbedependentonload;
underhighload,prioritizationstatecanbediscardedtolimitresourcecommitments.Inextremecases,
anendpointcouldevendiscardprioritizationstateforactiveorreservedstreams.Ifalimitisapplied,
endpointsSHOULDmaintainstateforatleastasmanystreamsasallowedbytheirsettingfor
SETTINGS_MAX_CONCURRENT_STREAMS.ImplementationsSHOULDalsoattempttoretainstatefor
streamsthatareinactiveuseintheprioritytree.
AnendpointreceivingaPRIORITYframethatchangesthepriorityofaclosedstreamSHOULDalterthe
dependenciesofthestreamsthatdependonit,ifithasretainedenoughstatetodoso.
5.3.5DefaultPriorities
Allstreamsareinitiallyassignedanonexclusivedependencyonstream0x0.Pushedstreams
(Section8.2)initiallydependontheirassociatedstream.Inbothcases,streamsareassignedadefault
weightof16.
5.4ErrorHandling
HTTP/2framingpermitstwoclassesoferror:
Anerrorconditionthatrenderstheentireconnectionunusableisaconnectionerror.
Anerrorinanindividualstreamisastreamerror.
AlistoferrorcodesisincludedinSection7.
5.4.1ConnectionErrorHandling
Aconnectionerrorisanyerrorwhichpreventsfurtherprocessingoftheframinglayer,orwhich
corruptsanyconnectionstate.
AnendpointthatencountersaconnectionerrorSHOULDfirstsendaGOAWAYframe(Section6.8)
withthestreamidentifierofthelaststreamthatitsuccessfullyreceivedfromitspeer.TheGOAWAY
frameincludesanerrorcodethatindicateswhytheconnectionisterminating.Aftersendingthe
GOAWAYframeforanerrorcondition,theendpointMUSTclosetheTCPconnection.
ItispossiblethattheGOAWAYwillnotbereliablyreceivedbythereceivingendpoint(see[RFC7230],
Section6.6).Intheeventofaconnectionerror,GOAWAYonlyprovidesabesteffortattemptto
communicatewiththepeeraboutwhytheconnectionisbeingterminated.
Anendpointcanendaconnectionatanytime.Inparticular,anendpointMAYchoosetotreatastream
errorasaconnectionerror.EndpointsSHOULDsendaGOAWAYframewhenendingaconnection,
providingthatcircumstancespermitit.
5.4.2StreamErrorHandling
Astreamerrorisanerrorrelatedtoaspecificstreamthatdoesnotaffectprocessingofotherstreams.
AnendpointthatdetectsastreamerrorsendsaRST_STREAMframe(Section6.4)thatcontainsthe
22/65
11/02/2015
streamidentifierofthestreamwheretheerroroccurred.TheRST_STREAMframeincludesanerror
codethatindicatesthetypeoferror.
ARST_STREAMisthelastframethatanendpointcansendonastream.Thepeerthatsendsthe
RST_STREAMframeMUSTbepreparedtoreceiveanyframesthatweresentorenqueuedforsending
bytheremotepeer.Theseframescanbeignored,exceptwheretheymodifyconnectionstate(suchas
thestatemaintainedforheadercompression(Section4.3),orflowcontrol).
Normally,anendpointSHOULDNOTsendmorethanoneRST_STREAMframeforanystream.
However,anendpointMAYsendadditionalRST_STREAMframesifitreceivesframesonaclosed
streamaftermorethanaroundtriptime.Thisbehaviorispermittedtodealwithmisbehaving
implementations.
AnendpointMUSTNOTsendaRST_STREAMinresponsetoaRST_STREAMframe,toavoidlooping.
5.4.3ConnectionTermination
IftheTCPconnectionisclosedorresetwhilestreamsremaininopenorhalfclosedstates,thenthe
affectedstreamscannotbeautomaticallyretried(seeSection8.1.4fordetails).
5.5ExtendingHTTP/2
HTTP/2permitsextensionoftheprotocol.Protocolextensionscanbeusedtoprovideadditional
servicesoralteranyaspectoftheprotocol,withinthelimitationsdescribedinthissection.Extensions
areeffectiveonlywithinthescopeofasingleHTTP/2connection.
Thisappliestotheprotocolelementsdefinedinthisdocument.Thisdoesnotaffecttheexisting
optionsforextendingHTTP,suchasdefiningnewmethods,statuscodes,orheaderfields.
Extensionsarepermittedtousenewframetypes(Section4.1),newsettings(Section6.5.2),ornew
errorcodes(Section7).Registriesareestablishedformanagingtheseextensionpoints:frametypes
(Section11.2),settings(Section11.3)anderrorcodes(Section11.4).
ImplementationsMUSTignoreunknownorunsupportedvaluesinallextensibleprotocolelements.
ImplementationsMUSTdiscardframesthathaveunknownorunsupportedtypes.Thismeansthatany
oftheseextensionpointscanbesafelyusedbyextensionswithoutpriorarrangementornegotiation.
However,extensionframesthatappearinthemiddleofaheaderblock(Section4.3)arenotpermitted;
theseMUSTbetreatedasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
ExtensionsthatcouldchangethesemanticsofexistingprotocolcomponentsMUSTbenegotiated
beforebeingused.Forexample,anextensionthatchangesthelayoutoftheHEADERSframecannotbe
useduntilthepeerhasgivenapositivesignalthatthisisacceptable.Inthiscase,itcouldalsobe
necessarytocoordinatewhentherevisedlayoutcomesintoeffect.Notethattreatinganyframeother
thanDATAframesasflowcontrolledissuchachangeinsemantics,andcanonlybedonethrough
negotiation.
Thisdocumentdoesn'tmandateaspecificmethodfornegotiatingtheuseofanextension,butnotes
thatasetting(Section6.5.2)couldbeusedforthatpurpose.Ifbothpeerssetavaluethatindicates
willingnesstousetheextension,thentheextensioncanbeused.Ifasettingisusedforextension
negotiation,theinitialvalueMUSTbedefinedinsuchafashionthattheextensionisinitiallydisabled.
6.FrameDefinitions
Thisspecificationdefinesanumberofframetypes,eachidentifiedbyaunique8bittypecode.Each
23/65
11/02/2015
frametypeservesadistinctpurposeeitherintheestablishmentandmanagementoftheconnectionas
awhole,orofindividualstreams.
Thetransmissionofspecificframetypescanalterthestateofaconnection.Ifendpointsfailto
maintainasynchronizedviewoftheconnectionstate,successfulcommunicationwithintheconnection
willnolongerbepossible.Therefore,itisimportantthatendpointshaveasharedcomprehensionof
howthestateisaffectedbytheuseanygivenframe.
6.1DATA
DATAframes(type=0x0)conveyarbitrary,variablelengthsequencesofoctetsassociatedwitha
stream.OneormoreDATAframesareused,forinstance,tocarryHTTPrequestorresponsepayloads.
DATAframesMAYalsocontainpadding.PaddingcanbeaddedtoDATAframestoobscurethesizeof
messages.Paddingisasecurityfeature;seeSection10.7.
++
|PadLength?(8)|
+++
|Data(*)...
++
|Padding(*)...
++
Figure6:DATAFramePayload
TheDATAframecontainsthefollowingfields:
PadLength: An8bitfieldcontainingthelengthoftheframepaddinginunitsofoctets.Thisfieldis
conditionalandisonlypresentifthePADDEDflagisset.
Data: Applicationdata.Theamountofdataistheremainderoftheframepayloadaftersubtractingthe
lengthoftheotherfieldsthatarepresent.
Padding: Paddingoctetsthatcontainnoapplicationsemanticvalue.PaddingoctetsMUSTbesetto
zerowhensending.Areceiverisnotobligatedtoverifypadding,butMAYtreatnonzeropadding
asaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
TheDATAframedefinesthefollowingflags:
END_STREAM(0x1): Bit0beingsetindicatesthatthisframeisthelastthattheendpointwillsendfor
theidentifiedstream.Settingthisflagcausesthestreamtoenteroneofthe"halfclosed"statesor
the"closed"state(Section5.1).
PADDED(0x8): Bit3beingsetindicatesthatthePadLengthfieldandanypaddingthatitdescribesis
present.
DATAframesMUSTbeassociatedwithastream.IfaDATAframeisreceivedwhosestreamidentifier
fieldis0x0,therecipientMUSTrespondwithaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
DATAframesaresubjecttoflowcontrolandcanonlybesentwhenastreamisinthe"open"or"half
closed(remote)"states.TheentireDATAframepayloadisincludedinflowcontrol,includingPad
LengthandPaddingfieldsifpresent.IfaDATAframeisreceivedwhosestreamisnotin"open"or"half
closed(local)"state,therecipientMUSTrespondwithastreamerror(Section5.4.2)oftype
STREAM_CLOSED.
24/65
11/02/2015
ThetotalnumberofpaddingoctetsisdeterminedbythevalueofthePadLengthfield.Ifthelengthof
thepaddingisthelengthoftheframepayloadorgreater,therecipientMUSTtreatthisasaconnection
error(Section5.4.1)oftypePROTOCOL_ERROR.
Note: AframecanbeincreasedinsizebyoneoctetbyincludingaPadLengthfieldwithavalueof
zero.
6.2HEADERS
TheHEADERSframe(type=0x1)isusedtoopenastream(Section5.1),andadditionallycarriesa
headerblockfragment.HEADERSframescanbesentonastreaminthe"open"or"halfclosed
(remote)"states.
++
|PadLength?(8)|
++++
|E|StreamDependency?(31)|
++++
|Weight?(8)|
++++
|HeaderBlockFragment(*)...
++
|Padding(*)...
++
Figure7:HEADERSFramePayload
TheHEADERSframepayloadhasthefollowingfields:
onlypresentifthePADDEDflagisset.
E:
Asinglebitflagindicatesthatthestreamdependencyisexclusive,seeSection5.3.Thisfieldis
onlypresentifthePRIORITYflagisset.
StreamDependency: A31bitstreamidentifierforthestreamthatthisstreamdependson,see
Section5.3.ThisfieldisonlypresentifthePRIORITYflagisset.
Weight: Anunsigned8bitintegerrepresentingapriorityweightforthestream,seeSection5.3.Add
onetothevaluetoobtainaweightbetween1and256.ThisfieldisonlypresentifthePRIORITY
flagisset.
HeaderBlockFragment: Aheaderblockfragment(Section4.3).
Padding: Paddingoctets.
TheHEADERSframedefinesthefollowingflags:
END_STREAM(0x1): Bit0beingsetindicatesthattheheaderblock(Section4.3)isthelastthatthe
endpointwillsendfortheidentifiedstream.
AHEADERSframecarriestheEND_STREAMflagthatsignalstheendofastream.However,a
HEADERSframewiththeEND_STREAMflagsetcanbefollowedbyCONTINUATIONframesonthe
samestream.Logically,theCONTINUATIONframesarepartoftheHEADERSframe.
END_HEADERS(0x4): Bit2beingsetindicatesthatthisframecontainsanentireheaderblock
(Section4.3)andisnotfollowedbyanyCONTINUATIONframes.
AHEADERSframewithouttheEND_HEADERSflagsetMUSTbefollowedbyaCONTINUATION
25/65
11/02/2015
frameforthesamestream.AreceiverMUSTtreatthereceiptofanyothertypeofframeoraframe
onadifferentstreamasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
present.
PRIORITY(0x20): Bit5beingsetindicatesthattheExclusiveFlag(E),StreamDependency,and
Weightfieldsarepresent;seeSection5.3.
ThepayloadofaHEADERSframecontainsaheaderblockfragment(Section4.3).Aheaderblockthat
doesnotfitwithinaHEADERSframeiscontinuedinaCONTINUATIONframe(Section6.10).
HEADERSframesMUSTbeassociatedwithastream.IfaHEADERSframeisreceivedwhosestream
identifierfieldis0x0,therecipientMUSTrespondwithaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
TheHEADERSframechangestheconnectionstateasdescribedinSection4.3.
TheHEADERSframecanincludepadding.Paddingfieldsandflagsareidenticaltothosedefinedfor
DATAframes(Section6.1).
PrioritizationinformationinaHEADERSframeislogicallyequivalenttoaseparatePRIORITYframe,
butinclusioninHEADERSavoidsthepotentialforchurninstreamprioritizationwhennewstreams
arecreated.PrioritizationfieldsinHEADERSframessubsequenttothefirstonastreamreprioritize
thestream(Section5.3.3).
6.3PRIORITY
ThePRIORITYframe(type=0x2)specifiesthesenderadvisedpriorityofastream(Section5.3).Itcan
besentatanytimeforanystream,includingidleorclosedstreams.
+++
|E|StreamDependency(31)|
++++
|Weight(8)|
+++
Figure8:PRIORITYFramePayload
ThepayloadofaPRIORITYframecontainsthefollowingfields:
E:
Asinglebitflagindicatesthatthestreamdependencyisexclusive,seeSection5.3.
StreamDependency: A31bitstreamidentifierforthestreamthatthisstreamdependson,see
Section5.3.
Weight: Anunsigned8bitintegerrepresentingapriorityweightforthestream,seeSection5.3.Add
onetothevaluetoobtainaweightbetween1and256.
ThePRIORITYframedoesnotdefineanyflags.
ThePRIORITYframealwaysidentifiesastream.IfaPRIORITYframeisreceivedwithastream
identifierof0x0,therecipientMUSTrespondwithaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
ThePRIORITYframecanbesentonastreaminanystate,thoughitcannotbesentbetween
consecutiveframesthatcompriseasingleheaderblock(Section4.3).Notethatthisframecouldarrive
26/65
11/02/2015
afterprocessingorframesendinghascompleted,whichwouldcauseittohavenoeffectonthe
identifiedstream.Forastreamthatisinthe"halfclosed(remote)"or"closed"state,thisframecan
onlyaffectprocessingoftheidentifiedstreamanditsdependentstreamsandnotframetransmission
onthatstream.
ThePRIORITYframecanbesentforastreaminthe"idle"or"closed"states.Thisallowsforthe
reprioritizationofagroupofdependentstreamsbyalteringthepriorityofanunusedorclosedparent
stream.
APRIORITYframewithalengthotherthan5octetsMUSTbetreatedasastreamerror(Section5.4.2)
oftypeFRAME_SIZE_ERROR.
6.4RST_STREAM
TheRST_STREAMframe(type=0x3)allowsforimmediateterminationofastream.RST_STREAMis
senttorequestcancellationofastream,ortoindicatethatanerrorconditionhasoccurred.
++
|ErrorCode(32)|
++
Figure9:RST_STREAMFramePayload
TheRST_STREAMframecontainsasingleunsigned,32bitintegeridentifyingtheerrorcode
(Section7).Theerrorcodeindicateswhythestreamisbeingterminated.
TheRST_STREAMframedoesnotdefineanyflags.
TheRST_STREAMframefullyterminatesthereferencedstreamandcausesittoentertheclosedstate.
AfterreceivingaRST_STREAMonastream,thereceiverMUSTNOTsendadditionalframesforthat
stream,withtheexceptionofPRIORITY.However,aftersendingtheRST_STREAM,thesending
endpointMUSTbepreparedtoreceiveandprocessadditionalframessentonthestreamthatmight
havebeensentbythepeerpriortothearrivaloftheRST_STREAM.
RST_STREAMframesMUSTbeassociatedwithastream.IfaRST_STREAMframeisreceivedwitha
streamidentifierof0x0,therecipientMUSTtreatthisasaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
RST_STREAMframesMUSTNOTbesentforastreaminthe"idle"state.IfaRST_STREAMframe
identifyinganidlestreamisreceived,therecipientMUSTtreatthisasaconnectionerror
(Section5.4.1)oftypePROTOCOL_ERROR.
ARST_STREAMframewithalengthotherthan4octetsMUSTbetreatedasaconnectionerror
(Section5.4.1)oftypeFRAME_SIZE_ERROR.
6.5SETTINGS
TheSETTINGSframe(type=0x4)conveysconfigurationparametersthataffecthowendpoints
communicate,suchaspreferencesandconstraintsonpeerbehavior.TheSETTINGSframeisalsoused
toacknowledgethereceiptofthoseparameters.Individually,aSETTINGSparametercanalsobe
referredtoasa"setting".
SETTINGSparametersarenotnegotiated;theydescribecharacteristicsofthesendingpeer,whichare
usedbythereceivingpeer.Differentvaluesforthesameparametercanbeadvertisedbyeachpeer.
Forexample,aclientmightsetahighinitialflowcontrolwindow,whereasaservermightsetalower
27/65
11/02/2015
valuetoconserveresources.
ASETTINGSframeMUSTbesentbybothendpointsatthestartofaconnection,andMAYbesentat
anyothertimebyeitherendpointoverthelifetimeoftheconnection.ImplementationsMUSTsupport
alloftheparametersdefinedbythisspecification.
EachparameterinaSETTINGSframereplacesanyexistingvalueforthatparameter.Parametersare
processedintheorderinwhichtheyappear,andareceiverofaSETTINGSframedoesnotneedto
maintainanystateotherthanthecurrentvalueofitsparameters.Therefore,thevalueofaSETTINGS
parameteristhelastvaluethatisseenbyareceiver.
SETTINGSparametersareacknowledgedbythereceivingpeer.Toenablethis,theSETTINGSframe
definesthefollowingflag:
ACK(0x1): Bit0beingsetindicatesthatthisframeacknowledgesreceiptandapplicationofthepeer's
SETTINGSframe.Whenthisbitisset,thepayloadoftheSETTINGSframeMUSTbeempty.Receipt
ofaSETTINGSframewiththeACKflagsetandalengthfieldvalueotherthan0MUSTbetreated
asaconnectionerror(Section5.4.1)oftypeFRAME_SIZE_ERROR.Formoreinfo,seeSettings
Synchronization(Section6.5.3).
SETTINGSframesalwaysapplytoaconnection,neverasinglestream.Thestreamidentifierfora
SETTINGSframeMUSTbezero(0x0).IfanendpointreceivesaSETTINGSframewhosestream
identifierfieldisanythingotherthan0x0,theendpointMUSTrespondwithaconnectionerror
TheSETTINGSframeaffectsconnectionstate.AbadlyformedorincompleteSETTINGSframeMUSTbe
treatedasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
ASETTINGSframewithalengthotherthanamultipleof6octetsMUSTbetreatedasaconnection
error(Section5.4.1)oftypeFRAME_SIZE_ERROR.
6.5.1SETTINGSFormat
ThepayloadofaSETTINGSframeconsistsofzeroormoreparameters,eachconsistingofanunsigned
16bitsettingidentifierandanunsigned32bitvalue.
++
|Identifier(16)|
+++
|Value(32)|
++
Figure10:SettingFormat
6.5.2DefinedSETTINGSParameters
Thefollowingparametersaredefined:
SETTINGS_HEADER_TABLE_SIZE(0x1): Allowsthesendertoinformtheremoteendpointofthe
maximumsizeoftheheadercompressiontableusedtodecodeheaderblocks,inoctets.The
encodercanselectanysizeequaltoorlessthanthisvaluebyusingsignalingspecifictotheheader
compressionformatinsideaheaderblock,see[COMPRESSION].Theinitialvalueis4,096octets.
SETTINGS_ENABLE_PUSH(0x2): Thissettingcanbeusetodisableserverpush(Section8.2).An
endpointMUSTNOTsendaPUSH_PROMISEframeifitreceivesthisparametersettoavalueof0.
28/65
11/02/2015
Anendpointthathasbothsetthisparameterto0andhaditacknowledgedMUSTtreatthereceipt
ofaPUSH_PROMISEframeasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
Theinitialvalueis1,whichindicatesthatserverpushispermitted.Anyvalueotherthan0or1
MUSTbetreatedasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
SETTINGS_MAX_CONCURRENT_STREAMS(0x3): Indicatesthemaximumnumberofconcurrent
streamsthatthesenderwillallow.Thislimitisdirectional:itappliestothenumberofstreams
thatthesenderpermitsthereceivertocreate.Initiallythereisnolimittothisvalue.Itis
recommendedthatthisvaluebenosmallerthan100,soastonotunnecessarilylimitparallelism.
Avalueof0forSETTINGS_MAX_CONCURRENT_STREAMSSHOULDNOTbetreatedasspecialby
endpoints.Azerovaluedoespreventthecreationofnewstreams,howeverthiscanalsohappen
foranylimitthatisexhaustedwithactivestreams.ServersSHOULDonlysetazerovalueforshort
durations;ifaserverdoesnotwishtoacceptrequests,closingtheconnectionismoreappropriate.
SETTINGS_INITIAL_WINDOW_SIZE(0x4): Indicatesthesender'sinitialwindowsize(inoctets)for
streamlevelflowcontrol.Theinitialvalueis2161(65,535)octets.
Thissettingaffectsthewindowsizeofallstreams,seeSection6.9.2.
Valuesabovethemaximumflowcontrolwindowsizeof2311MUSTbetreatedasaconnection
error(Section5.4.1)oftypeFLOW_CONTROL_ERROR.
SETTINGS_MAX_FRAME_SIZE(0x5): Indicatesthesizeofthelargestframepayloadthatthesenderis
willingtoreceive,inoctets.
Theinitialvalueis214(16,384)octets.ThevalueadvertisedbyanendpointMUSTbebetweenthis
initialvalueandthemaximumallowedframesize(2241or16,777,215octets),inclusive.Values
outsidethisrangeMUSTbetreatedasaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
SETTINGS_MAX_HEADER_LIST_SIZE(0x6): Thisadvisorysettinginformsapeerofthemaximumsize
ofheaderlistthatthesenderispreparedtoaccept,inoctets.Thevalueisbasedonthe
uncompressedsizeofheaderfields,includingthelengthofthenameandvalueinoctetsplusan
overheadof32octetsforeachheaderfield.
Foranygivenrequest,alowerlimitthanwhatisadvertisedMAYbeenforced.Theinitialvalueof
thissettingisunlimited.
AnendpointthatreceivesaSETTINGSframewithanyunknownorunsupportedidentifierMUST
ignorethatsetting.
6.5.3SettingsSynchronization
MostvaluesinSETTINGSbenefitfromorrequireanunderstandingofwhenthepeerhasreceivedand
appliedthechangedparametervalues.Inordertoprovidesuchsynchronizationtimepoints,the
recipientofaSETTINGSframeinwhichtheACKflagisnotsetMUSTapplytheupdatedparametersas
soonaspossibleuponreceipt.
ThevaluesintheSETTINGSframeMUSTbeprocessedintheordertheyappear,withnootherframe
processingbetweenvalues.UnsupportedparametersMUSTbeignored.Onceallvalueshavebeen
processed,therecipientMUSTimmediatelyemitaSETTINGSframewiththeACKflagset.Upon
receivingaSETTINGSframewiththeACKflagset,thesenderofthealteredparameterscanrelyonthe
settinghavingbeenapplied.
IfthesenderofaSETTINGSframedoesnotreceiveanacknowledgementwithinareasonableamount
oftime,itMAYissueaconnectionerror(Section5.4.1)oftypeSETTINGS_TIMEOUT.
29/65
11/02/2015
6.6PUSH_PROMISE
ThePUSH_PROMISEframe(type=0x5)isusedtonotifythepeerendpointinadvanceofstreamsthe
senderintendstoinitiate.ThePUSH_PROMISEframeincludestheunsigned31bitidentifierofthe
streamtheendpointplanstocreatealongwithasetofheadersthatprovideadditionalcontextforthe
stream.Section8.2containsathoroughdescriptionoftheuseofPUSH_PROMISEframes.
++
|PadLength?(8)|
++++
|R|PromisedStreamID(31)|
++++
++
|Padding(*)...
++
Figure11:PUSH_PROMISEPayloadFormat
ThePUSH_PROMISEframepayloadhasthefollowingfields:
onlypresentifthePADDEDflagisset.
R:
Asinglereservedbit.
PromisedStreamID: Anunsigned31bitintegerthatidentifiesthestreamthatisreservedbythe
PUSH_PROMISE.ThepromisedstreamidentifierMUSTbeavalidchoiceforthenextstreamsent
bythesender(seenewstreamidentifier(Section5.1.1)).
HeaderBlockFragment: Aheaderblockfragment(Section4.3)containingrequestheaderfields.
Padding: Paddingoctets.
ThePUSH_PROMISEframedefinesthefollowingflags:
END_HEADERS(0x4): Bit2beingsetindicatesthatthisframecontainsanentireheaderblock
(Section4.3)andisnotfollowedbyanyCONTINUATIONframes.
APUSH_PROMISEframewithouttheEND_HEADERSflagsetMUSTbefollowedbya
CONTINUATIONframeforthesamestream.AreceiverMUSTtreatthereceiptofanyothertypeof
frameoraframeonadifferentstreamasaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
present.
PUSH_PROMISEframesMUSTbeassociatedwithapeerinitiatedstreamthatisineitherthe"open"or
"halfclosed(remote)"state.ThestreamidentifierofaPUSH_PROMISEframeindicatesthestreamitis
associatedwith.Ifthestreamidentifierfieldspecifiesthevalue0x0,arecipientMUSTrespondwitha
connectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
Promisedstreamsarenotrequiredtobeusedintheordertheyarepromised.ThePUSH_PROMISE
onlyreservesstreamidentifiersforlateruse.
PUSH_PROMISEMUSTNOTbesentiftheSETTINGS_ENABLE_PUSHsettingofthepeerendpointisset
to0.AnendpointthathassetthissettingandhasreceivedacknowledgementMUSTtreatthereceiptof
aPUSH_PROMISEframeasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
30/65
11/02/2015
RecipientsofPUSH_PROMISEframescanchoosetorejectpromisedstreamsbyreturninga
RST_STREAMreferencingthepromisedstreamidentifierbacktothesenderofthePUSH_PROMISE.
APUSH_PROMISEframemodifiestheconnectionstateintwoways.Theinclusionofaheaderblock
(Section4.3)potentiallymodifiesthestatemaintainedforheadercompression.PUSH_PROMISEalso
reservesastreamforlateruse,causingthepromisedstreamtoenterthe"reserved"state.Asender
MUSTNOTsendaPUSH_PROMISEonastreamunlessthatstreamiseither"open"or"halfclosed
(remote)";thesenderMUSTensurethatthepromisedstreamisavalidchoiceforanewstream
identifier(Section5.1.1)(thatis,thepromisedstreamMUSTbeinthe"idle"state).
SincePUSH_PROMISEreservesastream,ignoringaPUSH_PROMISEframecausesthestreamstateto
becomeindeterminate.AreceiverMUSTtreatthereceiptofaPUSH_PROMISEonastreamthatis
neither"open"nor"halfclosed(local)"asaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.However,anendpointthathassentRST_STREAMontheassociatedstreamMUST
handlePUSH_PROMISEframesthatmighthavebeencreatedbeforetheRST_STREAMframeis
receivedandprocessed.
AreceiverMUSTtreatthereceiptofaPUSH_PROMISEthatpromisesanillegalstreamidentifier
(Section5.1.1)(thatis,anidentifierforastreamthatisnotcurrentlyinthe"idle"state)asa
connectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
ThePUSH_PROMISEframecanincludepadding.Paddingfieldsandflagsareidenticaltothosedefined
forDATAframes(Section6.1).
6.7PING
ThePINGframe(type=0x6)isamechanismformeasuringaminimalroundtriptimefromthesender,
aswellasdeterminingwhetheranidleconnectionisstillfunctional.PINGframescanbesentfromany
endpoint.
++
||
|OpaqueData(64)|
||
++
Figure12:PINGPayloadFormat
Inadditiontotheframeheader,PINGframesMUSTcontain8octetsofdatainthepayload.Asender
canincludeanyvalueitchoosesandusethoseoctetsinanyfashion.
ReceiversofaPINGframethatdoesnotincludeanACKflagMUSTsendaPINGframewiththeACKflag
setinresponse,withanidenticalpayload.PINGresponsesSHOULDbegivenhigherprioritythanany
otherframe.
ThePINGframedefinesthefollowingflags:
ACK(0x1): Bit0beingsetindicatesthatthisPINGframeisaPINGresponse.AnendpointMUSTset
thisflaginPINGresponses.AnendpointMUSTNOTrespondtoPINGframescontainingthisflag.
PINGframesarenotassociatedwithanyindividualstream.IfaPINGframeisreceivedwithastream
identifierfieldvalueotherthan0x0,therecipientMUSTrespondwithaconnectionerror
ReceiptofaPINGframewithalengthfieldvalueotherthan8MUSTbetreatedasaconnectionerror
31/65
11/02/2015
6.8GOAWAY
TheGOAWAYframe(type=0x7)informstheremotepeertostopcreatingstreamsonthisconnection.
GOAWAYcanbesentbyeithertheclientortheserver.Oncesent,thesenderwillignoreframessenton
anynewstreamswithidentifiershigherthantheincludedlaststreamidentifier.Receiversofa
GOAWAYframeMUSTNOTopenadditionalstreamsontheconnection,althoughanewconnectioncan
beestablishedfornewstreams.
Thepurposeofthisframeistoallowanendpointtogracefullystopacceptingnewstreams,whilestill
finishingprocessingofpreviouslyestablishedstreams.Thisenablesadministrativeactions,likeserver
maintenance.
Thereisaninherentraceconditionbetweenanendpointstartingnewstreamsandtheremotesending
aGOAWAYframe.Todealwiththiscase,theGOAWAYcontainsthestreamidentifierofthelastpeer
initiatedstreamwhichwasormightbeprocessedonthesendingendpointinthisconnection.For
instance,iftheserversendsaGOAWAYframe,theidentifiedstreamisthehighestnumberedstream
initiatedbytheclient.
IfthereceiveroftheGOAWAYhassentdataonstreamswithahigherstreamidentifierthanwhatis
indicatedintheGOAWAYframe,thosestreamsarenotorwillnotbeprocessed.Thereceiverofthe
GOAWAYframecantreatthestreamsasthoughtheyhadneverbeencreatedatall,therebyallowing
thosestreamstoberetriedlateronanewconnection.
EndpointsSHOULDalwayssendaGOAWAYframebeforeclosingaconnectionsothattheremotepeer
canknowwhetherastreamhasbeenpartiallyprocessedornot.Forexample,ifanHTTPclientsendsa
POSTatthesametimethataserverclosesaconnection,theclientcannotknowiftheserverstartedto
processthatPOSTrequestiftheserverdoesnotsendaGOAWAYframetoindicatewhatstreamsit
mighthaveactedon.
AnendpointmightchoosetocloseaconnectionwithoutsendingGOAWAYformisbehavingpeers.
+++
|R|LastStreamID(31)|
+++
|ErrorCode(32)|
++
|AdditionalDebugData(*)|
++
Figure13:GOAWAYPayloadFormat
TheGOAWAYframedoesnotdefineanyflags.
TheGOAWAYframeappliestotheconnection,notaspecificstream.AnendpointMUSTtreata
GOAWAYframewithastreamidentifierotherthan0x0asaconnectionerror(Section5.4.1)oftype
PROTOCOL_ERROR.
ThelaststreamidentifierintheGOAWAYframecontainsthehighestnumberedstreamidentifierfor
whichthesenderoftheGOAWAYframemighthavetakensomeactionon,ormightyettakeactionon.
Allstreamsuptoandincludingtheidentifiedstreammighthavebeenprocessedinsomeway.Thelast
streamidentifiercanbesetto0ifnostreamswereprocessed.
Note: Inthiscontext,"processed"meansthatsomedatafromthestreamwaspassedtosomehigher
32/65
11/02/2015
layerofsoftwarethatmighthavetakensomeactionasaresult.
IfaconnectionterminateswithoutaGOAWAYframe,thelaststreamidentifieriseffectivelythehighest
possiblestreamidentifier.
Onstreamswithlowerorequalnumberedidentifiersthatwerenotclosedcompletelypriortothe
connectionbeingclosed,reattemptingrequests,transactions,oranyprotocolactivityisnotpossible,
withtheexceptionofidempotentactionslikeHTTPGET,PUT,orDELETE.Anyprotocolactivitythat
useshighernumberedstreamscanbesafelyretriedusinganewconnection.
Activityonstreamsnumberedlowerorequaltothelaststreamidentifiermightstillcomplete
successfully.ThesenderofaGOAWAYframemightgracefullyshutdownaconnectionbysendinga
GOAWAYframe,maintainingtheconnectioninanopenstateuntilallinprogressstreamscomplete.
AnendpointMAYsendmultipleGOAWAYframesifcircumstanceschange.Forinstance,anendpoint
thatsendsGOAWAYwithNO_ERRORduringgracefulshutdowncouldsubsequentlyencountera
conditionthatrequiresimmediateterminationoftheconnection.Thelaststreamidentifierfromthe
lastGOAWAYframereceivedindicateswhichstreamscouldhavebeenactedupon.EndpointsMUST
NOTincreasethevaluetheysendinthelaststreamidentifier,sincethepeersmightalreadyhave
retriedunprocessedrequestsonanotherconnection.
Aclientthatisunabletoretryrequestslosesallrequeststhatareinflightwhentheserverclosesthe
connection.ThisisespeciallytrueforintermediariesthatmightnotbeservingclientsusingHTTP/2.A
serverthatisattemptingtogracefullyshutdownaconnectionSHOULDsendaninitialGOAWAYframe
withthelaststreamidentifiersetto2311andaNO_ERRORcode.Thissignalstotheclientthata
shutdownisimminentandthatnofurtherrequestscanbeinitiated.Afterwaitingatleastoneround
triptime,theservercansendanotherGOAWAYframewithanupdatedlaststreamidentifier.This
ensuresthataconnectioncanbecleanlyshutdownwithoutlosingrequests.
AftersendingaGOAWAYframe,thesendercandiscardframesforstreamswithidentifiershigherthan
theidentifiedlaststream.However,anyframesthatalterconnectionstatecannotbecompletely
ignored.Forinstance,HEADERS,PUSH_PROMISEandCONTINUATIONframesMUSTbeminimally
processedtoensurethestatemaintainedforheadercompressionisconsistent(seeSection4.3);
similarlyDATAframesMUSTbecountedtowardtheconnectionflowcontrolwindow.Failureto
processtheseframescancauseflowcontrolorheadercompressionstatetobecomeunsynchronized.
TheGOAWAYframealsocontainsa32biterrorcode(Section7)thatcontainsthereasonforclosing
theconnection.
EndpointsMAYappendopaquedatatothepayloadofanyGOAWAYframe.Additionaldebugdatais
intendedfordiagnosticpurposesonlyandcarriesnosemanticvalue.Debuginformationcouldcontain
securityorprivacysensitivedata.LoggedorotherwisepersistentlystoreddebugdataMUSThave
adequatesafeguardstopreventunauthorizedaccess.
6.9WINDOW_UPDATE
TheWINDOW_UPDATEframe(type=0x8)isusedtoimplementflowcontrol;seeSection5.2foran
overview.
Flowcontroloperatesattwolevels:oneachindividualstreamandontheentireconnection.
Bothtypesofflowcontrolarehopbyhop;thatis,onlybetweenthetwoendpoints.Intermediariesdo
notforwardWINDOW_UPDATEframesbetweendependentconnections.However,throttlingofdata
transferbyanyreceivercanindirectlycausethepropagationofflowcontrolinformationtowardthe
33/65
11/02/2015
originalsender.
Flowcontrolonlyappliestoframesthatareidentifiedasbeingsubjecttoflowcontrol.Oftheframe
typesdefinedinthisdocument,thisincludesonlyDATAframes.Framesthatareexemptfromflow
controlMUSTbeacceptedandprocessed,unlessthereceiverisunabletoassignresourcestohandling
theframe.AreceiverMAYrespondwithastreamerror(Section5.4.2)orconnectionerror
(Section5.4.1)oftypeFLOW_CONTROL_ERRORifitisunabletoacceptaframe.
+++
|R|WindowSizeIncrement(31)|
+++
Figure14:WINDOW_UPDATEPayloadFormat
ThepayloadofaWINDOW_UPDATEframeisonereservedbit,plusanunsigned31bitinteger
indicatingthenumberofoctetsthatthesendercantransmitinadditiontotheexistingflowcontrol
window.Thelegalrangefortheincrementtotheflowcontrolwindowis1to2311(2,147,483,647)
octets.
TheWINDOW_UPDATEframedoesnotdefineanyflags.
TheWINDOW_UPDATEframecanbespecifictoastreamortotheentireconnection.Intheformer
case,theframe'sstreamidentifierindicatestheaffectedstream;inthelatter,thevalue"0"indicates
thattheentireconnectionisthesubjectoftheframe.
AreceiverMUSTtreatthereceiptofaWINDOW_UPDATEframewithanflowcontrolwindow
incrementof0asastreamerror(Section5.4.2)oftypePROTOCOL_ERROR;errorsontheconnection
flowcontrolwindowMUSTbetreatedasaconnectionerror(Section5.4.1).
WINDOW_UPDATEcanbesentbyapeerthathassentaframebearingtheEND_STREAMflag.This
meansthatareceivercouldreceiveaWINDOW_UPDATEframeona"halfclosed(remote)"or"closed"
stream.AreceiverMUSTNOTtreatthisasanerror,seeSection5.1.
AreceiverthatreceivesaflowcontrolledframeMUSTalwaysaccountforitscontributionagainstthe
connectionflowcontrolwindow,unlessthereceivertreatsthisasaconnectionerror(Section5.4.1).
Thisisnecessaryeveniftheframeisinerror.Sincethesendercountstheframetowardtheflow
controlwindow,ifthereceiverdoesnot,theflowcontrolwindowatsenderandreceivercanbecome
different.
AWINDOW_UPDATEframewithalengthotherthan4octetsMUSTbetreatedasaconnectionerror
6.9.1TheFlowControlWindow
FlowcontrolinHTTP/2isimplementedusingawindowkeptbyeachsenderoneverystream.The
flowcontrolwindowisasimpleintegervaluethatindicateshowmanyoctetsofdatathesenderis
permittedtotransmit;assuch,itssizeisameasureofthebufferingcapacityofthereceiver.
Twoflowcontrolwindowsareapplicable:thestreamflowcontrolwindowandtheconnectionflow
controlwindow.ThesenderMUSTNOTsendaflowcontrolledframewithalengththatexceedsthe
spaceavailableineitheroftheflowcontrolwindowsadvertisedbythereceiver.Frameswithzero
lengthwiththeEND_STREAMflagset(thatis,anemptyDATAframe)MAYbesentifthereisno
availablespaceineitherflowcontrolwindow.
34/65
11/02/2015
Forflowcontrolcalculations,the9octetframeheaderisnotcounted.
Aftersendingaflowcontrolledframe,thesenderreducesthespaceavailableinbothwindowsbythe
lengthofthetransmittedframe.
ThereceiverofaframesendsaWINDOW_UPDATEframeasitconsumesdataandfreesupspacein
flowcontrolwindows.SeparateWINDOW_UPDATEframesaresentforthestreamandconnection
levelflowcontrolwindows.
AsenderthatreceivesaWINDOW_UPDATEframeupdatesthecorrespondingwindowbytheamount
specifiedintheframe.
AsenderMUSTNOTallowaflowcontrolwindowtoexceed2311octets.Ifasenderreceivesa
WINDOW_UPDATEthatcausesaflowcontrolwindowtoexceedthismaximumitMUSTterminate
eitherthestreamortheconnection,asappropriate.Forstreams,thesendersendsaRST_STREAMwith
theerrorcodeofFLOW_CONTROL_ERRORcode;fortheconnection,aGOAWAYframewitha
FLOW_CONTROL_ERRORcode.
FlowcontrolledframesfromthesenderandWINDOW_UPDATEframesfromthereceiverare
completelyasynchronouswithrespecttoeachother.Thispropertyallowsareceivertoaggressively
updatethewindowsizekeptbythesendertopreventstreamsfromstalling.
6.9.2InitialFlowControlWindowSize
WhenanHTTP/2connectionisfirstestablished,newstreamsarecreatedwithaninitialflowcontrol
windowsizeof65,535octets.Theconnectionflowcontrolwindowis65,535octets.Bothendpoints
canadjusttheinitialwindowsizefornewstreamsbyincludingavaluefor
SETTINGS_INITIAL_WINDOW_SIZEintheSETTINGSframethatformspartoftheconnectionpreface.
TheconnectionflowcontrolwindowcanonlybechangedusingWINDOW_UPDATEframes.
PriortoreceivingaSETTINGSframethatsetsavalueforSETTINGS_INITIAL_WINDOW_SIZE,an
endpointcanonlyusethedefaultinitialwindowsizewhensendingflowcontrolledframes.Similarly,
theconnectionflowcontrolwindowissettothedefaultinitialwindowsizeuntilaWINDOW_UPDATE
frameisreceived.
ASETTINGSframecanaltertheinitialflowcontrolwindowsizeforallstreamsinthe"open"or"half
closed(remote)"state.WhenthevalueofSETTINGS_INITIAL_WINDOW_SIZEchanges,areceiverMUST
adjustthesizeofallstreamflowcontrolwindowsthatitmaintainsbythedifferencebetweenthenew
valueandtheoldvalue.
AchangetoSETTINGS_INITIAL_WINDOW_SIZEcancausetheavailablespaceinaflowcontrolwindow
tobecomenegative.AsenderMUSTtrackthenegativeflowcontrolwindow,andMUSTNOTsendnew
flowcontrolledframesuntilitreceivesWINDOW_UPDATEframesthatcausetheflowcontrolwindow
tobecomepositive.
Forexample,iftheclientsends60KBimmediatelyonconnectionestablishment,andtheserversets
theinitialwindowsizetobe16KB,theclientwillrecalculatetheavailableflowcontrolwindowtobe
44KBonreceiptoftheSETTINGSframe.Theclientretainsanegativeflowcontrolwindowuntil
WINDOW_UPDATEframesrestorethewindowtobeingpositive,afterwhichtheclientcanresume
sending.
ASETTINGSframecannotaltertheconnectionflowcontrolwindow.
AnendpointMUSTtreatachangetoSETTINGS_INITIAL_WINDOW_SIZEthatcausesanyflowcontrol
35/65
11/02/2015
windowtoexceedthemaximumsizeasaconnectionerror(Section5.4.1)oftype
FLOW_CONTROL_ERROR.
6.9.3ReducingtheStreamWindowSize
Areceiverthatwishestouseasmallerflowcontrolwindowthanthecurrentsizecansendanew
SETTINGSframe.However,thereceiverMUSTbepreparedtoreceivedatathatexceedsthiswindow
size,sincethesendermightsenddatathatexceedsthelowerlimitpriortoprocessingtheSETTINGS
frame.
AftersendingaSETTINGSframethatreducestheinitialflowcontrolwindowsize,areceiverMAY
continuetoprocessstreamsthatexceedflowcontrollimits.Allowingstreamstocontinuedoesnot
allowthereceivertoimmediatelyreducethespaceitreservesforflowcontrolwindows.Progresson
thesestreamscanalsostall,sinceWINDOW_UPDATEframesareneededtoallowthesendertoresume
sending.ThereceiverMAYinsteadsendaRST_STREAMwithFLOW_CONTROL_ERRORerrorcodefor
theaffectedstreams.
6.10CONTINUATION
TheCONTINUATIONframe(type=0x9)isusedtocontinueasequenceofheaderblockfragments
(Section4.3).AnynumberofCONTINUATIONframescanbesent,aslongastheprecedingframeison
thesamestreamandisaHEADERS,PUSH_PROMISEorCONTINUATIONframewithoutthe
END_HEADERSflagset.
++
++
Figure15:CONTINUATIONFramePayload
TheCONTINUATIONframepayloadcontainsaheaderblockfragment(Section4.3).
TheCONTINUATIONframedefinesthefollowingflag:
END_HEADERS(0x4): Bit2beingsetindicatesthatthisframeendsaheaderblock(Section4.3).
IftheEND_HEADERSbitisnotset,thisframeMUSTbefollowedbyanotherCONTINUATION
frame.AreceiverMUSTtreatthereceiptofanyothertypeofframeoraframeonadifferent
streamasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
TheCONTINUATIONframechangestheconnectionstateasdefinedinSection4.3.
CONTINUATIONframesMUSTbeassociatedwithastream.IfaCONTINUATIONframeisreceived
whosestreamidentifierfieldis0x0,therecipientMUSTrespondwithaconnectionerror
ACONTINUATIONframeMUSTbeprecededbyaHEADERS,PUSH_PROMISEorCONTINUATIONframe
withouttheEND_HEADERSflagset.ArecipientthatobservesviolationofthisruleMUSTrespondwith
aconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.
7.ErrorCodes
Errorcodesare32bitfieldsthatareusedinRST_STREAMandGOAWAYframestoconveythereasons
forthestreamorconnectionerror.
36/65
11/02/2015
Errorcodesshareacommoncodespace.Someerrorcodesapplyonlytoeitherstreamsortheentire
connectionandhavenodefinedsemanticsintheothercontext.
Thefollowingerrorcodesaredefined:
NO_ERROR(0x0): Theassociatedconditionisnotasaresultofanerror.Forexample,aGOAWAY
mightincludethiscodetoindicategracefulshutdownofaconnection.
PROTOCOL_ERROR(0x1): Theendpointdetectedanunspecificprotocolerror.Thiserrorisforuse
whenamorespecificerrorcodeisnotavailable.
INTERNAL_ERROR(0x2): Theendpointencounteredanunexpectedinternalerror.
FLOW_CONTROL_ERROR(0x3): Theendpointdetectedthatitspeerviolatedtheflowcontrolprotocol.
SETTINGS_TIMEOUT(0x4): TheendpointsentaSETTINGSframe,butdidnotreceivearesponseina
timelymanner.SeeSettingsSynchronization(Section6.5.3).
STREAM_CLOSED(0x5): Theendpointreceivedaframeafterastreamwashalfclosed.
FRAME_SIZE_ERROR(0x6): Theendpointreceivedaframewithaninvalidsize.
REFUSED_STREAM(0x7): Theendpointrefusesthestreampriortoperforminganyapplication
processing,seeSection8.1.4fordetails.
CANCEL(0x8): Usedbytheendpointtoindicatethatthestreamisnolongerneeded.
COMPRESSION_ERROR(0x9): Theendpointisunabletomaintaintheheadercompressioncontextfor
theconnection.
CONNECT_ERROR(0xa): TheconnectionestablishedinresponsetoaCONNECTrequest(Section8.3)
wasresetorabnormallyclosed.
ENHANCE_YOUR_CALM(0xb): Theendpointdetectedthatitspeerisexhibitingabehaviorthatmight
begeneratingexcessiveload.
INADEQUATE_SECURITY(0xc): Theunderlyingtransporthaspropertiesthatdonotmeetminimum
securityrequirements(seeSection9.2).
HTTP_1_1_REQUIRED(0xd): TheendpointrequiresthatHTTP/1.1beusedinsteadofHTTP/2.
UnknownorunsupportederrorcodesMUSTNOTtriggeranyspecialbehavior.TheseMAYbetreated
byanimplementationasbeingequivalenttoINTERNAL_ERROR.
8.HTTPMessageExchanges
HTTP/2isintendedtobeascompatibleaspossiblewithcurrentusesofHTTP.Thismeansthat,from
theapplicationperspective,thefeaturesoftheprotocolarelargelyunchanged.Toachievethis,all
requestandresponsesemanticsarepreserved,althoughthesyntaxofconveyingthosesemanticshas
changed.
Thus,thespecificationandrequirementsofHTTP/1.1SemanticsandContent[RFC7231],Conditional
Requests[RFC7232],RangeRequests[RFC7233],Caching[RFC7234]andAuthentication[RFC7235]
areapplicabletoHTTP/2.SelectedportionsofHTTP/1.1MessageSyntaxandRouting[RFC7230],such
astheHTTPandHTTPSURIschemes,arealsoapplicableinHTTP/2,buttheexpressionofthose
semanticsforthisprotocolaredefinedinthesectionsbelow.
8.1HTTPRequest/ResponseExchange
AclientsendsanHTTPrequestonanewstream,usingapreviouslyunusedstreamidentifier
37/65
11/02/2015
(Section5.1.1).AserversendsanHTTPresponseonthesamestreamastherequest.
AnHTTPmessage(requestorresponse)consistsof:
1. foraresponseonly,zeroormoreHEADERSframes(eachfollowedbyzeroormore
CONTINUATIONframes)containingthemessageheadersofinformational(1xx)HTTPresponses
(see[RFC7230],Section3.2and[RFC7231],Section6.2),and
2. oneHEADERSframe(followedbyzeroormoreCONTINUATIONframes)containingthemessage
headers(see[RFC7230],Section3.2),and
3. zeroormoreDATAframescontainingthepayloadbody(see[RFC7230],Section3.3),and
4. optionally,oneHEADERSframe,followedbyzeroormoreCONTINUATIONframescontainingthe
trailerpart,ifpresent(see[RFC7230],Section4.1.2).
ThelastframeinthesequencebearsanEND_STREAMflag,notingthataHEADERSframebearingthe
END_STREAMflagcanbefollowedbyCONTINUATIONframesthatcarryanyremainingportionsofthe
headerblock.
Otherframes(fromanystream)MUSTNOToccurbetweeneitherHEADERSframeandany
CONTINUATIONframesthatmightfollow.
HTTP/2usesDATAframestocarrymessagepayloads.Thechunkedtransferencodingdefinedin
Section4.1of[RFC7230]MUSTNOTbeusedinHTTP/2.
Trailingheaderfieldsarecarriedinaheaderblockthatalsoterminatesthestream.Suchaheader
blockisasequencestartingwithaHEADERSframe,followedbyzeroormoreCONTINUATIONframes,
wheretheHEADERSframebearsanEND_STREAMflag.Headerblocksafterthefirstthatdonot
terminatethestreamarenotpartofanHTTPrequestorresponse.
AHEADERSframe(andassociatedCONTINUATIONframes)canonlyappearatthestartorendofa
stream.AnendpointthatreceivesaHEADERSframewithouttheEND_STREAMflagsetafterreceiving
afinal(noninformational)statuscodeMUSTtreatthecorrespondingrequestorresponseas
malformed(Section8.1.2.6).
AnHTTPrequest/responseexchangefullyconsumesasinglestream.Arequeststartswiththe
HEADERSframethatputsthestreamintoan"open"state.Therequestendswithaframebearing
END_STREAM,whichcausesthestreamtobecome"halfclosed(local)"fortheclientand"halfclosed
(remote)"fortheserver.AresponsestartswithaHEADERSframeandendswithaframebearing
END_STREAM,whichplacesthestreaminthe"closed"state.
AnHTTPresponseiscompleteaftertheserversendsortheclientreceivesaframewiththe
END_STREAMflagset(includinganyCONTINUATIONframesneededtocompleteaheaderblock).A
servercansendacompleteresponsepriortotheclientsendinganentirerequestiftheresponsedoes
notdependonanyportionoftherequestthathasnotbeensentandreceived.Whenthisistrue,a
serverMAYrequestthattheclientaborttransmissionofarequestwithouterrorbysendinga
RST_STREAMwithanerrorcodeofNO_ERRORaftersendingacompleteresponse(i.e.,aframewith
theEND_STREAMflag).ClientsMUSTNOTdiscardresponsesasaresultofreceivingsucha
RST_STREAM,thoughclientscanalwaysdiscardresponsesattheirdiscretionforotherreasons.
8.1.1UpgradingFromHTTP/2
HTTP/2removessupportforthe101(SwitchingProtocols)informationalstatuscode([RFC7231],
Section6.2.2).
Thesemanticsof101(SwitchingProtocols)aren'tapplicabletoamultiplexedprotocol.Alternative
38/65
11/02/2015
protocolsareabletousethesamemechanismsthatHTTP/2usestonegotiatetheiruse(seeSection3).
8.1.2HTTPHeaderFields
HTTPheaderfieldscarryinformationasaseriesofkeyvaluepairs.ForalistingofregisteredHTTP
headers,seetheMessageHeaderFieldRegistrymaintainedat
<https://www.iana.org/assignments/messageheaders>.
JustasinHTTP/1.x,headerfieldnamesarestringsofASCIIcharactersthatarecomparedinacase
insensitivefashion.However,headerfieldnamesMUSTbeconvertedtolowercasepriortotheir
encodinginHTTP/2.ArequestorresponsecontaininguppercaseheaderfieldnamesMUSTbetreated
asmalformed(Section8.1.2.6).
8.1.2.1PseudoHeaderFields
WhileHTTP/1.xusedthemessagestartline(see[RFC7230],Section3.1)toconveythetargetURIand
methodoftherequest,andthestatuscodefortheresponse,HTTP/2usesspecialpseudoheaderfields
beginningwith':'character(ASCII0x3a)forthispurpose.
PseudoheaderfieldsarenotHTTPheaderfields.EndpointsMUSTNOTgeneratepseudoheaderfields
otherthanthosedefinedinthisdocument.
Pseudoheaderfieldsareonlyvalidinthecontextinwhichtheyaredefined.Pseudoheaderfields
definedforrequestsMUSTNOTappearinresponses;pseudoheaderfieldsdefinedforresponses
MUSTNOTappearinrequests.PseudoheaderfieldsMUSTNOTappearintrailers.EndpointsMUST
treatarequestorresponsethatcontainsundefinedorinvalidpseudoheaderfieldsasmalformed
(Section8.1.2.6).
AllpseudoheaderfieldsMUSTappearintheheaderblockbeforeregularheaderfields.Anyrequestor
responsethatcontainsapseudoheaderfieldthatappearsinaheaderblockafteraregularheaderfield
MUSTbetreatedasmalformed(Section8.1.2.6).
8.1.2.2ConnectionSpecificHeaderFields
HTTP/2doesnotusetheConnectionheaderfieldtoindicateconnectionspecificheaderfields;inthis
protocol,connectionspecificmetadataisconveyedbyothermeans.AnendpointMUSTNOTgenerate
anHTTP/2messagecontainingconnectionspecificheaderfields;anymessagecontainingconnection
specificheaderfieldsMUSTbetreatedasmalformed(Section8.1.2.6).
TheonlyexceptiontothisistheTEheaderfield,whichMAYbepresentinanHTTP/2request;whenit
is,itMUSTNOTcontainanyvalueotherthan"trailers".
ThismeansthatanintermediarytransforminganHTTP/1.xmessagetoHTTP/2willneedtoremove
anyheaderfieldsnominatedbytheConnectionheaderfield,alongwiththeConnectionheaderfield
itself.SuchintermediariesSHOULDalsoremoveotherconnectionspecificheaderfields,suchasKeep
Alive,ProxyConnection,TransferEncodingandUpgrade,eveniftheyarenotnominatedby
Connection.
Note: HTTP/2purposefullydoesnotsupportupgradetoanotherprotocol.Thehandshakemethods
describedinSection3arebelievedsufficienttonegotiatetheuseofalternativeprotocols.
8.1.2.3RequestPseudoHeaderFields
39/65
11/02/2015
ThefollowingpseudoheaderfieldsaredefinedforHTTP/2requests:
The:methodpseudoheaderfieldincludestheHTTPmethod([RFC7231],Section4).
The:schemepseudoheaderfieldincludestheschemeportionofthetargetURI([RFC3986],
Section3.1).
:schemeisnotrestrictedtohttpandhttpsschemedURIs.Aproxyorgatewaycantranslate
requestsfornonHTTPschemes,enablingtheuseofHTTPtointeractwithnonHTTPservices.
The:authoritypseudoheaderfieldincludestheauthorityportionofthetargetURI([RFC3986],
Section3.2).TheauthorityMUSTNOTincludethedeprecateduserinfosubcomponentforhttp
orhttpsschemedURIs.
ToensurethattheHTTP/1.1requestlinecanbereproducedaccurately,thispseudoheaderfield
MUSTbeomittedwhentranslatingfromanHTTP/1.1requestthathasarequesttargetinorigin
orasteriskform(see[RFC7230],Section5.3).ClientsthatgenerateHTTP/2requestsdirectly
SHOULDusethe:authoritypseudoheaderfieldinsteadoftheHostheaderfield.An
intermediarythatconvertsanHTTP/2requesttoHTTP/1.1MUSTcreateaHostheaderfieldif
oneisnotpresentinarequestbycopyingthevalueofthe:authoritypseudoheaderfield.
The:pathpseudoheaderfieldincludesthepathandquerypartsofthetargetURI(thepath
absoluteproductionfrom[RFC3986]andoptionallya'?'characterfollowedbythequery
production,see[RFC3986],Section3.3and[RFC3986],Section3.4).Arequestinasteriskform
includesthevalue'*'forthe:pathpseudoheaderfield.
ThispseudoheaderfieldMUSTNOTbeemptyforhttporhttpsURIs;httporhttpsURIsthat
donotcontainapathcomponentMUSTincludeavalueof'/'.Theexceptiontothisruleisan
OPTIONSrequestforanhttporhttpsURIthatdoesnotincludeapathcomponent;theseMUST
includea:pathpseudoheaderfieldwithavalueof'*'(see[RFC7230],Section5.3.4).
AllHTTP/2requestsMUSTincludeexactlyonevalidvalueforthe:method,:scheme,and:path
pseudoheaderfields,unlessitisaCONNECTrequest(Section8.3).AnHTTPrequestthatomits
mandatorypseudoheaderfieldsismalformed(Section8.1.2.6).
HTTP/2doesnotdefineawaytocarrytheversionidentifierthatisincludedintheHTTP/1.1request
line.
8.1.2.4ResponsePseudoHeaderFields
ForHTTP/2responses,asingle:statuspseudoheaderfieldisdefinedthatcarriestheHTTPstatus
codefield(see[RFC7231],Section6).ThispseudoheaderfieldMUSTbeincludedinallresponses,
otherwisetheresponseismalformed(Section8.1.2.6).
HTTP/2doesnotdefineawaytocarrytheversionorreasonphrasethatisincludedinanHTTP/1.1
statusline.
8.1.2.5CompressingtheCookieHeaderField
TheCookieheaderfield[COOKIE]usesasemicolon(";")todelimitcookiepairs(or"crumbs").This
headerfielddoesn'tfollowthelistconstructionrulesinHTTP(see[RFC7230],Section3.2.2),which
preventscookiepairsfrombeingseparatedintodifferentnamevaluepairs.Thiscansignificantly
reducecompressionefficiencyasindividualcookiepairsareupdated.
40/65
11/02/2015
Toallowforbettercompressionefficiency,theCookieheaderfieldMAYbesplitintoseparateheader
fields,eachwithoneormorecookiepairs.IftherearemultipleCookieheaderfieldsafter
decompression,theseMUSTbeconcatenatedintoasingleoctetstringusingthetwooctetdelimiterof
0x3B,0x20(theASCIIstring";")beforebeingpassedintoanonHTTP/2context,suchasanHTTP/1.1
connection,oragenericHTTPserverapplication.
Therefore,thefollowingtwolistsofCookieheaderfieldsaresemanticallyequivalent.
cookie:a=b;c=d;e=f
cookie:a=b
cookie:c=d
cookie:e=f
8.1.2.6MalformedRequestsandResponses
AmalformedrequestorresponseisonethatisanotherwisevalidsequenceofHTTP/2frames,butis
otherwiseinvalidduetothepresenceofextraneousframes,prohibitedheaderfields,theabsenceof
mandatoryheaderfields,ortheinclusionofuppercaseheaderfieldnames.
Arequestorresponsethatincludesanpayloadbodycanincludeacontentlengthheaderfield.A
requestorresponseisalsomalformedifthevalueofacontentlengthheaderfielddoesnotequal
thesumoftheDATAframepayloadlengthsthatformthebody.Aresponsethatisdefinedtohaveno
payload,asdescribedin[RFC7230],Section3.3.2,canhaveanonzerocontentlengthheaderfield,
eventhoughnocontentisincludedinDATAframes.
IntermediariesthatprocessHTTPrequestsorresponses(i.e.,anyintermediarynotactingasatunnel)
MUSTNOTforwardamalformedrequestorresponse.Malformedrequestsorresponsesthatare
detectedMUSTbetreatedasastreamerror(Section5.4.2)oftypePROTOCOL_ERROR.
Formalformedrequests,aserverMAYsendanHTTPresponsepriortoclosingorresettingthestream.
ClientsMUSTNOTacceptamalformedresponse.Notethattheserequirementsareintendedtoprotect
againstseveraltypesofcommonattacksagainstHTTP;theyaredeliberatelystrict,becausebeing
permissivecanexposeimplementationstothesevulnerabilities.
8.1.3Examples
ThissectionshowsHTTP/1.1requestsandresponses,withillustrationsofequivalentHTTP/2
requestsandresponses.
AnHTTPGETrequestincludesrequestheaderfieldsandnopayloadbodyandisthereforetransmitted
asasingleHEADERSframe,followedbyzeroormoreCONTINUATIONframescontainingtheserialized
blockofrequestheaderfields.TheHEADERSframeinthefollowinghasboththeEND_HEADERSand
END_STREAMflagsset;noCONTINUATIONframesaresent:
GET/resourceHTTP/1.1HEADERS
Host:example.org==>+END_STREAM
Accept:image/jpeg+END_HEADERS
:method=GET
:scheme=https
:path=/resource
host=example.org
accept=image/jpeg
41/65
11/02/2015
Similarly,aresponsethatincludesonlyresponseheaderfieldsistransmittedasaHEADERSframe
(again,followedbyzeroormoreCONTINUATIONframes)containingtheserializedblockofresponse
headerfields.
HTTP/1.1304NotModifiedHEADERS
ETag:"xyzzy"==>+END_STREAM
Expires:Thu,23Jan...+END_HEADERS
:status=304
etag="xyzzy"
expires=Thu,23Jan...
AnHTTPPOSTrequestthatincludesrequestheaderfieldsandpayloaddataistransmittedasone
HEADERSframe,followedbyzeroormoreCONTINUATIONframescontainingtherequestheader
fields,followedbyoneormoreDATAframes,withthelastCONTINUATION(orHEADERS)frame
havingtheEND_HEADERSflagsetandthefinalDATAframehavingtheEND_STREAMflagset:
POST/resourceHTTP/1.1HEADERS
Host:example.org==>END_STREAM
ContentType:image/jpegEND_HEADERS
ContentLength:123:method=POST
:path=/resource
{binarydata}:scheme=https
CONTINUATION
+END_HEADERS
contenttype=image/jpeg
host=example.org
contentlength=123
DATA
+END_STREAM
{binarydata}
Notethatdatacontributingtoanygivenheaderfieldcouldbespreadbetweenheaderblockfragments.
Theallocationofheaderfieldstoframesinthisexampleisillustrativeonly.
AresponsethatincludesheaderfieldsandpayloaddataistransmittedasaHEADERSframe,followed
byzeroormoreCONTINUATIONframes,followedbyoneormoreDATAframes,withthelastDATA
frameinthesequencehavingtheEND_STREAMflagset:
HTTP/1.1200OKHEADERS
ContentType:image/jpeg==>END_STREAM
ContentLength:123+END_HEADERS
:status=200
{binarydata}contenttype=image/jpeg
contentlength=123
DATA
+END_STREAM
{binarydata}
Aninformationalresponseusinga1xxstatuscodeotherthan101istransmittedasaHEADERSframe,
followedbyzeroormoreCONTINUATIONframes.
Trailingheaderfieldsaresentasaheaderblockafterboththerequestorresponseheaderblockand
alltheDATAframeshavebeensent.TheHEADERSframestartingthetrailersheaderblockhasthe
42/65
11/02/2015
END_STREAMflagset.
Thefollowingexampleincludesbotha100(Continue)statuscode,whichissentinresponsetoa
requestcontaininga"100continue"tokenintheExpectheaderfield,andtrailingheaderfields:
HTTP/1.1100ContinueHEADERS
ExtensionField:bar==>END_STREAM
+END_HEADERS
:status=100
extensionfield=bar
HTTP/1.1200OKHEADERS
ContentType:image/jpeg==>END_STREAM
TransferEncoding:chunked+END_HEADERS
Trailer:Foo:status=200
contentlength=123
123contenttype=image/jpeg
{binarydata}trailer=Foo
0
Foo:barDATA
END_STREAM
{binarydata}
HEADERS
+END_STREAM
+END_HEADERS
foo=bar
8.1.4RequestReliabilityMechanismsinHTTP/2
InHTTP/1.1,anHTTPclientisunabletoretryanonidempotentrequestwhenanerroroccurs,
becausethereisnomeanstodeterminethenatureoftheerror.Itispossiblethatsomeserver
processingoccurredpriortotheerror,whichcouldresultinundesirableeffectsiftherequestwere
reattempted.
HTTP/2providestwomechanismsforprovidingaguaranteetoaclientthatarequesthasnotbeen
processed:
TheGOAWAYframeindicatesthehigheststreamnumberthatmighthavebeenprocessed.
Requestsonstreamswithhighernumbersarethereforeguaranteedtobesafetoretry.
TheREFUSED_STREAMerrorcodecanbeincludedinaRST_STREAMframetoindicatethatthe
streamisbeingclosedpriortoanyprocessinghavingoccurred.Anyrequestthatwassentonthe
resetstreamcanbesafelyretried.
Requeststhathavenotbeenprocessedhavenotfailed;clientsMAYautomaticallyretrythem,even
thosewithnonidempotentmethods.
AserverMUSTNOTindicatethatastreamhasnotbeenprocessedunlessitcanguaranteethatfact.If
framesthatareonastreamarepassedtotheapplicationlayerforanystream,thenREFUSED_STREAM
MUSTNOTbeusedforthatstream,andaGOAWAYframeMUSTincludeastreamidentifierthatis
greaterthanorequaltothegivenstreamidentifier.
Inadditiontothesemechanisms,thePINGframeprovidesawayforaclienttoeasilytestaconnection.
Connectionsthatremainidlecanbecomebrokenassomemiddleboxes(forinstance,networkaddress
translators,orloadbalancers)silentlydiscardconnectionbindings.ThePINGframeallowsaclientto
43/65
11/02/2015
safelytestwhetheraconnectionisstillactivewithoutsendingarequest.
8.2ServerPush
HTTP/2allowsaservertopreemptivelysend(or"push")responses(alongwithcorresponding
"promised"requests)toaclientinassociationwithapreviousclientinitiatedrequest.Thiscanbe
usefulwhentheserverknowstheclientwillneedtohavethoseresponsesavailableinordertofully
processtheresponsetotheoriginalrequest.
Aclientcanrequestthatserverpushbedisabled,thoughthisisnegotiatedforeachhopindependently.
TheSETTINGS_ENABLE_PUSHsettingcanbesetto0toindicatethatserverpushisdisabled.
PromisedrequestsMUSTbecacheable(see[RFC7231],Section4.2.3),MUSTbesafe(see[RFC7231],
Section4.2.1)andMUSTNOTincludearequestbody.Clientsthatreceiveapromisedrequestthatis
notcacheable,isnotknowntobesafeorthatindicatesthepresenceofarequestbodyMUSTresetthe
promisedstreamwithastreamerror(Section5.4.2)oftypePROTOCOL_ERROR.Notethiscouldresult
inthepromisedstreambeingresetiftheclientdoesnotrecognizeanewlydefinedmethodasbeing
safe.
Pushedresponsesthatarecacheable(see[RFC7234],Section3)canbestoredbytheclient,ifit
implementsanHTTPcache.Pushedresponsesareconsideredsuccessfullyvalidatedontheorigin
server(e.g.,ifthe"nocache"cacheresponsedirective[RFC7234],Section5.2.2ispresent)whilethe
streamidentifiedbythepromisedstreamIDisstillopen.
PushedresponsesthatarenotcacheableMUSTNOTbestoredbyanyHTTPcache.TheyMAYbemade
availabletotheapplicationseparately.
TheserverMUSTincludeavalueinthe:authorityheaderfieldforwhichtheserverisauthoritative
(seeSection10.1).AclientMUSTtreataPUSH_PROMISEforwhichtheserverisnotauthoritativeasa
streamerror(Section5.4.2)oftypePROTOCOL_ERROR.
Anintermediarycanreceivepushesfromtheserverandchoosenottoforwardthemontotheclient.
Inotherwords,howtomakeuseofthepushedinformationisuptothatintermediary.Equally,the
intermediarymightchoosetomakeadditionalpushestotheclient,withoutanyactiontakenbythe
server.
Aclientcannotpush.Thus,serversMUSTtreatthereceiptofaPUSH_PROMISEframeasaconnection
error(Section5.4.1)oftypePROTOCOL_ERROR.ClientsMUSTrejectanyattempttochangethe
SETTINGS_ENABLE_PUSHsettingtoavalueotherthan0bytreatingthemessageasaconnectionerror
8.2.1PushRequests
Serverpushissemanticallyequivalenttoaserverrespondingtoarequest;however,inthiscasethat
requestisalsosentbytheserver,asaPUSH_PROMISEframe.
ThePUSH_PROMISEframeincludesaheaderblockthatcontainsacompletesetofrequestheader
fieldsthattheserverattributestotherequest.Itisnotpossibletopusharesponsetoarequestthat
includesarequestbody.
Pushedresponsesarealwaysassociatedwithanexplicitrequestfromtheclient.ThePUSH_PROMISE
framessentbytheserveraresentonthatexplicitrequest'sstream.ThePUSH_PROMISEframealso
includesapromisedstreamidentifier,chosenfromthestreamidentifiersavailabletotheserver(see
Section5.1.1).
44/65
11/02/2015
TheheaderfieldsinPUSH_PROMISEandanysubsequentCONTINUATIONframesMUSTbeavalidand
completesetofrequestheaderfields(Section8.1.2.3).TheserverMUSTincludeamethodinthe
:methodheaderfieldthatissafeandcacheable.IfaclientreceivesaPUSH_PROMISEthatdoesnot
includeacompleteandvalidsetofheaderfields,orthe:methodheaderfieldidentifiesamethodthat
isnotsafe,itMUSTrespondwithastreamerror(Section5.4.2)oftypePROTOCOL_ERROR.
TheserverSHOULDsendPUSH_PROMISE(Section6.6)framespriortosendinganyframesthat
referencethepromisedresponses.Thisavoidsaracewhereclientsissuerequestspriortoreceiving
anyPUSH_PROMISEframes.
Forexample,iftheserverreceivesarequestforadocumentcontainingembeddedlinkstomultiple
imagefiles,andtheserverchoosestopushthoseadditionalimagestotheclient,sendingpush
promisesbeforetheDATAframesthatcontaintheimagelinksensuresthattheclientisabletoseethe
promisesbeforediscoveringembeddedlinks.Similarly,iftheserverpushesresponsesreferencedby
theheaderblock(forinstance,inLinkheaderfields),sendingthepushpromisesbeforesendingthe
headerblockensuresthatclientsdonotrequestthem.
PUSH_PROMISEframesMUSTNOTbesentbytheclient.
PUSH_PROMISEframescanbesentbytheserverinresponsetoanyclientinitiatedstream,butthe
streamMUSTbeineitherthe"open"or"halfclosed(remote)"statewithrespecttotheserver.
PUSH_PROMISEframesareinterspersedwiththeframesthatcomprisearesponse,thoughtheycannot
beinterspersedwithHEADERSandCONTINUATIONframesthatcompriseasingleheaderblock.
SendingaPUSH_PROMISEframecreatesanewstreamandputsthestreamintothereserved(local)
statefortheserverandthereserved(remote)statefortheclient.
8.2.2PushResponses
AftersendingthePUSH_PROMISEframe,theservercanbegindeliveringthepushedresponseasa
response(Section8.1.2.4)onaserverinitiatedstreamthatusesthepromisedstreamidentifier.The
serverusesthisstreamtotransmitanHTTPresponse,usingthesamesequenceofframesasdefinedin
Section8.1.Thisstreambecomes"halfclosed"totheclient(Section5.1)aftertheinitialHEADERS
frameissent.
OnceaclientreceivesaPUSH_PROMISEframeandchoosestoacceptthepushedresponse,theclient
SHOULDNOTissueanyrequestsforthepromisedresponseuntilafterthepromisedstreamhasclosed.
Iftheclientdetermines,foranyreason,thatitdoesnotwishtoreceivethepushedresponsefromthe
server,oriftheservertakestoolongtobeginsendingthepromisedresponse,theclientcansendan
RST_STREAMframe,usingeithertheCANCELorREFUSED_STREAMcodes,andreferencingthepushed
stream'sidentifier.
AclientcanusetheSETTINGS_MAX_CONCURRENT_STREAMSsettingtolimitthenumberofresponses
thatcanbeconcurrentlypushedbyaserver.AdvertisingaSETTINGS_MAX_CONCURRENT_STREAMS
valueofzerodisablesserverpushbypreventingtheserverfromcreatingthenecessarystreams.This
doesnotprohibitaserverfromsendingPUSH_PROMISEframes;clientsneedtoresetanypromised
streamsthatarenotwanted.
ClientsreceivingapushedresponseMUSTvalidatethateithertheserverisauthoritative(see
Section10.1),ortheproxythatprovidedthepushedresponseisconfiguredforthecorresponding
request.Forexample,aserverthatoffersacertificateforonlytheexample.comDNSIDorCommon
Nameisnotpermittedtopusharesponseforhttps://www.example.org/doc.
45/65
11/02/2015
TheresponseforaPUSH_PROMISEstreambeginswithaHEADERSframe,whichimmediatelyputsthe
streamintothehalfclosed(remote)statefortheserverandhalfclosed(local)statefortheclient,
andendswithaframebearingEND_STREAM,whichplacesthestreaminthe"closed"state.
Note: TheclientneversendsaframewiththeEND_STREAMflagforaserverpush.
8.3TheCONNECTMethod
InHTTP/1.x,thepseudomethodCONNECT([RFC7231],Section4.3.6)isusedtoconvertanHTTP
connectionintoatunneltoaremotehost.CONNECTisprimarilyusedwithHTTPproxiestoestablisha
TLSsessionwithanoriginserverforthepurposesofinteractingwithhttpsresources.
InHTTP/2,theCONNECTmethodisusedtoestablishatunneloverasingleHTTP/2streamtoa
remotehost,forsimilarpurposes.TheHTTPheaderfieldmappingworksasdefinedinRequestHeader
Fields(Section8.1.2.3),withafewdifferences.Specifically:
The:methodheaderfieldissettoCONNECT.
The:schemeand:pathheaderfieldsMUSTbeomitted.
The:authorityheaderfieldcontainsthehostandporttoconnectto(equivalenttothe
authorityformoftherequesttargetofCONNECTrequests,see[RFC7230],Section5.3).
ACONNECTrequestthatdoesnotconformtotheserestrictionsismalformed(Section8.1.2.6).
AproxythatsupportsCONNECTestablishesaTCPconnection[TCP]totheserveridentifiedinthe
:authorityheaderfield.Oncethisconnectionissuccessfullyestablished,theproxysendsaHEADERS
framecontaininga2xxseriesstatuscodetotheclient,asdefinedin[RFC7231],Section4.3.6.
AftertheinitialHEADERSframesentbyeachpeer,allsubsequentDATAframescorrespondtodata
sentontheTCPconnection.ThepayloadofanyDATAframessentbytheclientistransmittedbythe
proxytotheTCPserver;datareceivedfromtheTCPserverisassembledintoDATAframesbythe
proxy.FrametypesotherthanDATAorstreammanagementframes(RST_STREAM,
WINDOW_UPDATE,andPRIORITY)MUSTNOTbesentonaconnectedstream,andMUSTbetreatedas
astreamerror(Section5.4.2)ifreceived.
TheTCPconnectioncanbeclosedbyeitherpeer.TheEND_STREAMflagonaDATAframeistreatedas
beingequivalenttotheTCPFINbit.AclientisexpectedtosendaDATAframewiththeEND_STREAM
flagsetafterreceivingaframebearingtheEND_STREAMflag.AproxythatreceivesaDATAframewith
theEND_STREAMflagsetsendstheattacheddatawiththeFINbitsetonthelastTCPsegment.Aproxy
thatreceivesaTCPsegmentwiththeFINbitsetsendsaDATAframewiththeEND_STREAMflagset.
NotethatthefinalTCPsegmentorDATAframecouldbeempty.
ATCPconnectionerrorissignaledwithRST_STREAM.AproxytreatsanyerrorintheTCPconnection,
whichincludesreceivingaTCPsegmentwiththeRSTbitset,asastreamerror(Section5.4.2)oftype
CONNECT_ERROR.Correspondingly,aproxyMUSTsendaTCPsegmentwiththeRSTbitsetifit
detectsanerrorwiththestreamortheHTTP/2connection.
9.AdditionalHTTPRequirements/Considerations
ThissectionoutlinesattributesoftheHTTPprotocolthatimproveinteroperability,reduceexposureto
knownsecurityvulnerabilities,orreducethepotentialforimplementationvariation.
9.1ConnectionManagement
HTTP/2connectionsarepersistent.Forbestperformance,itisexpectedclientswillnotclose
46/65
11/02/2015
connectionsuntilitisdeterminedthatnofurthercommunicationwithaserverisnecessary(for
example,whenausernavigatesawayfromaparticularwebpage),oruntiltheserverclosesthe
connection.
ClientsSHOULDNOTopenmorethanoneHTTP/2connectiontoagivenhostandportpair,wherehost
isderivedfromaURI,aselectedalternativeservice[ALTSVC],oraconfiguredproxy.
Aclientcancreateadditionalconnectionsasreplacements,eithertoreplaceconnectionsthatarenear
toexhaustingtheavailablestreamidentifierspace(Section5.1.1),torefreshthekeyingmaterialfora
TLSconnection,ortoreplaceconnectionsthathaveencounterederrors(Section5.4.1).
AclientMAYopenmultipleconnectionstothesameIPaddressandTCPportusingdifferentServer
NameIndication[TLSEXT]valuesortoprovidedifferentTLSclientcertificates,butSHOULDavoid
creatingmultipleconnectionswiththesameconfiguration.
Serversareencouragedtomaintainopenconnectionsforaslongaspossible,butarepermittedto
terminateidleconnectionsifnecessary.WheneitherendpointchoosestoclosethetransportlayerTCP
connection,theterminatingendpointSHOULDfirstsendaGOAWAY(Section6.8)framesothatboth
endpointscanreliablydeterminewhetherpreviouslysentframeshavebeenprocessedandgracefully
completeorterminateanynecessaryremainingtasks.
9.1.1ConnectionReuse
Connectionsthataremadetoanoriginserver,eitherdirectlyorthroughatunnelcreatedusingthe
CONNECTmethod(Section8.3)MAYbereusedforrequestswithmultipledifferentURIauthority
components.Aconnectioncanbereusedaslongastheoriginserverisauthoritative(Section10.1).For
TCPconnectionswithoutTLS,thisdependsonthehosthavingresolvedtothesameIPaddress.
Forhttpsresources,connectionreuseadditionallydependsonhavingacertificatethatisvalidforthe
hostintheURI.ThecertificatepresentedbytheserverMUSTsatisfyanychecksthattheclientwould
performwhenforminganewTLSconnectionforthehostintheURI.
AnoriginservermightofferacertificatewithmultiplesubjectAltNameattributes,ornameswith
wildcards,oneofwhichisvalidfortheauthorityintheURI.Forexample,acertificatewitha
subjectAltNameof*.example.commightpermittheuseofthesameconnectionforrequeststo
URIsstartingwithhttps://a.example.com/andhttps://b.example.com/.
Insomedeployments,reusingaconnectionformultipleoriginscanresultinrequestsbeingdirectedto
thewrongoriginserver.Forexample,TLSterminationmightbeperformedbyamiddleboxthatuses
theTLSServerNameIndication(SNI)[TLSEXT]extensiontoselectanoriginserver.Thismeansthatit
ispossibleforclientstosendconfidentialinformationtoserversthatmightnotbetheintendedtarget
fortherequest,eventhoughtheserverisotherwiseauthoritative.
Aserverthatdoesnotwishclientstoreuseconnectionscanindicatethatitisnotauthoritativefora
requestbysendinga421(MisdirectedRequest)statuscodeinresponsetotherequest(see
Section9.1.2).
AclientthatisconfiguredtouseaproxyoverHTTP/2directsrequeststothatproxythroughasingle
connection.Thatis,allrequestssentviaaproxyreusetheconnectiontotheproxy.
9.1.2The421(MisdirectedRequest)StatusCode
The421(MisdirectedRequest)statuscodeindicatesthattherequestwasdirectedataserverthatis
notabletoproducearesponse.Thiscanbesentbyaserverthatisnotconfiguredtoproduce
47/65
11/02/2015
responsesforthecombinationofschemeandauthoritythatareincludedintherequestURI.
Clientsreceivinga421(MisdirectedRequest)responsefromaserverMAYretrytherequestwhether
therequestmethodisidempotentornotoveradifferentconnection.Thisispossibleifaconnection
isreused(Section9.1.1)orifanalternativeserviceisselected([ALTSVC]).
ThisstatuscodeMUSTNOTbegeneratedbyproxies.
A421responseiscacheablebydefault;i.e.,unlessotherwiseindicatedbythemethoddefinitionor
explicitcachecontrols(seeSection4.2.2of[RFC7234]).
9.2UseofTLSFeatures
ImplementationsofHTTP/2MUSTuseTLS[TLS12]version1.2orhigherforHTTP/2overTLS.The
generalTLSusageguidancein[TLSBCP]SHOULDbefollowed,withsomeadditionalrestrictionsthat
arespecifictoHTTP/2.
TheTLSimplementationMUSTsupporttheServerNameIndication(SNI)[TLSEXT]extensiontoTLS.
HTTP/2clientsMUSTindicatethetargetdomainnamewhennegotiatingTLS.
DeploymentsofHTTP/2thatnegotiateTLS1.3orhigherneedonlysupportandusetheSNIextension;
deploymentsofTLS1.2aresubjecttotherequirementsinthefollowingsections.Implementationsare
encouragedtoprovidedefaultsthatcomply,butitisrecognizedthatdeploymentsareultimately
responsibleforcompliance.
9.2.1TLS1.2Features
ThissectiondescribesrestrictionsontheTLS1.2featuresetthatcanbeusedwithHTTP/2.Dueto
deploymentlimitations,itmightnotbepossibletofailTLSnegotiationwhentheserestrictionsarenot
met.AnendpointMAYimmediatelyterminateanHTTP/2connectionthatdoesnotmeettheseTLS
requirementswithaconnectionerror(Section5.4.1)oftypeINADEQUATE_SECURITY.
AdeploymentofHTTP/2overTLS1.2MUSTdisablecompression.TLScompressioncanleadtothe
exposureofinformationthatwouldnototherwiseberevealed[RFC3749].Genericcompressionis
unnecessarysinceHTTP/2providescompressionfeaturesthataremoreawareofcontextand
thereforelikelytobemoreappropriateforuseforperformance,securityorotherreasons.
AdeploymentofHTTP/2overTLS1.2MUSTdisablerenegotiation.AnendpointMUSTtreataTLS
renegotiationasaconnectionerror(Section5.4.1)oftypePROTOCOL_ERROR.Notethatdisabling
renegotiationcanresultinlonglivedconnectionsbecomingunusableduetolimitsonthenumberof
messagestheunderlyingciphersuitecanencipher.
AnendpointMAYuserenegotiationtoprovideconfidentialityprotectionforclientcredentialsoffered
inthehandshake,butanyrenegotiationMUSToccurpriortosendingtheconnectionpreface.Aserver
SHOULDrequestaclientcertificateifitseesarenegotiationrequestimmediatelyafterestablishinga
connection.
Thiseffectivelypreventstheuseofrenegotiationinresponsetoarequestforaspecificprotected
resource.Afuturespecificationmightprovideawaytosupportthisusecase.Alternatively,aserver
mightuseanerror(Section5.4)oftypeHTTP_1_1_REQUIREDtorequesttheclientuseaprotocol
whichsupportsrenegotiation.
ImplementationsMUSTsupportephemeralkeyexchangesizesofatleast2048bitsforciphersuites
thatuseephemeralfinitefieldDiffieHellman(DHE)[TLS12]and224bitsforciphersuitesthatuse
48/65
11/02/2015
ephemeralellipticcurveDiffieHellman(ECDHE)[RFC4492].ClientsMUSTacceptDHEsizesofupto
4096bits.EndpointsMAYtreatnegotiationofkeysizessmallerthanthelowerlimitsasaconnection
error(Section5.4.1)oftypeINADEQUATE_SECURITY.
9.2.2TLS1.2CipherSuites
AdeploymentofHTTP/2overTLS1.2SHOULDNOTuseanyoftheciphersuitesthatarelistedinthe
ciphersuiteblacklist(AppendixA).
EndpointsMAYchoosetogenerateaconnectionerror(Section5.4.1)oftypeINADEQUATE_SECURITY
ifoneoftheciphersuitesfromtheblacklistarenegotiated.Adeploymentthatchoosestouseablack
listedciphersuiteriskstriggeringaconnectionerrorunlessthesetofpotentialpeersisknownto
acceptthatciphersuite.
ImplementationsMUSTNOTgeneratethiserrorinreactiontothenegotiationofaciphersuitethatis
notontheblacklist.Consequently,whenclientsofferaciphersuitethatisnotontheblacklist,they
havetobepreparedtousethatciphersuitewithHTTP/2.
TheblacklistincludestheciphersuitethatTLS1.2makesmandatory,whichmeansthatTLS1.2
deploymentscouldhavenonintersectingsetsofpermittedciphersuites.Toavoidthisproblem
causingTLShandshakefailures,deploymentsofHTTP/2thatuseTLS1.2MUSTsupport
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256[TLSECDHE]withtheP256ellipticcurve[FIPS186].
Notethatclientsmightadvertisesupportofciphersuitesthatareontheblacklistinordertoallowfor
connectiontoserversthatdonotsupportHTTP/2.ThisallowsserverstoselectHTTP/1.1witha
ciphersuitethatisontheHTTP/2blacklist.However,thiscanresultinHTTP/2beingnegotiatedwith
ablacklistedciphersuiteiftheapplicationprotocolandciphersuiteareindependentlyselected.
10.SecurityConsiderations
10.1ServerAuthority
HTTP/2reliesontheHTTP/1.1definitionofauthorityfordeterminingwhetheraserveris
authoritativeinprovidingagivenresponse,see[RFC7230],Section9.1.Thisreliesonlocalname
resolutionforthe"http"URIscheme,andtheauthenticatedserveridentityforthe"https"scheme(see
[RFC2818],Section3).
10.2CrossProtocolAttacks
Inacrossprotocolattack,anattackercausesaclienttoinitiateatransactioninoneprotocoltowarda
serverthatunderstandsadifferentprotocol.Anattackermightbeabletocausethetransactionto
appearasvalidtransactioninthesecondprotocol.Incombinationwiththecapabilitiesoftheweb
context,thiscanbeusedtointeractwithpoorlyprotectedserversinprivatenetworks.
CompletingaTLShandshakewithanALPNidentifierforHTTP/2canbeconsideredsufficient
protectionagainstcrossprotocolattacks.ALPNprovidesapositiveindicationthataserveriswillingto
proceedwithHTTP/2,whichpreventsattacksonotherTLSbasedprotocols.
TheencryptioninTLSmakesitdifficultforattackerstocontrolthedatawhichcouldbeusedina
crossprotocolattackonacleartextprotocol.
ThecleartextversionofHTTP/2hasminimalprotectionagainstcrossprotocolattacks.Theconnection
preface(Section3.5)containsastringthatisdesignedtoconfuseHTTP/1.1servers,butnospecial
protectionisofferedforotherprotocols.AserverthatiswillingtoignorepartsofanHTTP/1.1request
49/65
11/02/2015
containinganUpgradeheaderfieldinadditiontotheclientconnectionprefacecouldbeexposedtoa
crossprotocolattack.
10.3IntermediaryEncapsulationAttacks
TheHTTP/2headerfieldencodingallowstheexpressionofnamesthatarenotvalidfieldnamesinthe
InternetMessageSyntaxusedbyHTTP/1.1.Requestsorresponsescontaininginvalidheaderfield
namesMUSTbetreatedasmalformed(Section8.1.2.6).Anintermediarythereforecannottranslatean
HTTP/2requestorresponsecontaininganinvalidfieldnameintoanHTTP/1.1message.
Similarly,HTTP/2allowsheaderfieldvaluesthatarenotvalid.Whilemostofthevaluesthatcanbe
encodedwillnotalterheaderfieldparsing,carriagereturn(CR,ASCII0xd),linefeed(LF,ASCII0xa),
andthezerocharacter(NUL,ASCII0x0)mightbeexploitedbyanattackeriftheyaretranslated
verbatim.Anyrequestorresponsethatcontainsacharacternotpermittedinaheaderfieldvalue
MUSTbetreatedasmalformed(Section8.1.2.6).Validcharactersaredefinedbythefieldcontent
ABNFruleinSection3.2of[RFC7230].
10.4CacheabilityofPushedResponses
Pushedresponsesdonothaveanexplicitrequestfromtheclient;therequestisprovidedbytheserver
inthePUSH_PROMISEframe.
Cachingresponsesthatarepushedispossiblebasedontheguidanceprovidedbytheoriginserverin
theCacheControlheaderfield.However,thiscancauseissuesifasingleserverhostsmorethanone
tenant.Forexample,aservermightoffermultipleuserseachasmallportionofitsURIspace.
Wheremultipletenantssharespaceonthesameserver,thatserverMUSTensurethattenantsarenot
abletopushrepresentationsofresourcesthattheydonothaveauthorityover.Failuretoenforcethis
wouldallowatenanttoprovidearepresentationthatwouldbeservedoutofcache,overridingthe
actualrepresentationthattheauthoritativetenantprovides.
Pushedresponsesforwhichanoriginserverisnotauthoritative(seeSection10.1)MUSTNOTbeused
orcached.
10.5DenialofServiceConsiderations
AnHTTP/2connectioncandemandagreatercommitmentofresourcestooperatethanaHTTP/1.1
connection.Theuseofheadercompressionandflowcontroldependonacommitmentofresourcesfor
storingagreateramountofstate.Settingsforthesefeaturesensurethatmemorycommitmentsfor
thesefeaturesarestrictlybounded.
ThenumberofPUSH_PROMISEframesisnotconstrainedinthesamefashion.Aclientthataccepts
serverpushSHOULDlimitthenumberofstreamsitallowstobeinthe"reserved(remote)"state.
Excessivenumberofserverpushstreamscanbetreatedasastreamerror(Section5.4.2)oftype
ENHANCE_YOUR_CALM.
Processingcapacitycannotbeguardedaseffectivelyasstatecapacity.
TheSETTINGSframecanbeabusedtocauseapeertoexpendadditionalprocessingtime.Thismight
bedonebypointlesslychangingSETTINGSparameters,settingmultipleundefinedparameters,or
changingthesamesettingmultipletimesinthesameframe.WINDOW_UPDATEorPRIORITYframes
canbeabusedtocauseanunnecessarywasteofresources.
Largenumbersofsmalloremptyframescanbeabusedtocauseapeertoexpendtimeprocessing
50/65
11/02/2015
frameheaders.Notehoweverthatsomeusesareentirelylegitimate,suchasthesendingofanempty
DATAorCONTINUATIONframeattheendofastream.
Headercompressionalsoofferssomeopportunitiestowasteprocessingresources;seeSection7of
[COMPRESSION]formoredetailsonpotentialabuses.
LimitsinSETTINGSparameterscannotbereducedinstantaneously,whichleavesanendpointexposed
tobehaviorfromapeerthatcouldexceedthenewlimits.Inparticular,immediatelyafterestablishinga
connection,limitssetbyaserverarenotknowntoclientsandcouldbeexceededwithoutbeingan
obviousprotocolviolation.
Allthesefeaturesi.e.,SETTINGSchanges,smallframes,headercompressionhavelegitimateuses.
Thesefeaturesbecomeaburdenonlywhentheyareusedunnecessarilyortoexcess.
Anendpointthatdoesn'tmonitorthisbehaviorexposesitselftoariskofdenialofserviceattack.
ImplementationsSHOULDtracktheuseofthesefeaturesandsetlimitsontheiruse.AnendpointMAY
treatactivitythatissuspiciousasaconnectionerror(Section5.4.1)oftypeENHANCE_YOUR_CALM.
10.5.1LimitsonHeaderBlockSize
Alargeheaderblock(Section4.3)cancauseanimplementationtocommitalargeamountofstate.
Headerfieldsthatarecriticalforroutingcanappeartowardtheendofaheaderblock,whichprevents
streamingofheaderfieldstotheirultimatedestination.Thisorderingandotherreasons,suchas
ensuringcachecorrectness,meansthatanendpointmightneedtobuffertheentireheaderblock.Since
thereisnohardlimittothesizeofaheaderblock,someendpointscouldbeforcedtocommitalarge
amountofavailablememoryforheaderfields.
AnendpointcanusetheSETTINGS_MAX_HEADER_LIST_SIZEtoadvisepeersoflimitsthatmightapply
onthesizeofheaderblocks.Thissettingisonlyadvisory,soendpointsMAYchoosetosendheader
blocksthatexceedthislimitandriskhavingtherequestorresponsebeingtreatedasmalformed.This
settingisspecifictoaconnection,soanyrequestorresponsecouldencounterahopwithalower,
unknownlimit.Anintermediarycanattempttoavoidthisproblembypassingonvaluespresentedby
differentpeers,buttheyarenotobligatedtodoso.
AserverthatreceivesalargerheaderblockthanitiswillingtohandlecansendanHTTP431(Request
HeaderFieldsTooLarge)statuscode[RFC6585].Aclientcandiscardresponsesthatitcannotprocess.
TheheaderblockMUSTbeprocessedtoensureaconsistentconnectionstate,unlesstheconnectionis
closed.
10.5.2CONNECTIssues
TheCONNECTmethodcanbeusedtocreatedisproportionateloadonanproxy,sincestreamcreation
isrelativelyinexpensivewhencomparedtothecreationandmaintenanceofaTCPconnection.Aproxy
mightalsomaintainsomeresourcesforaTCPconnectionbeyondtheclosingofthestreamthatcarries
theCONNECTrequest,sincetheoutgoingTCPconnectionremainsintheTIME_WAITstate.Aproxy
thereforecannotrelyonSETTINGS_MAX_CONCURRENT_STREAMSalonetolimittheresources
consumedbyCONNECTrequests.
10.6UseofCompression
Compressioncanallowanattackertorecoversecretdatawhenitiscompressedinthesamecontextas
dataunderattackercontrol.HTTP/2enablescompressionofheaderfields(Section4.3);thefollowing
concernsalsoapplytotheuseofHTTPcompressedcontentcodings([RFC7231],Section3.1.2.1).
51/65
11/02/2015
Therearedemonstrableattacksoncompressionthatexploitthecharacteristicsoftheweb(e.g.,
[BREACH]).Theattackerinducesmultiplerequestscontainingvaryingplaintext,observingthelength
oftheresultingciphertextineach,whichrevealsashorterlengthwhenaguessaboutthesecretis
correct.
ImplementationscommunicatingonasecurechannelMUSTNOTcompresscontentthatincludesboth
confidentialandattackercontrolleddataunlessseparatecompressiondictionariesareusedforeach
sourceofdata.CompressionMUSTNOTbeusedifthesourceofdatacannotbereliablydetermined.
Genericstreamcompression,suchasthatprovidedbyTLSMUSTNOTbeusedwithHTTP/2(see
Section9.2).
Furtherconsiderationsregardingthecompressionofheaderfieldsaredescribedin[COMPRESSION].
10.7UseofPadding
PaddingwithinHTTP/2isnotintendedasareplacementforgeneralpurposepadding,suchasmight
beprovidedbyTLS[TLS12].Redundantpaddingcouldevenbecounterproductive.Correctapplication
candependonhavingspecificknowledgeofthedatathatisbeingpadded.
Tomitigateattacksthatrelyoncompression,disablingorlimitingcompressionmightbepreferableto
paddingasacountermeasure.
Paddingcanbeusedtoobscuretheexactsizeofframecontent,andisprovidedtomitigatespecific
attackswithinHTTP.Forexample,attackswherecompressedcontentincludesbothattacker
controlledplaintextandsecretdata(seeforexample,[BREACH]).
Useofpaddingcanresultinlessprotectionthanmightseemimmediatelyobvious.Atbest,padding
onlymakesitmoredifficultforanattackertoinferlengthinformationbyincreasingthenumberof
framesanattackerhastoobserve.Incorrectlyimplementedpaddingschemescanbeeasilydefeated.In
particular,randomizedpaddingwithapredictabledistributionprovidesverylittleprotection;
similarly,paddingpayloadstoafixedsizeexposesinformationaspayloadsizescrossthefixedsize
boundary,whichcouldbepossibleifanattackercancontrolplaintext.
IntermediariesSHOULDretainpaddingforDATAframes,butMAYdroppaddingforHEADERSand
PUSH_PROMISEframes.Avalidreasonforanintermediarytochangetheamountofpaddingofframes
istoimprovetheprotectionsthatpaddingprovides.
10.8PrivacyConsiderations
SeveralcharacteristicsofHTTP/2provideanobserveranopportunitytocorrelateactionsofasingle
clientorserverovertime.Thisincludesthevalueofsettings,themannerinwhichflowcontrol
windowsaremanaged,thewayprioritiesareallocatedtostreams,timingofreactionstostimulus,and
handlingofanyfeaturesthatarecontrolledbysettings.
Asfarasthiscreatesobservabledifferencesinbehavior,theycouldbeusedasabasisfor
fingerprintingaspecificclient,asdefinedinSection1.8of[HTML5].
HTTP/2'spreferenceforusingasingleTCPconnectionallowscorrelationofauser'sactivityonasite.
Ifconnectionsarereusedfordifferentorigins,thisallowstrackingacrossthoseorigins.
BecausethePINGandSETTINGSframessolicitimmediateresponses,theycanbeusedbyanendpoint
tomeasurelatencytotheirpeer.Thismighthaveprivacyimplicationsincertainscenarios.
11.IANAConsiderations
52/65
11/02/2015
AstringforidentifyingHTTP/2isenteredintothe"ApplicationLayerProtocolNegotiation(ALPN)
ProtocolIDs"registryestablishedin[TLSALPN].
Thisdocumentestablishesaregistryforframetypes,settings,anderrorcodes.Thesenewregistries
areenteredintoanew"HypertextTransferProtocol(HTTP)2Parameters"section.
ThisdocumentregisterstheHTTP2SettingsheaderfieldforuseinHTTP;andthe421(Misdirected
Request)statuscode.
ThisdocumentregistersthePRImethodforuseinHTTP,toavoidcollisionswiththeconnection
preface(Section3.5).
11.1RegistrationofHTTP/2IdentificationStrings
ThisdocumentcreatestworegistrationsfortheidentificationofHTTP/2inthe"ApplicationLayer
ProtocolNegotiation(ALPN)ProtocolIDs"registryestablishedin[TLSALPN].
The"h2"stringidentifiesHTTP/2whenusedoverTLS:
Protocol: HTTP/2overTLS
IdentificationSequence: 0x680x32("h2")
Specification: Thisdocument
The"h2c"stringidentifiesHTTP/2whenusedovercleartextTCP:
Protocol: HTTP/2overTCP
IdentificationSequence: 0x680x320x63("h2c")
Specification: Thisdocument
11.2FrameTypeRegistry
ThisdocumentestablishesaregistryforHTTP/2frametypecodes.The"HTTP/2FrameType"registry
managesan8bitspace.The"HTTP/2FrameType"registryoperatesundereitherofthe"IETF
Review"or"IESGApproval"policies[RFC5226]forvaluesbetween0x00and0xef,withvalues
between0xf0and0xffbeingreservedforexperimentaluse.
Newentriesinthisregistryrequirethefollowinginformation:
FrameType: Anameorlabelfortheframetype.
Code: The8bitcodeassignedtotheframetype.
Specification: Areferencetoaspecificationthatincludesadescriptionoftheframelayout,its
semantics,andflagsthattheframetypeuses,includinganypartsoftheframethatare
conditionallypresentbasedonthevalueofflags.
Theentriesinthefollowingtableareregisteredbythisdocument.
FrameType
Code Section
DATA
0x0
Section6.1
HEADERS
0x1
Section6.2
PRIORITY
0x2
Section6.3
53/65
11/02/2015
RST_STREAM
0x3
Section6.4
SETTINGS
0x4
Section6.5
PUSH_PROMISE
0x5
Section6.6
PING
0x6
Section6.7
GOAWAY
0x7
Section6.8
WINDOW_UPDATE 0x8
Section6.9
CONTINUATION
Section6.10
0x9
11.3SettingsRegistry
ThisdocumentestablishesaregistryforHTTP/2settings.The"HTTP/2Settings"registrymanagesa
16bitspace.The"HTTP/2Settings"registryoperatesunderthe"ExpertReview"policy[RFC5226]for
valuesintherangefrom0x0000to0xefff,withvaluesbetweenand0xf000and0xffffbeingreserved
forexperimentaluse.
Newregistrationsareadvisedtoprovidethefollowinginformation:
Name: Asymbolicnameforthesetting.Specifyingasettingnameisoptional.
Code: The16bitcodeassignedtothesetting.
InitialValue: Aninitialvalueforthesetting.
Specification: Anoptionalreferencetoaspecificationthatdescribestheuseofthesetting.
AninitialsetofsettingregistrationscanbefoundinSection6.5.2.
Name
Code InitialValue Specification
HEADER_TABLE_SIZE
0x1
4096
Section6.5.2
ENABLE_PUSH
0x2
Section6.5.2
MAX_CONCURRENT_STREAMS 0x3
(infinite)
Section6.5.2
INITIAL_WINDOW_SIZE
0x4
65535
Section6.5.2
MAX_FRAME_SIZE
0x5
16384
Section6.5.2
MAX_HEADER_LIST_SIZE
0x6
(infinite)
Section6.5.2
11.4ErrorCodeRegistry
ThisdocumentestablishesaregistryforHTTP/2errorcodes.The"HTTP/2ErrorCode"registry
managesa32bitspace.The"HTTP/2ErrorCode"registryoperatesunderthe"ExpertReview"policy
[RFC5226].
Registrationsforerrorcodesarerequiredtoincludeadescriptionoftheerrorcode.Anexpert
reviewerisadvisedtoexaminenewregistrationsforpossibleduplicationwithexistingerrorcodes.
Useofexistingregistrationsistobeencouraged,butnotmandated.
Newregistrationsareadvisedtoprovidethefollowinginformation:
Name: Anamefortheerrorcode.Specifyinganerrorcodenameisoptional.
Code: The32biterrorcodevalue.
Description: Abriefdescriptionoftheerrorcodesemantics,longerifnodetailedspecificationis
54/65
11/02/2015
provided.
Specification: Anoptionalreferenceforaspecificationthatdefinestheerrorcode.
Theentriesinthefollowingtableareregisteredbythisdocument.
Name
Code Description
Specification
NO_ERROR
0x0
Gracefulshutdown
Section7
PROTOCOL_ERROR
0x1
Protocolerrordetected
Section7
INTERNAL_ERROR
0x2
Implementationfault
Section7
FLOW_CONTROL_ERROR 0x3
Flowcontrollimitsexceeded
Section7
SETTINGS_TIMEOUT
0x4
Settingsnotacknowledged
Section7
STREAM_CLOSED
0x5
Framereceivedforclosedstream
Section7
FRAME_SIZE_ERROR
0x6
Framesizeincorrect
Section7
REFUSED_STREAM
0x7
Streamnotprocessed
Section7
CANCEL
0x8
Streamcancelled
Section7
COMPRESSION_ERROR
0x9
Compressionstatenotupdated
Section7
CONNECT_ERROR
0xa
TCPconnectionerrorforCONNECTmethod Section7
ENHANCE_YOUR_CALM
0xb
Processingcapacityexceeded
Section7
INADEQUATE_SECURITY 0xc
NegotiatedTLSparametersnotacceptable
Section7
HTTP_1_1_REQUIRED
UseHTTP/1.1fortherequest
Section7
0xd
11.5HTTP2SettingsHeaderFieldRegistration
ThissectionregisterstheHTTP2SettingsheaderfieldinthePermanentMessageHeaderField
Registry[BCP90].
Headerfieldname: HTTP2Settings
Applicableprotocol: http
Status: standard
Author/Changecontroller: IETF
Specificationdocument(s): Section3.2.1ofthisdocument
Relatedinformation: ThisheaderfieldisonlyusedbyanHTTP/2clientforUpgradebased
negotiation.
11.6PRIMethodRegistration
ThissectionregistersthePRImethodintheHTTPMethodRegistry([RFC7231],Section8.1).
MethodName: PRI
Safe Yes
Idempotent Yes
Specificationdocument(s) Section3.5ofthisdocument
Relatedinformation: Thismethodisneverusedbyanactualclient.Thismethodwillappeartobeused
whenanHTTP/1.1serverorintermediaryattemptstoparseanHTTP/2connectionpreface.
55/65
11/02/2015
11.7The421(MisdirectedRequest)HTTPStatusCode
Thisdocumentregistersthe421(MisdirectedRequest)HTTPStatuscodeintheHypertextTransfer
Protocol(HTTP)StatusCodeRegistry([RFC7231],Section8.2).
StatusCode: 421
ShortDescription: MisdirectedRequest
Specification: Section9.1.2ofthisdocument
12.Acknowledgements
Thisdocumentincludessubstantialinputfromthefollowingindividuals:
AdamLangley,WanTehChang,JimMorrison,MarkNottingham,AlyssaWilk,CostinManolache,
WilliamChan,VitaliyLvin,JoeChan,AdamBarth,RyanHamilton,GavinPeters,KentAlstad,Kevin
Lindsay,PaulAmer,FanYang,JonathanLeighton(SPDYcontributors).
GabrielMontenegroandWillyTarreau(Upgrademechanism).
WilliamChan,SalvatoreLoreto,OsamaMazahir,GabrielMontenegro,JituPadhye,RobertoPeon,
RobTrace(Flowcontrol).
MikeBishop(Extensibility).
MarkNottingham,JulianReschke,JamesSnell,JeffPinner,MikeBishop,HerveRuellan
(Substantialeditorialcontributions).
KariHurtta,TatsuhiroTsujikawa,GregWilkins,PoulHenningKamp,JonathanThackray.
AlexeyMelnikovwasaneditorofthisdocumentduring2013.
AsubstantialproportionofMartin'scontributionwassupportedbyMicrosoftduringhis
employmentthere.
TheJapaneseHTTP/2communityprovidedaninvaluablecontribution,includinganumberof
implementations,plusnumeroustechnicalandeditorialcontributions.
13.References
13.1NormativeReferences
[COMPRESSION]
[COOKIE]
[FIPS186]
[RFC2119]
[RFC2818]
[RFC3986]
[RFC4648]
[RFC5226]
[RFC5234]
Ruellan,H.andR.Peon,HPACKHeaderCompressionforHTTP/2,Internet
Draftdraftietfhttpbisheadercompression11(workinprogress),
February2015.
Barth,A.,HTTPStateManagementMechanism,RFC6265,April2011.
NIST,DigitalSignatureStandard(DSS),FIPSPUB1864,July2013,
<http://dx.doi.org/10.6028/NIST.FIPS.1864>.
Bradner,S.,KeywordsforuseinRFCstoIndicateRequirementLevels,BCP14,
RFC2119,March1997.
Rescorla,E.,HTTPOverTLS,RFC2818,May2000.
BernersLee,T.,Fielding,R.,andL.Masinter,UniformResourceIdentifier(URI):
GenericSyntax,STD66,RFC3986,January2005.
Josefsson,S.,TheBase16,Base32,andBase64DataEncodings,RFC4648,
October2006.
Narten,T.andH.Alvestrand,GuidelinesforWritinganIANAConsiderations
SectioninRFCs,BCP26,RFC5226,May2008.
Crocker,D.andP.Overell,AugmentedBNFforSyntaxSpecifications:ABNF,
STD68,RFC5234,January2008.
56/65
11/02/2015
[RFC7230]
Fielding,R.,Ed.andJ.Reschke,Ed.,HypertextTransferProtocol(HTTP/1.1):
MessageSyntaxandRouting,RFC7230,June2014.
SemanticsandContent,RFC7231,June2014.
ConditionalRequests,RFC7232,June2014.
Fielding,R.,Ed.,Lafon,Y.,Ed.,andJ.Reschke,Ed.,HypertextTransferProtocol
(HTTP/1.1):RangeRequests,RFC7233,June2014.
Fielding,R.,Ed.,Nottingham,M.,Ed.,andJ.Reschke,Ed.,HypertextTransfer
Protocol(HTTP/1.1):Caching,RFC7234,June2014.
Authentication,RFC7235,June2014.
Postel,J.,TransmissionControlProtocol,STD7,RFC793,September1981.
Friedl,S.,Popov,A.,Langley,A.,andE.Stephan,TransportLayerSecurity(TLS)
ApplicationLayerProtocolNegotiationExtension,RFC7301,July2014.
Rescorla,E.,TLSEllipticCurveCipherSuiteswithSHA256/384andAESGalois
CounterMode(GCM),RFC5289,August2008.
Eastlake,D.,TransportLayerSecurity(TLS)Extensions:ExtensionDefinitions,
RFC6066,January2011.
Dierks,T.andE.Rescorla,TheTransportLayerSecurity(TLS)ProtocolVersion
1.2,RFC5246,August2008.
[RFC7231]
[RFC7232]
[RFC7233]
[RFC7234]
[RFC7235]
[TCP]
[TLSALPN]
[TLSECDHE]
[TLSEXT]
[TLS12]
13.2InformativeReferences
[ALTSVC]
[BCP90]
[BREACH]
[HTML5]
[RFC3749]
[RFC4492]
[RFC6585]
[RFC7323]
[TALKING]
[TLSBCP]
Nottingham,M.,McManus,P.,andJ.Reschke,HTTPAlternativeServices,Internet
Draftdraftietfhttpbisaltsvc06(workinprogress),February2015.
Klyne,G.,Nottingham,M.,andJ.Mogul,RegistrationProceduresforMessageHeader
Fields,BCP90,RFC3864,September2004.
Gluck,Y.,Harris,N.,andA.Prado,BREACH:RevivingtheCRIMEAttack,July2013,
<http://breachattack.com/resources/BREACH%20
%20SSL,%20gone%20in%2030%20seconds.pdf>.
Hickson,I.,Berjon,R.,Faulkner,S.,Leithead,T.,DoyleNavara,E.,O'Connor,E.,andS.
Pfeiffer,HTML5,W3CRecommendationREChtml520141028,October2014,
<http://www.w3.org/TR/2014/REChtml520141028/>.
Latestversionavailableat<http://www.w3.org/TR/html5/>.
Hollenbeck,S.,TransportLayerSecurityProtocolCompressionMethods,RFC3749,
May2004.
BlakeWilson,S.,Bolyard,N.,Gupta,V.,Hawk,C.,andB.Moeller,EllipticCurve
Cryptography(ECC)CipherSuitesforTransportLayerSecurity(TLS),RFC4492,
May2006.
Nottingham,M.andR.Fielding,AdditionalHTTPStatusCodes,RFC6585,April2012.
Borman,D.,Braden,B.,Jacobson,V.,andR.Scheffenegger,TCPExtensionsforHigh
Performance,RFC7323,September2014.
Huang,LS.,Chen,E.,Barth,A.,Rescorla,E.,andC.Jackson,TalkingtoYourselfforFun
andProfit,2011,<http://w2spconf.com/2011/papers/websocket.pdf>.
Sheffer,Y.,Holz,R.,andP.SaintAndre,RecommendationsforSecureUseofTLSand
DTLS,InternetDraftdraftietfutatlsbcp08(workinprogress),December2014.
57/65
11/02/2015
A.TLS1.2CipherSuiteBlackList
AnHTTP/2implementationMAYtreatthenegotiationofanyofthefollowingciphersuiteswithTLS
1.2asaconnectionerror(Section5.4.1)oftypeINADEQUATE_SECURITY:
TLS_NULL_WITH_NULL_NULL,TLS_RSA_WITH_NULL_MD5,TLS_RSA_WITH_NULL_SHA,
TLS_RSA_EXPORT_WITH_RC4_40_MD5,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5,TLS_RSA_WITH_IDEA_CBC_SHA,
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_DH_DSS_WITH_DES_CBC_SHA,TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_DH_RSA_WITH_DES_CBC_SHA,
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_DHE_DSS_WITH_DES_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_DHE_RSA_WITH_DES_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DH_anon_EXPORT_WITH_RC4_40_MD5,
TLS_DH_anon_WITH_RC4_128_MD5,TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_DH_anon_WITH_DES_CBC_SHA,TLS_DH_anon_WITH_3DES_EDE_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA,TLS_KRB5_WITH_3DES_EDE_CBC_SHA,
TLS_KRB5_WITH_RC4_128_SHA,TLS_KRB5_WITH_IDEA_CBC_SHA,TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_WITH_3DES_EDE_CBC_MD5,TLS_KRB5_WITH_RC4_128_MD5,
TLS_KRB5_WITH_IDEA_CBC_MD5,TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA,TLS_KRB5_EXPORT_WITH_RC4_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5,TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_MD5,TLS_PSK_WITH_NULL_SHA,TLS_DHE_PSK_WITH_NULL_SHA,
TLS_RSA_PSK_WITH_NULL_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_DSS_WITH_AES_128_CBC_SHA,TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_anon_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_DH_DSS_WITH_AES_256_CBC_SHA,TLS_DH_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DH_anon_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_DH_DSS_WITH_AES_128_CBC_SHA256,TLS_DH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA,TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DH_DSS_WITH_AES_256_CBC_SHA256,TLS_DH_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DH_anon_WITH_AES_128_CBC_SHA256,TLS_DH_anon_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA,TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA,
TLS_PSK_WITH_RC4_128_SHA,TLS_PSK_WITH_3DES_EDE_CBC_SHA,
TLS_PSK_WITH_AES_128_CBC_SHA,TLS_PSK_WITH_AES_256_CBC_SHA,
TLS_DHE_PSK_WITH_RC4_128_SHA,TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_PSK_WITH_AES_128_CBC_SHA,TLS_DHE_PSK_WITH_AES_256_CBC_SHA,
TLS_RSA_PSK_WITH_RC4_128_SHA,TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA,TLS_RSA_PSK_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_SEED_CBC_SHA,TLS_DH_DSS_WITH_SEED_CBC_SHA,
TLS_DH_RSA_WITH_SEED_CBC_SHA,TLS_DHE_DSS_WITH_SEED_CBC_SHA,
58/65
11/02/2015
TLS_DHE_RSA_WITH_SEED_CBC_SHA,TLS_DH_anon_WITH_SEED_CBC_SHA,
TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_DH_RSA_WITH_AES_128_GCM_SHA256,TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
TLS_DH_DSS_WITH_AES_128_GCM_SHA256,TLS_DH_DSS_WITH_AES_256_GCM_SHA384,
TLS_DH_anon_WITH_AES_128_GCM_SHA256,TLS_DH_anon_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_GCM_SHA256,TLS_PSK_WITH_AES_256_GCM_SHA384,
TLS_RSA_PSK_WITH_AES_128_GCM_SHA256,TLS_RSA_PSK_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_CBC_SHA256,TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_NULL_SHA256,TLS_PSK_WITH_NULL_SHA384,
TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
TLS_DHE_PSK_WITH_NULL_SHA256,TLS_DHE_PSK_WITH_NULL_SHA384,
TLS_RSA_PSK_WITH_AES_128_CBC_SHA256,TLS_RSA_PSK_WITH_AES_256_CBC_SHA384,
TLS_RSA_PSK_WITH_NULL_SHA256,TLS_RSA_PSK_WITH_NULL_SHA384,
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256,TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256,TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256,TLS_EMPTY_RENEGOTIATION_INFO_SCSV,
TLS_ECDH_ECDSA_WITH_NULL_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_NULL_SHA,
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_NULL_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_NULL_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_anon_WITH_NULL_SHA,TLS_ECDH_anon_WITH_RC4_128_SHA,
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
TLS_ECDH_anon_WITH_AES_256_CBC_SHA,TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA,
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA,TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_SRP_SHA_WITH_AES_128_CBC_SHA,TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA,TLS_SRP_SHA_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_PSK_WITH_RC4_128_SHA,TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256,TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_PSK_WITH_NULL_SHA,TLS_ECDHE_PSK_WITH_NULL_SHA256,
TLS_ECDHE_PSK_WITH_NULL_SHA384,TLS_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_RSA_WITH_ARIA_256_CBC_SHA384,TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256,
TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384,TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256,
59/65
11/02/2015
TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384,TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384,TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384,TLS_DH_anon_WITH_ARIA_128_CBC_SHA256,
TLS_DH_anon_WITH_ARIA_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384,TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384,TLS_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_RSA_WITH_ARIA_256_GCM_SHA384,TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384,TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256,
TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384,TLS_DH_anon_WITH_ARIA_128_GCM_SHA256,
TLS_DH_anon_WITH_ARIA_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384,TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384,TLS_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_PSK_WITH_ARIA_256_CBC_SHA384,TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384,TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384,TLS_PSK_WITH_ARIA_128_GCM_SHA256,
TLS_PSK_WITH_ARIA_256_GCM_SHA384,TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256,
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384,TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384,TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384,TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384,
TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384,TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256,
TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384,TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384,TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384,TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,TLS_RSA_WITH_AES_128_CCM,
TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM_8,TLS_RSA_WITH_AES_256_CCM_8,
TLS_PSK_WITH_AES_128_CCM,TLS_PSK_WITH_AES_256_CCM,TLS_PSK_WITH_AES_128_CCM_8,
TLS_PSK_WITH_AES_256_CCM_8.
Note: ThislistwasassembledfromthesetofregisteredTLSciphersuitesatthetimeofwriting.This
listincludesthoseciphersuitesthatdonotofferanephemeralkeyexchangeandthosethatare
60/65
11/02/2015
basedontheTLSnull,streamorblockciphertype(asdefinedinSection6.2.3of[TLS12]).
Additionalciphersuiteswiththesepropertiescouldbedefined;thesewouldnotbeexplicitly
prohibited.
B.ChangeLog
ThissectionistoberemovedbyRFCEditorbeforepublication.
EnabledthesendingofPRIORITYforanystreamstate.
AddedaciphersuiteblacklistandmadeseveralchangestotheTLSusagesection.
RenamedNotAuthoritativestatuscodetoMisdirectedRequest.
AddedHTTP_1_1_REQUIREDerrorcode.
Pseudoheaderfieldsarenowrequiredtoappearstrictlybeforeregularones.
Restored1xxseriesstatuscodes,except101.
Changedframelengthfield24bits.Expandedframeheaderto9octets.Addedasettingtolimitthe
damage.
Addedasettingtoadvisepeersofheadersetsizelimits.
Removedsegments.
MadenonsemanticbearingHEADERSframesillegalintheHTTPmapping.
Restoredextensibilityoptions.
RestrictingTLSciphersuitestoAEADonly.
RemovingContentEncodingrequirements.
PermittingtheuseofPRIORITYafterstreamclose.
RemovedALTSVCframe.
RemovedBLOCKEDframe.
Reducingthemaximumpaddingsizeto256octets;removingpaddingfromCONTINUATIONframes.
RemovedperframeGZIPcompression.
AddedBLOCKEDframe(atrisk).
61/65
11/02/2015
Simplifiedpriorityscheme.
AddedDATAperframeGZIPcompression.
Changed"connectionheader"to"connectionpreface"toavoidconfusion.
Addeddependencybasedstreamprioritization.
Added"h2c"identifiertodistinguishbetweencleartextandsecuredHTTP/2.
AddingmissingpaddingtoPUSH_PROMISE.
IntegrateALTSVCframeandsupportingtext.
Droppingrequirementon"deflate"ContentEncoding.
Improvingsecurityconsiderationsarounduseofcompression.
Addingpaddingfordataframes.
Renumberingframetypes,errorcodes,andsettings.
AddingINADEQUATE_SECURITYerrorcode.
UpdatingTLSusagerequirementsto1.2;forbiddingTLScompression.
Removingextensibilityforframesandsettings.
Changingsettingidentifiersize.
Removingtheabilitytodisableflowcontrol.
Changingtheprotocolidentificationtokento"h2".
Changingtheuseof:authoritytomakeitoptionalandtoallowuserinfoinnonHTTPcases.
Allowingspliton0x0forCookie.
ReservedPRImethodinHTTP/1.1toavoidpossiblefuturecollisions.
Addedcookiecrumblingformoreefficientheadercompression.
Addedheaderfieldorderingwiththevalueconcatenationmechanism.
Markeddraftforimplementation.
AddingdefinitionforCONNECTmethod.
62/65
11/02/2015
Constrainingtheuseofpushtosafe,cacheablemethodswithnorequestbody.
Changingfrom:hostto:authoritytoremoveanypotentialconfusion.
Addingsettingforheadercompressiontablesize.
Addingsettingsacknowledgement.
RemovingunnecessaryandpotentiallyproblematicflagsfromCONTINUATION.
Addeddenialofserviceconsiderations.
Markingthedraftreadyforimplementation.
RenumberingEND_PUSH_PROMISEflag.
Editorialclarificationsandchanges.
AddedCONTINUATIONframeforHEADERSandPUSH_PROMISE.
PUSH_PROMISEisnolongerimplicitlyprohibitedifSETTINGS_MAX_CONCURRENT_STREAMSiszero.
Pushexpandedtoallowallsafemethodswithoutarequestbody.
ClarifiedtheuseofHTTPheaderfieldsinrequestsandresponses.ProhibitedHTTP/1.1hopbyhop
headerfields.
Requiringthatintermediariesnotforwardrequestswithmissingorillegalrouting:headers.
Clarifiedrequirementsaroundhandlingdifferentframesafterstreamclose,streamresetand
GOAWAY.
Addedmorespecificprohibitionsforsendingofdifferentframetypesinvariousstreamstates.
Makingthelastreceivedsettingvaluetheeffectivevalue.
ClarifiedrequirementsonTLSversion,extensionandciphers.
Committedmajorrestructuringatrocities.
Addedreferencetofirstheadercompressiondraft.
Addedmoreformaldescriptionofframelifecycle.
MovedEND_STREAM(renamedfromFINAL)backtoHEADERS/DATA.
RemovedHEADERS+PRIORITY,addedoptionalprioritytoHEADERSframe.
AddedPRIORITYframe.
63/65
11/02/2015
Addedcontinuationstoframescarryingheaderblocks.
Replaceduseof"session"with"connection"toavoidconfusionwithotherHTTPstatefulconcepts,like
cookies.
Removed"message".
SwitchedtoTLSALPNfromNPN.
Editorialchanges.
AddedIANAconsiderationssectionforframetypes,errorcodesandsettings.
Removeddataframecompression.
AddedPUSH_PROMISE.
Addedgloballyapplicableflagstoframing.
Removedzlibbasedheadercompressionmechanism.
Updatedreferences.
Clarifiedstreamidentifierreuse.
RemovedCREDENTIALSframeandassociatedmechanisms.
Addedadviceagainstnaiveimplementationofflowcontrol.
Addedsessionheadersection.
Restructuredframeheader.Removeddistinctionbetweendataandcontrolframes.
Alteredflowcontrolpropertiestoincludesessionlevellimits.
Addednoteoncacheabilityofpushedresourcesandmultipletenantservers.
Changedprotocollabelformbasedondiscussions.
Changedtitlethroughout.
RemovedsectiononIncompatibilitieswithSPDYdraft#2.
ChangedINTERNAL_ERRORonGOAWAYtohaveavalueof2<https://groups.google.com/forum/?
fromgroups#!topic/spdydev/cfUef2gL3iU>.
Replacedabstractandintroduction.
AddedsectiononstartingHTTP/2.0,includingupgrademechanism.
Removedunusedreferences.
Addedflowcontrolprinciples(Section5.2.1)basedon<https://tools.ietf.org/html/draftmontenegro
64/65
11/02/2015
httpbishttp2fcprinciples01>.
B.17Sincedraftmbelshehttpbisspdy00
Adoptedasbasefordraftietfhttpbishttp2.
Updatedauthors/editorslist.
Addedstatusnote.
Authors'Addresses
MikeBelshe
Twist
Email:mbelshe@chromium.org
RobertoPeon
Google,Inc
Email:fenix@google.com
MartinThomson(editor)
Mozilla
331EEvelynStreet
MountainView,CA94041
US
Email:martin.thomson@gmail.com
65/65

HTTP 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HTTP 2

Transféré par

Droits d'auteur :

Formats disponibles

11/02/2015

Code InitialValue Specification

Vous aimerez peut-être aussi