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

I completely agree.  Extensions should have free reign over the payload, but not be allowed to change the framing at all.  In fact the framing layer itself could be imagined as the first and last stage in the middleware stack, for the receiver and sender, respectively.  

Once all the extensions have executed their transformations on the sending node, then and only then is the framing generated from the state of the internal data structures that describe the current frame.

And since we're already not supporting things like "sendfile" and arbitrarily long messages of unknown length can be fragmented, this works quite cleanly and simply.

Brian

Sent from my iPhone

On Feb 28 2011, at 12:40 PM, Greg Wilkins <gregw@webtide.com> wrote:

> On 1 March 2011 01:32, John Tamplin <jat@google.com> wrote:
>> 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.
> 
> Well I remember the proposal for deflate stream being made, but I
> certainly don't recall any consensus that it should be put into the
> draft.  There have been consistent voices against compressing the
> framing.
> 
> I really think this is an important point of principal, if any
> arbitrary extension is free to entirely change what is sent on the
> wire, then we are going to have a very difficult environment in which
> to develop any kind of meaningful intermediaries.    I keep coming
> back to the analogy of HTTP, where it is not legal to just add a
> header to define an extension and then change HTTP framing entirely.
> The only way to break out of HTTP framing is with something like
> Upgrade or CONNECT.
> 
> If the first exemplar of an extension we have is something that
> completely changes what is sent over the wire, then I think we have
> totally devalued WS framing as a standard.
> 
> regards
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi