Re: [hybi] SPDY protocol from google frame

[Greg Wilkins <[e-mail]>]

Firstly it is really great that the SPDY guys are reading this
list!   I have some questions for you below after my own little
rant (haven't had a rant for a week or two... withdrawal)


<rant>
  As somebody who has implement both HTTP and several ss7 related
  telecommunications protocols - I can definitely say that I can see
  the benefits of both points of view.

  Unfortunately websocket has been designed (IMNSHO) to capture
  the worse aspects of both.

  It does not have the ease of debugging of a text protocol, yet it
  does not have the predictability or security from injection that
  you get with binary protocols that have fixed header sizes.

  Instead we have this strange mix of two types of framing - both
  sentinel based.  One looks for a sentinel byte to mark the end
  of the frame and the other looks for a sentinel bit to mark the
  end of the frame length.
</rant>


However, to be more constructive:  The IETF is very likely
to form a WG that is focused on standardizing websocket.

One of the things I would very much like that WG to achieve
is a rationalization of the framing in Websocket to
a fixed length length prefix (double 'length' is deliberate).

IF (big IF) this was achieved - it was my intention to
redo the BWTP proposal as something that could be carried
over websocket framing.

Would the google SPDY folks be interested in doing the same
with their protocol.   If so, I'd be very much inclined to
combine the efforts as the efforts are very similar?

I think that having something with the advance semantics of
HTTP that can be carried over a bidirectional transport
with reduced header overheads would be absolutely awesome
(although I'd advocate having channel header defaults
as in BWTP rather than scary gzipped headers - but minor point).

Since there is some convergence of efforts around websocket,
it would be a real pity if a) we could not make it's framing
acceptable to more efforts; b) other efforts duplicated the
work needed to get browser/intermediaries/servers to accept
a new transport.


cheers










































Roberto Peon wrote:
> Having implemented the HTTP framing library that Google uses (yes I'm
> one of the SPDY guys), I can say that I absolutely hate dealing with
> non-length prefixed protocols.
> With HTTP, I don't know how much to allocate, I have to scan
> byte-by-byte for boundaries, and when dealing with text.. and worse,
>  you get into all sorts of fun ambiguities about what is allowed (e.g.
> is a newline allowed in quoted text?)
> Some of that was addressed with HTTPbis, but it is no fun whatsoever
> dealing with header-injection where unknown people can change your framing. 
> 
> For my sanity, security, and for significantly better performing
> proxies, I prefer length prefixing! :)
> -=R