Subject: [hybi] The WebSocket protocol issues.

From: Alexander Voronin <[email-masked]>
Date: Thu, 23 Sep 2010 18:22:21 +0300

Unfortunately I did not find person who's made changes from 75 to 76
versions of the draft, so I decide to write right in Your mailing list. So
sorry for any inconvenience.

I'm high graduated C/C++ developer and almost all of my work is dedicated to
server side stuff like appication servers andhigh-load systems. Today I've
try to obtain information about WebSockets and was a bit confused.

Guys, are You serious about "1.3 Opening handshake" paragraph? Who can
explain for me and thousands of other developers for what the hell we'll
need all this "take the digits from", "obtain a 32-bit number",
"big-endian", "MD5" and other stuff? From who or what we'r trying to
"protect" socket connection? From common sense and sane people? Why not
enough just few (and already implemented) HTTP headers? Why we need two
reserved bytes 0x00 and 0xFF in each message in start and end instead of
just one 0x00 or 0xFF at the end, as It always was? Who is that wicked man
who invents up with all this nonsense?

Sorry for emotions and please explain something for me.

---

From: Simone Bordet <[email-masked]>
Date: Thu, 23 Sep 2010 17:41:21 +0200

Hi,

> Sorry for emotions and please explain something for me.

Gut comments like yours, which I read with a moderately large smile,
are nonetheless irrelevant.

Rest assured that the people that has been selected as editor of the
specification for the protocol, and most if not all of the other
contributors in this list, are the top guys/gals in the area.
The protocol is still a moving target, it's in draft, it will improve.
Be patient; if you express your comments in a more constructive way,
they will be taken in account and discussed.

Regards,

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Pieter Hintjens <[email-masked]>
Date: Thu, 23 Sep 2010 18:20:54 +0200

Alexander,

I'd encourage you to start (and this applies to any mailing list,
really) by reading as much of the archives as you can.  You'll find
your question exhaustively discussed and answered over the last
months.

-Pieter

On Thu, Sep 23, 2010 at 5:22 PM, Alexander Voronin
<[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

-- 
-
Pieter Hintjens
iMatix - www.imatix.com

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 23 Sep 2010 09:52:04 -0700

> your question exhaustively discussed and answered over the last

The current draft is 
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-01, 
which should help with the framing questions.

But the archives aren't going answer the 1.3 Opening handshake question. 
That section was inserted by the previous editor without any discussion 
from the people on the list.

Since that handshake is non-standard, was not discussed before 
inclusion, and does not use common best practices, it's not surprising 
that good engineers from outside the list have the same reaction as 
Alexander and will continue to do so. It's just not the case that the 
handshake was well designed or that the archives will show a good 
justification for the design. "Are you serious?" is a perfectly 
appropriate reaction to the current handshake.

If there's any consensus, it's that the handshake may be nonsense, but 
it's straight-forward to implement, and because people want to ship 
websockets soon, it's not worth fixing to a more normal, sane handshake.

-- Scott

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 23 Sep 2010 10:06:41 -0700

On 23 September 2010 09:52, Scott Ferguson <[email-masked]> wrote:
> If there's any consensus, it's that the handshake may be nonsense, but it's
> straight-forward to implement, and because people want to ship websockets
> soon, it's not worth fixing to a more normal, sane handshake.

It should not surprise anybody here that I am not part of any
consensus that the handshake should remain and I think it is
definitely worth fixing.

I think the reluctance to fix it has mostly been due to partisan
politics - either defending the origins  and/or a reluctance to cause
offence by it's replacement with another solution.

I'm really sorry if the strength of my criticism of the handshake is
seen as offensive to any particular person/comp - but it is a howler
of a design (and I think we have all been guilty of individually
making the occasional howler).  The whole purpose of achieving
consensus in a WG before such ideas are put into the draft is to avoid
this exact circumstance of having an individual moment of poor design
included in the draft and then others having argue for it deletion
when the case was never made for it's inclusion.

regards

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 23 Sep 2010 11:04:19 -0700

Greg,

I want to point out that I am totally open to replacing the handshake.
However, I do think there are a set of requirements that we should meet:

1. Prevent cross protocol attacks. (It would really help if these were
enumerated in detail.) If WebSockets can be used to e.g. attack an SMTP
server and cause it to send mail, as one example, I think people would turn
off / not implement WebSockets, which would not be good.
2. Detect and fail in the presence of intermediaries that will cause
problems with the WebSockets connection. If there's an intermediary that is
going to be buffering messages for a long period of time waiting for a
connection to be closed, as is the case with some current HTTP
intermediaries, that would cause serious problems and I would want to know
that up front. The current handshake doesn't do a great job here in that
it's been pointed out (in Issue 4) that it hangs in the presence of certain
such proxies. As I stated in another email, I'm open to alternatives.
3. Compliance with HTTP up to the point of CONNECT.

Alternatives that actually meet the above criteria in a manner that is
sufficiently "better" than the current proposal I am fully open to.

-Ian

On Thu, Sep 23, 2010 at 10:06 AM, Greg Wilkins <[email-masked]> wrote:

> it's

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Sep 2010 20:42:45 +0200

Hi Ian,

> such proxies. As I stated in another email, I'm open to alternatives.

Concerning this HTTP compatibility issue, I proposed a quick-n-dirty fix
in the wording that at least renders it compatible with HTTP (in fact, I
even think that hixie proposed it first). However, I don't know how we
should work on the subject. Since last weeks were very much focused on
framing, I did not want to interfere with that work by proposing to
attack a second issue in parallel. And I don't know if we'd better just
fix it or rework it. If we just fix it (basically swap two sentences in
the server-side work), we also risk leaving it as-is and not fix other
possible issues. Maybe at this step this is acceptable, I don't know.
The only thing I know is that several server-side people had to apply
the workaround to get it to work through reverse-proxies, one of them
even posted on this list about it IIRC.

On another point, I hate the way it's worded. The protocol is not
described, we only get an english translation of one implementation,
which makes it terribly difficult to implement something that works with
different languages/frameworks, and to test for standards compliance. But
that might be secondary.

How can we advance on that issue ? Do you prefer that we run in incremental
steps, eg :

   1) fix HTTP compatibility without changing the protocol (swap the two
      sentences)
   2) write the protocol description somewhere.
   3) fix other issues (HTTP compliance, better error detection, ...)

