Re: [hybi] Websocket: two protocols into one, and Internet rules broken

[Iñaki Baz Castillo <[e-mail]>]

2011/6/16 Anthony Catel <[e-mail]>:
> "101 Switching Protocols
> The server understands and is willing to comply with the client's request,
> via the Upgrade message header field (section 14.42), for a change in the
> application protocol being used on this connection. The server will switch
> protocols to those defined by the response's Upgrade header field
> immediately after the empty line which terminates the 101 response.
> The protocol SHOULD be switched only when it is advantageous to do so. For
> example, switching to a newer version of HTTP is advantageous over older
> versions, and switching to a real-time, synchronous protocol might be
> advantageous when delivering resources that use such features."
>
> HTTP doesn't define that a binary protocol should not be used. It also
> doesn't define that "swithing protocols" means "must switch between
> different HTTP version".

Ok, RFC 2616 said that 21 years ago. That does not mean that it's
suitable. For me is just a vague specification that nobody cared too
much in 1999.



> > Now let's imagine we want web browsers to become real SIP or XMPP
> > clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
> > the browser will first open a TCP connection, then send an HTTP
> > "handshake" and then switch same TCP stream to speak SIP or XMPP? and
> > all this stuff just because "HTTP is the only protocol in the world"?
>
> Ok, but how do you handle origin security? By writting a SIP extension? And
> thus for every new protocol you want to handle?

Security would be handled at SIP or XMPP level. I dont' understand the
problem. If a web browser becomes a real SIP or XMPP client it could
handle authentication as stated for SIP/XMPP and prompt the human user
when required (as when a web server replies 401).



> Browsers were designed to speak HTTP. IMHO, if you break this rule, it
> leaves the doors wide open to any kind of crazy stuff.

Web-browsers must also speak DNS protocol (directly or indirectly, it
does not matter). If a new protocol is standarized for web browsers,
which is the problem? what about Flash or Java applets? they can open
TCP/UDP connections from the webbrowser to make usage of any other
protocol. Is it a risk? of course, so let's do standards and mandate
security mechanims. But that has nothing to do with "just use HTTP".

Note that web browsers were originally designed to speak HTTP and
render HTML pages. But now everybody wants IM, video, audio and
whatever through a web browser. There is no need to implement all
these new requeriments on top of HTTP. Maybe HTTP is not a good
protocol for that! there are other protocols.

Also, take into account that, after the handshake WebSocket is no
longer HTTP, so it *is* a different protocol. It doesn't matter what
browsers were originally designed to.



-- 
Iñaki Baz Castillo
<[e-mail]>