Subject: [hybi] The charter vs the specification

From: Benjamin Black <[email-masked]>
Date: Sat, 4 Sep 2010 11:11:55 -0700

I am confused by the contradiction between the WG charter and the
WebSockets specification.  Specifically, this:

"The Hypertext-Bidirectional (HyBi) working group will seek
standardization of one approach to maintain bidirectional
communications between the HTTP client, server and intermediate
entities, which will provide more efficiency compared to the current
use of hanging requests."

There are things that match this description, for example the Reverse
HTTP work.  What it does not describe is WebSockets, at least not
without a very convoluted reading.  Unlike the stated goal of HyBi,
the goal of WebSockets is to permit sharing of a TCP port between an
HTTP service and a non-HTTP, bidirectional, binary protocol service.
Neither clients nor servers for WebSockets need speak HTTP at all.  In
order to meet its goal, the WebSockets protocol requires an upgrade
process that meets two requirements:

1) Looks enough like HTTP that the TCP socket sharing server can
process it to distinguish it from a regular HTTP request.
2) Is actually an invalid HTTP request, such that non-WebSockets
speakers, particularly intermediate devices that would fail on the
WebSockets traffic, can't process it.

I support both the WebSockets goal and the requirements for the
upgrade process (so much so that I am implementing the protocol right
now).  What has caused me much confusion, and others, too, based on
the mailing list archives, is the contradiction between the HyBi
charter and the WebSockets specification.  The charter is clear that
the purpose of the WG is standardization of a protocol to "maintain
bidirectional communications between the HTTP client, server and
intermediate entities".  Worse,
draft-ietf-hybi-thewebsocketprotocol-01 is phrased in its abstract and
introductory sections in such a way that what it does could be
misunderstood as HTTP compliant.

This is a really unfortunate state of affairs.  Could someone explain
how it got to this point and, perhaps, why the charter doesn't need to
be changed, all evidence to the contrary?  Sorry if I'm sounding a bit
like a certain long-time standards mailing list loony, I just haven't
seen this clear a disconnect between charter and work in a WG before.

b

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 04 Sep 2010 22:07:18 +0200

>WebSockets traffic, can't process it.

With http://www.ietf.org/mail-archive/web/hybi/current/msg02955.html it
is my understanding that communication between conforming Websocket im-
plementations will violate no requirement of the HTTP specification, so
there would be no invalid requests (unless the group decides that the
protocol should not piggy-back on HTTP at all, as some are proposing).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Benjamin Black <[email-masked]>
Date: Sat, 4 Sep 2010 13:24:26 -0700

> plementations will violate no requirement of the HTTP specification, so

Thank you for the link!  It actually does not say all communication
will violate no requirement of the HTTP specification, it says
everything will be HTTP compliant until upgrade completes.  After
upgrade, it is no longer HTTP compliant, and if the connection is not
in a (HTTP CONNECT) tunnel, is likely to confuse intermediate
non-WebSockets HTTP speakers.  Even with an HTTP compliant upgrade
handshake, the WebSockets specification directly conflicts with the WG
charter.

> protocol should not piggy-back on HTTP at all, as some are proposing).

The protocol is not piggy-backed on HTTP, which is exactly what puts
it in conflict with the charter.  There is an upgrade mechanism
defined to switch from HTTP to WebSockets, at which point it is just
WebSockets on TCP, without any HTTP involved.  Nothing in the spec, so
far as I can see, precludes use of WebSockets without the HTTP upgrade
handshake, if folks choose to implement WS-only clients and servers.

b

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 04 Sep 2010 23:30:35 +0200

* Benjamin Black wrote:
>upgrade, it is no longer HTTP compliant, ...

You can only violate requirements of the HTTP specification when they
are applicable, and they are not after the protocol has been switched.

>handshake, if folks choose to implement WS-only clients and servers.

