Re: [hybi] With deflate-stream, Close frame doesn't work as an end of data marker

[John Tamplin <[e-mail]>]

[BTW - here is the thread where I first posted results of an
experiment - http://www.ietf.org/mail-archive/web/hybi/current/msg01810.html
]

On Mon, Feb 28, 2011 at 4:52 AM, Greg Wilkins <[e-mail]> wrote:
> I'm +1 for compression within the frame.
>
> If we compress the framing, then intermediaries will have to
> decompress in order to see framing and to know when to forward etc.
> It also has significant debug issues as it makes it much harder to
> decode a partial frame capture.
>
> I understand the argument that compression will not be as good, but I
> think some compromise is necessary.

The framing is pretty small and it is hard to imagine much redundancy
from the header (the opcode and reserved bits will be constant, but
then you will interfere with the compression by all the constantly
changing lengths), so I think little is lost by compressing only the
payload.

However, it does mean the implementation is more complicated, and I
don't believe this would be feasible using the stock inflate/deflate
in Java for example.  I would not agree to just compressing each
frame's payload independently -- my earlier experiments show this will
frequently increase the size of the data and result in only modest
savings compared to maintaining compression state over the life of the
connection (while we are discussing it, we should talk about the
parameters to use for deflate to minimize memory requirements on the
server -- experiments done for compression in SPDY [mentioned in the
linked thread] show you can get most of the benefit with more modest
memory requirements using lower parameters).

It also means we have to agree on the details of how it should be
specified, which is why the super-simple deflate-stream was added to
the standard instead of trying to get agreement on something better.

--
John A. Tamplin
Software Engineer (GWT), Google