|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
While testing firefox's implementation of this draft Vlad determined that some versions of Chrome throw PROTOCOL_ERROR and close the connection if it receives a type 0xB frame with a non zero length on stream 0. Other frame type numbers, such as 0xC do not seem to have that problem. testing indicates this is fixed in version 59 and is a problem previous to that. (57 is in release as I write this). presumably this is related to historical code around BLOCKED which was proposed to use 0xB. Prudence says to just use a different code point for the moment. we discussed this in the f2f in ORD so it shouldnt be a problem https://github.com/httpwg/http-extensions/pull/323
Comment on attachment 8856776 [details] Bug 1355277 - change h2 origin frame codepoint to 0xc https://reviewboard.mozilla.org/r/128702/#review131476 ::: netwerk/protocol/http/Http2Session.cpp:229 (Diff revision 1) > Http2Session::RecvPing, > Http2Session::RecvGoAway, > Http2Session::RecvWindowUpdate, > Http2Session::RecvContinuation, > Http2Session::RecvAltSvc, // extension for type 0x0A > - Http2Session::RecvOrigin // extension for type 0x0B > + Http2Session::RecvUnused, // 0x0B ignore for now nit: Note that this used to be BLOCKED, but that's gone now? ::: testing/xpcshell/node-http2/lib/protocol/framer.js:1072 (Diff revision 1) > } > // Otherwise, we just ignore this > } > }; > > -frameTypes[0xB] = 'ORIGIN'; > +// frame 0xB was BLOCKED and some versions of chrome will This is fine for here, but I'll probably need to do some work in the main repo to make this not choke in real-world situations. This is more a note to myself than anything for you to do here.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0f7d40d274fb change h2 origin frame codepoint to 0xc r=nwgh