> This is what I favor, and it is at most 8 bytes of overhead (send an empty > HEADERS frame before whatever else) in non-HTTP cases where metadata about > the stream opening is not needed (nothing that I can think of would do this > today). > > You've convinced me -- having only one frame be able to open streams is very compelling. > >> Another option is a flag on the HEADERS frame similar to the continuation >> bit that says a PRIORITY frame is following and must be sent after the >> continued headers are received. >> > > This is basically what HEADERS+PRIORITY is, without the overhead of the > frame-header. > > So since we have frame specific flags now can we just use them and drop to duplicated frame type so that only one frame is used for stream creation? 1. remove frame 0x08 HEADERS as duplicated 2. rename frame 0x01 from HEADERS+PRIORITY to HEADERS and indicate that it is the only frame that may create a stream 3. add flag 0x02 PRIORITY to the HEADERS frame to indicate the first 4 bytes of the frame contain a priority field 4. add flag 0x04 CONTINUED to the HEADERS frame to indicate that the headers block is split across a second frame which must be the next frame sent on the wire 5. add a frame 0x02 PRIORITY that is 4 bytes long and must be sent only on open streams a slightly different shade of shed :)
Received on Sunday, 26 May 2013 14:32:13 UTC