Regards,
Willy

---

From: James Graham <[email-masked]>
Date: Thu, 23 Sep 2010 21:17:40 +0200 (CEST)

On Thu, 23 Sep 2010, Willy Tarreau wrote:

> different languages/frameworks, and to test for standards compliance.

I strongly disagree with the statement about an algorithmic description 
being hard to test. I have reviewed the tests for the Opera implementation 
of -76 and the algorithmic description is good for verifying the accuracy 
of the tests and ensuring that corner cases are covered. I find that other 
styles tend to be less rigorous or make it easier to miss the edge cases.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 23 Sep 2010 21:33:40 +0200

> styles tend to be less rigorous or make it easier to miss the edge cases.

I keep thinking it's difficult because the algorithm only focuses on two
specific points :
  - the client
  - the server

Anyone who has to design anything in between is left with that. Side X will
do this, side Y will do that. And if either does not ? Nothing planned for
that. For 30 years, RFCs were written with MUST, SHOULD, MAY, etc...  wording
for a reason : take decisions upon unexpected situations. Here, there are
simply no unexpected situations, only the ideal case is considered. And BTW
it has already failed, by considering that what worked in a simple
point-to-point test case was the representation of reality, leaving no room
for fixing issues. The only thing which breaks HTTP in draft 76 is the
wording ! The protocol itself works if you don't respect the imposed
algorithm !

Regards,
Willy

---

From: James Graham <[email-masked]>
Date: Thu, 23 Sep 2010 21:45:38 +0200 (CEST)

On Thu, 23 Sep 2010, Willy Tarreau wrote:

> that.

You should read it as "side X MUST do this, side Y MUST do that" (to 
within black-box observable limits).

> simply no unexpected situations, only the ideal case is considered.

This is not true. It is possible that for some situations the algorithm 
has undesirable behaviour, and it is possible that it fails to consider 
some situations. But it is far from the truth to say that it never allows 
for the possibility of unexpected behaviour.

> And BTW
> wording !

