Subject: [hybi] Some comments on draft-ietf-hybi-thewebsocketprotocol-03.txt

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 29 Oct 2010 15:27:48 +0800

Hi,

Some questions and clarifications on the web socket draft-v03.

[1] For the handshake the GET method, same as HTTP is used. After
handshake is it only frames used for data transfer? Is there any methods
such as PUT, POST as in HTTP involved in this protocol? How wil the
client and server interpret the frame messages? What action will it
perform on the resources based on the messages received?
Does it mean that when the client sends a message the server will
interpret as PUT or POST. The server send a frame to client, the client
will interpret as a response to GET. Is this right?

[2] Is there a way to open a single handshake for multipe resources in
the current design of web socket protocol?  I am asking this because one
of the goals of this protocol is to limit the connections and reduce
signaling.

[3]From the reading of the draft, if there is an on path HTTP proxy and
TLS is not used, will the handshake fail.  Then how is this solved? Are
there any websocket proxies or special port numbers defined for web
socket so that HTTP proxy does not intercept the packet?  I was unable
to see special or unique port numbers for web socket in the draft.
Mostly came across HTTP port numbers such as 80(no security),
443(security).

[4] In section 1.6 it is mentioned that if web socket is used by
dedicated client the origin model is not useful.  Why is this so?

[5] In section 4, there is mentioning about extension data. Not very
clear the usage of this. No description was given regarding the use of
this.  There are some fields defined to handle extension data (RSV
fields) but the use case is not clearly defined in the draft.

[6] In section 5, there is mentioining of interaction of websocket with
HTTP proxy.  My impression was websocket is very different from HTTP. So
how will it work when there is a proxy. How will the handshake succeed?
Are we considering an upgrade for the HTTP proxy and make it understand
websocket?

[7]Is 'sec-websocket-protocol' field an optional field in handshake or
mandatory?  From reading the client processing, looks like a mandatory
field.  But there is some text saying that this field is optional field.
Not clear on this. If protocol is NULL, then no need to send this field?

[8]The security feature used (sec keys) in the opening
handshake(challenge response) solves which security aspect?  Is it to
ensure that the websocket client is talking to a web socket server.
Which security feature is this method trying to achieve. Is it to
alleviate the cross protocol attack?

BR,
Mohana

---

From: Fumitoshi Ukai (鵜飼文敏) <[email-masked]>
Date: Fri, 29 Oct 2010 17:12:39 +0900

On Fri, Oct 29, 2010 at 16:27, Mohana Jeyatharan <
[email-masked]> wrote:

> handshake is it only frames used for data transfer?

we'll change the handshake, but as for draft-v03, yes.

> Is there any methods
> such as PUT, POST as in HTTP involved in this protocol?

no.

> How wil the

no, for the client side, it is assumed to be used with WebSocket API
http://dev.w3.org/html5/websockets/
client uses send() method to send message, and uses message event handler to
receive message.

> the current design of web socket protocol?

no for now.

>  I am asking this because one

websocket could reduce signaling, because it will requires 1 connection to
send/receive messages, while http basically requires 1 request/response per
message.

Anyway, websocket might add multiplexing in future, so it could limit the
connection to the host.

> Mostly came across HTTP port numbers such as 80(no security),

websocket goes though proxy with CONNECT. (5.1 step 3)
so, it might fail the handshake if proxy is configured to disallow the
connection to port 80 (or port that websocket is using).
Also, intercepting/transparent proxy might confuse websocket protocol as
http and handshake will fail.

> dedicated client the origin model is not useful.  Why is this so?

the client could set any arbitrary origin, so it could connect the target
server that wants to restrict the specific origin.

> fields) but the use case is not clearly defined in the draft.

I think extension will be discussing later.

> Are we considering an upgrade for the HTTP proxy and make it understand

As said, websocket goes through proxy with CONNECT. that is, it talks to the
proxy to open connection to the target websocket server
as https case.

> mandatory?

no.

> From reading the client processing, looks like a mandatory

if client opens a websocket as "new WebSocket(url)", then it won't send
"sec-websocket-protocol" field.

> alleviate the cross protocol attack?

yes, i think so.  it protects websocket client talks with http server, and
http client talks with websocket server.

regards,
ukai

>
> BR,
> Mohana
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Zhong Yu <[email-masked]>
Date: Fri, 29 Oct 2010 12:12:21 -0500

2010/10/29 Fumitoshi Ukai (鵜飼文敏) <[email-masked]>
>
> On Fri, Oct 29, 2010 at 16:27, Mohana Jeyatharan <[email-masked]> wrote:
>>
>> Hi,
>>

If the next handshake protocol still looks like HTTP, is it possible that a
new/dedicated HTTP method is used instead of GET, like WEBSOCKET?

A server serving both HTTP and WEBSOCKET should be able to identify
the protocol type of an incoming connection as early as possible.
Currently this isn't very easy. Naive string match for websocket
headers is wrong, implementations shouldn't do that(yet many will).
Theoretically we should apply a full fledged websocket parser before
we can know whether the connection is for websocket. And my
impression is that this parser has nothing to do with the HTTP parser.

If instead of GET we use a new http method, e.g. WEBSOCKET,
the server can identify a websocket connection just by naive string
match on the first 10 characters ("WEBSOCKET" SPACE).
That can make things a lot easier. Especially for components that
can't afford too much intelligence in them.

> if client opens a websocket as "new WebSocket(url)", then it won't send "sec-websocket-protocol" field.
>

I wonder why a subprotocol is justified. I skimmed the archive and
didn't see any
discussion about it. Any pointers?

Zhong Yu