Re: [hybi] It's time to ship

[Willy Tarreau <[e-mail]>]

Hello Ian,

On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette (????????????????????????) wrote:
> >  - you're using the OPTIONS method. The WG's consensus was voted as using
> >    GET. While technically working, OPTIONS limits some possibilities since
> >    no path is sent to the server.
> >
> >
> I agree it is important to be able to identify between various resources on
> a server. E.g. for our use, we will have multiple different websocket
> endpoints, and we want our frontend to be able to dispatch to the
> appropriate backend based on the information in the handshake. That said, I
> think the draft allows for that (Sec-WebSocket-URL), or as pointed out on
> another thread, it appears OPTIONS does allow for a path component. So, I
> think we should be able to resolve that point.

Once again,I'm not opposed at all to this point. I'd even say that would it
not have been accepted as a consensus in the last poll, I'd probably have
voted for it. It's just that it's a change from what was planned till now
and participants need to express their opinion on that point.

> >  - your proposal involves AES-128-CTR. As was discussed here, it seems
> > there
> >    are still export regulations for certain countries eventhough they're
> >    apparently fading out. It could still be a problem for companies who
> > want
> >    to export products to some countries and which never had to put crypto
> > in
> >    them.
> >
> 
> It would be nice to understand if this is actually a hard constraint.
> AES-128-CTR has the benefit of being well understood, as well as fast, as
> demonstrated by Maciej in another thread. That said, I don't care strongly
> one way or another here.

One of my issue with it is that despite being fast, it's a lot slower than
simpler masking. I design software components to be used at the border side
of infrastructures to dispatch the traffic to multiple servers, and I'm
very much concerned by the performance limitations. On a machine which has
normally no issue processing 10 Gbps of HTTP, I could not even process 1 Gbps
of WebSocket with large contents. This is much concerning because it implies
that in order to build the stream analysers we've talked about in the past,
it will become mandatory to install expensive crypto acceleration cards. This
is not logical for a protocol which is supposed to be transferred in clear
(ws:// as opposed to wss://). Checking for forbidden words, dangerous links
or forbidden contents on campus sites will be much more expensive due to this
masking algorithm alone.

> >  - several people on the list asked for the ability to be able to disable
> >    the masking in some well-controlled environments (eg: server-to-server
> >    communications). I see no provisions for this.
> >
> >
> There's nothing that would prevent you from writing an extension that would
> disable the masking, from my understanding.

Adam did not seem favorable to that.

> >  - it has not yet been stated whether only the payload or also the framing
> >    should be masked. Your proposal masks both, which means that it
> > definitely
> >    blocks any possibility of performing multiplexing later. There does not
> >    appear to have been a consensus in this area yet.
> >
> >
> I'm not sure why this would block the possibility of multiplexing. I would
> agree that would be a problem if it were the case. However, a number of the
> early proposals for multiplexing included something like a stream-id in the
> frame. This could still be present. Though it would be masked, so would the
> length and other things that a meaningful intermediary would care about, so
> assuming the intermediary was capable of un-masking, is this an issue?

Yes, and you got the point : if the ID is masked, how to you know which
stream it is in order to pick the right unmask key ? At least the stream
ID will have to be unmasked. If we prepend it before the frame, it means
a new framing format. Till not it was suggested to have it in the frame.

> >  - Greg proposed to replace the MORE bit with a FIN bit so that the first
> >    hello frame from the server starts with a high bit set, thus ensuring
> >    that we can break the connection on non-HTTP compliant intermediaries
> >    which would expect a second response after the 101.
> >
> >
> The draft Adam sent out is based on an intermediate version I had checked
> into SVN, back when it looked like we were gaining speed on CONNECT. I
> didn't yet get around to flipping MORE/FIN, but I don't have any ojbections
> to this.

OK.

> > Those are just a few notes, it's really not easy to changes :-/
> >
> 
> There's a tool on the IETF to diff drafts. I find it quite helpful, that
> said, a lot of text has changed because I had already started to make other
> requested changes (including trying to resolve the HTTP compliance issue, by
> stating the requirements of the handshake rather than stating send X bytes,
> send Y bytes, ...). This makes the diff a bit harder to interpret, for sure.

Ah, OK. Till now I'd only use the automated diffs between incremental drafts,
I did not know that there were other tools.

Regards,
Willy