If you think there is a bug in the algorithm as stated that is fine and we 
should fix it. Suggesting that the wording should be more permissive so 
the spec is ambiguous, leaving implementations to rely on shared knowledge 
beyond the spec to achieve interoperability, is not acceptable.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 23 Sep 2010 13:54:39 -0700

>   3) fix other issues (HTTP compliance, better error detection, ...)

Willy,

I am planning on punting a lot of this from -02 since I still don't think
there's any consensus towards an answer, though I appreciate Greg's attempts
here, I want to discuss that before throwing into a draft. Also, I
sympathize with your complaints about the english translation of one
implementation, I was hoping we would get an alternate handshake proposal
that I could then write in the draft as opposed to just transliterating the
current handshake text into ABNF and then deleting it upon the next draft
update ;)

As for ways to move forward, I personally prefer a version of 2. Aka frame
it as "We need a handshake people are happy with." Someone comes up with a
handshake people are happy with, and that presumably is compatible with
HTTP, and then we throw that in the draft.

Text for better error detection is always appreciated independent of the
handshake issue.

-Ian

---

From: Alexander Voronin <[email-masked]>
Date: Fri, 24 Sep 2010 00:21:12 +0300

It's obvious that any cross protocol attacks can be avoided using simple MD5
digest or something MORE simplest like send and than receive kind of random
solt in headers. I believe there is no SMTP server that will send correct
answer to something like "Salt: ALAhjdj337fjl". This seems like paranoia.

About WebSocket and CONNECT method. I guess there is nothing in common at
all. CONNECT is a HTTP method, WebSocket is an extension (You are using GET
to establish connection right?). CONNECT definetly allows clients to use raw
sockets over HTTP, WebSockets just a high level with fragmentation and own
extensions. Data going trough CONNECT connection (nice pun!) is not parsed
by intermediaries (i want believe!), but WebSocket as extension to HTTP GET
may be parsed and even replaced by intermediaries. Check here
http://trac.tools.ietf.org/wg/hybi/trac/ticket/4 and You'll see that even
handshake has problems with compliance with HTTP basics.

About framing. I read the draft and have few ideas how to implement all this
in more simple manner and with few features that I learned from
"flash(XMLSocket.Socket) to appserver" development.If you do not mind, I
will explain.

Thanx to All for You. You are doing great job, but sometimes results has
nothing in common with reality.

2010/9/23 Ian Fette (イアンフェッティ) <[email-masked]>

-- 
когда я опустился на самое дно, снизу мне постучали..

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 23 Sep 2010 17:02:32 -0700

On 23 September 2010 12:17, James Graham <[email-masked]> wrote:
> of -76 and the algorithmic description is good for verifying the accuracy of
> the tests and ensuring that corner cases are covered. I find that other

I think it is apparent that we have a wide spectrum of opinions on the
value of an algorithmic specification.

However, while some obviously find it useful, I don't think that
anybody could argue that a formal specification in ABNF or similar is
going to be more rigorous than an english textual description.   If
you are keen ABNF can be used to automatically generate tests.

Now that we have ABNF in a normative, it makes little sense to have a
second normative section with english text.
So can we at least make the english text algorithms a non normative section?

regards

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Sep 2010 06:15:57 +0200

> HTTP, and then we throw that in the draft.

OK, then I'll try to spend some time discussing the pros and cons of various
proposal.

> Text for better error detection is always appreciated independent of the

I was meaning handshake error detection ;-)

Cheers,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Sep 2010 06:25:59 +0200

On Fri, Sep 24, 2010 at 12:21:12AM +0300, Alexander Voronin wrote:
> may be parsed and even replaced by intermediaries.

We also discussed the use of CONNECT in the past (I proposed it as an
alternative to GET+101). And the general feeling was that while it was more
commonly implemented and supported on proxies, it generally isn't implemented
at all on servers or there is a risk that some servers which share proxy
function might forward that further. Also, the only doc around CONNECT usage
refers to proxies, where an IP:port is expected as the URI. It's not certain
how many changes are required on various components to accept something else
there. So in the end, it might be harder to get CONNECT to work than to get
GET+101 work (it's already defined in RFC2817).

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Sep 2010 06:30:37 +0200

> So can we at least make the english text algorithms a non normative section?

Yes that would be great. I appreciate it as an implementation example or
guide, I just don't like having it as a description of the protocol.

Regards,
Willy