Re: Alternative Header Compression Update..

On 11/07/2013 6:22 a.m., Mike Bishop wrote:
> One advantage of removing the reference set is that Gabor's streaming proposal can be taken even further -- HEADERS frames from different streams can be interleaved with other frame types, because the headers they add to a stream are emitted as the frame is processed and the header table is always in a consistent state.
>
> Whether this would be desirable or useful, however, seems unclear.  HEADERS frames must still be processed in order for compression views to be consistent, and for HTTP semantics must precede any DATA on the same stream.

IMHO this is both desirable and useful.

Consider a load balancer which receives multiple hundreds of streams 
near simultaneously from as many servers and needs to deliver those 
frames to the one client connection. Being able to encode and serialize 
the frames as they arrive regardless of order means the balancer is not 
required to hold anything in queues waiting for followup frames no 
matter how the server read() are interleaved.

The clause mandating that HEADERS #h1 and HEADERS #h2 of a 2-block 
headers (stream #s1) be sequentially serialized on the wire is just 
adding needless complexity. Any compressor state changes which HEADERS 
of a separate stream (#s2) will cause if inserted between those #h1 and 
#h2 will be changes that would occur anyway if it were scheduled last 
after #h2. We also gain the potential benefit where HEADERS #1 of each 
stream might share some detail (long "Cookie"? long ":path"?) which 
otherwise could be evicted by HEADERS #h2 on stream #s1 and thus saving 
even more bandwidth on stream #s2.

Amos

Received on Thursday, 11 July 2013 03:14:24 UTC