The handshake is defined to be part of the protocol. You can of course
define the protocol without the handshake and then define the details
of the protocol switch from HTTP separately, but that is mostly a matter
of termininology (though I note defining them separately would set ex-
pectations poorly and exchanging raw WebSocket frames without ensuring
client and server both agree to do so would likely be risky; right now,
say "DELETE ..." in US-ASCII should be fine WebSocket text frame.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Sep 2010 16:18:09 -0700

> are applicable, and they are not after the protocol has been switched.

Right. I think this is basically a matter of protocol wordsmithery. As long
as the initial handshake is HTTP compliant, and this spec Updates HTTP,
I don't see a compliance problem, though I agree it's not really part of
HTTP.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 5 Sep 2010 07:12:54 +0200

On Sat, Sep 04, 2010 at 01:24:26PM -0700, Benjamin Black wrote:
> WebSockets on TCP, without any HTTP involved.

This is normal since HTTP only supports a request/response mechanism.
WebSocket wants to be truly bidirectional, so it can only use HTTP to
set up the connection and switch to the protocol itself.

> Nothing in the spec, so

Such hypothesis have already been discussed (WS on it own port, WS over
TLS, ...) and the recent work on the framing may make that possible if
we manage to limit the dependency on HTTP for the handshake.

Willy

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Sep 2010 13:59:03 -0400

> we manage to limit the dependency on HTTP for the handshake.

The mindset seems to be that WS will be open ended and be useful 
against existing backend internet protocol servers (i.e. SMTP, POP3, 
FTP, TELNET or any other TCP based server, etc). IOW, no changes 
required on the server-side.

Since the WS stack is filtering on well-known ports, these internet 
protocol servers would have be servicing other non-filtered ports.

So the motivation for a non-handshake WS stack is to be able to work 
with existing backend protocol servers but servers that not totally 
clueless about the type of clients hence binding to other ports.

I think that regardless of the specific HTTP dependency, there still 
needs to be some binding, anchor, association to some initial portal. 
If we want to have no handshake, then either it is IP authentication 
or the handshaking is delayed to the OnMessage() I/O.  I think that 
the better solution is for tunneling or proxy that will do the 
handshake then connect to the legacy protocol server.

Either way, the server would be the ultimate decider by:

    - Binding to a not well-known port
    - Using a proxy to filter ANY initial handshake

Out of curiosity,  I did a quick WSPORTSCAN.HTML script to open ports 
1 to 100 and got the following (Using CHROME):

port: 1 | except: Error: SECURITY_ERR: DOM Exception 18
port: 7 | except: Error: SECURITY_ERR: DOM Exception 18
port: 9 | except: Error: SECURITY_ERR: DOM Exception 18
port: 11 | except: Error: SECURITY_ERR: DOM Exception 18
port: 13 | except: Error: SECURITY_ERR: DOM Exception 18
port: 15 | except: Error: SECURITY_ERR: DOM Exception 18
port: 17 | except: Error: SECURITY_ERR: DOM Exception 18
port: 19 | except: Error: SECURITY_ERR: DOM Exception 18
port: 20 | except: Error: SECURITY_ERR: DOM Exception 18
port: 21 | except: Error: SECURITY_ERR: DOM Exception 18
port: 22 | except: Error: SECURITY_ERR: DOM Exception 18
port: 23 | except: Error: SECURITY_ERR: DOM Exception 18
port: 25 | except: Error: SECURITY_ERR: DOM Exception 18
port: 37 | except: Error: SECURITY_ERR: DOM Exception 18
port: 42 | except: Error: SECURITY_ERR: DOM Exception 18
port: 43 | except: Error: SECURITY_ERR: DOM Exception 18
port: 53 | except: Error: SECURITY_ERR: DOM Exception 18
port: 77 | except: Error: SECURITY_ERR: DOM Exception 18
port: 79 | except: Error: SECURITY_ERR: DOM Exception 18
port: 87 | except: Error: SECURITY_ERR: DOM Exception 18
port: 95 | except: Error: SECURITY_ERR: DOM Exception 18
port: 2 | Disconnected - status 2
port: 3 | Disconnected - status 2
port: 4 | Disconnected - status 2
port: 5 | Disconnected - status 2
port: 6 | Disconnected - status 2
port: 8 | Disconnected - status 2
port: 10 | Disconnected - status 2
port: 12 | Disconnected - status 2
port: 14 | Disconnected - status 2
port: 16 | Disconnected - status 2
port: 18 | Disconnected - status 2
port: 24 | Disconnected - status 2
port: 26 | Disconnected - status 2
port: 27 | Disconnected - status 2
port: 28 | Disconnected - status 2
port: 29 | Disconnected - status 2
port: 30 | Disconnected - status 2
port: 31 | Disconnected - status 2
port: 32 | Disconnected - status 2
port: 33 | Disconnected - status 2
port: 34 | Disconnected - status 2
port: 35 | Disconnected - status 2
port: 36 | Disconnected - status 2
port: 38 | Disconnected - status 2
port: 39 | Disconnected - status 2
port: 40 | Disconnected - status 2
port: 41 | Disconnected - status 2
port: 44 | Disconnected - status 2
port: 45 | Disconnected - status 2
port: 46 | Disconnected - status 2
port: 47 | Disconnected - status 2
port: 48 | Disconnected - status 2
port: 49 | Disconnected - status 2
port: 50 | Disconnected - status 2
port: 51 | Disconnected - status 2
port: 52 | Disconnected - status 2
port: 54 | Disconnected - status 2
port: 55 | Disconnected - status 2
port: 56 | Disconnected - status 2
port: 57 | Disconnected - status 2
port: 58 | Disconnected - status 2
port: 59 | Disconnected - status 2
port: 60 | Disconnected - status 2
port: 61 | Disconnected - status 2
port: 62 | Disconnected - status 2
port: 63 | Disconnected - status 2
port: 64 | Disconnected - status 2
port: 65 | Disconnected - status 2
port: 66 | Disconnected - status 2
port: 67 | Disconnected - status 2
port: 68 | Disconnected - status 2
port: 69 | Disconnected - status 2
port: 70 | Disconnected - status 2
port: 71 | Disconnected - status 2
port: 72 | Disconnected - status 2
port: 73 | Disconnected - status 2
port: 74 | Disconnected - status 2
port: 75 | Disconnected - status 2
port: 76 | Disconnected - status 2
port: 78 | Disconnected - status 2
port: 80 | Disconnected - status 2
port: 81 | Disconnected - status 2
port: 82 | Disconnected - status 2
port: 83 | Disconnected - status 2
port: 84 | Disconnected - status 2
port: 85 | Disconnected - status 2
port: 86 | Disconnected - status 2
port: 88 | Disconnected - status 2
port: 89 | Disconnected - status 2
port: 90 | Disconnected - status 2
port: 91 | Disconnected - status 2
port: 92 | Disconnected - status 2
port: 93 | Disconnected - status 2
port: 94 | Disconnected - status 2
port: 96 | Disconnected - status 2
port: 97 | Disconnected - status 2
port: 98 | Disconnected - status 2
port: 99 | Disconnected - status 2
port: 100 | Disconnected - status 2

Each OnClose() disconnect event came in slowly.  The SECURITY_ERR 
exceptions was immediate.

So if we really wanted WS to be independent of the HTTP portal, maybe 
the server should be able to tell the WS stack not to filter certain 
well-known ports. This would represent a security threat entry point 
so we probably don't want to do allow this, but you can't stop bad 
guys with custom WS stacks.

For example, lets say we wanted to have a simple EMAIL client (MTA) 
written in WS-HTML (HTML + WebSocket Javascripting) and I didn't want 
to have specific SMTP ports for this - just use existing port 25 or 
port 587 servers.

Even if WS was changed to allow for a non-handshake, somehow we need 
to tell the WS stack to allow port 25 or port 587.

If you say that at a minimum, a non-handshake WS requires a special 
port, then its really not independent of any other requirement.

That may good enough to at least make this a server-authorized and 
allowed portal.

But you won't be able to use a generic WS-HTML client as a general 
purpose client for existing legacy internet protocol services.  In 
lieu of controlling what well-known ports are filtered by the WS stack 
implementation, you still need that special backend server setup on a 
different port.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com