Subject: [hybi] draft-10 questions

From: Tobias Oberstein <[email-masked]>
Date: Sun, 31 Jul 2011 06:13:07 -0700

I'm implementing WebSockets and have some questions where I can't figure out the answer from the draft spec.
That could be my fault, but hints would be welcome anyway ..

1.
Are data frames of payload length 0 allowed?
If so, are data messages of length 0 (where all fragments have length 0) allowed?
If so, what is a browser supposed to do? Fire an JS onMessage() event with 0 length string?

2.
In the context of a persistent http connection, what is allowed _before_ the WebSocket handshake
(that is before client sends GET with upgrade header)?
For example, are "normal" GETs allowed? In other words: is it permissable for a client to do "normal"
http on a persistent connection, and then  - at any point - decide to request to upgrade to WebSocket?

3.
When the client has sent an upgrade request, the spec says on server response

   The handshake from the server is much simpler than the client
   handshake.  The first line is an HTTP Status-Line, with the status
   code 101:

        HTTP/1.1 101 Switching Protocols

   Any status code other than 101 indicates that the WebSocket handshake
   has not completed, and that the semantics of HTTP still apply.

Does that mean, the server may send not only http error codes, but also for example http redirects?

4.
The spec defines 2 new URI schemes for WebSockets: ws and wss.

On the other hand, 
http://tools.ietf.org/html/draft-ietf-websec-origin-02

"If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts,
and ports."

Does that mean that with browsers, a JS script coming from (http, somehost, 80) is not allowed
to contact (ws, somehost, 80), because http != ws?

I guess that is expected to succeed, but then, what is the purpose/semantics of the new schemes?

---

From: Patrick McManus <[email-masked]>
Date: Sun, 31 Jul 2011 12:02:37 -0400

> If so, what is a browser supposed to do? Fire an JS onMessage() event with 0 length string?

0 length strings are valid and useful strings. (e.g. the name of the
band on stage that is displayed on an electronic marquee, when nobody is
playing.) Fragmenting a 0 length string is silly, but harmless.

> http on a persistent connection, and then  - at any point - decide to request to upgrade to WebSocket?

prior to the 101 the connection is http. So yes, you can send the
bootstrap http request on a reused http connection. You can do anything
HTTP allows you to do, because the handshake is carried out over HTTP.
That's the point of reusing the infrastructure.

> Does that mean, the server may send not only http error codes, but also for example http redirects?

The server may do so as they are legitimate HTTP. Note that HTTP doesn't
require the client to follow the returned redirects, it just defines
what they mean. In the context of the current Websocket API browsers
implementing that would not follow the redirect.

> to contact (ws, somehost, 80), because http != ws?

loosely - the js can open ws to any host (not just somehost) because ws
builds in an origin enforcement opportunity for the server and this
mechanism dates back to day 1 of websockets. (as opposed to http which
needs to worry about hosts that don't participate in cross origin
enforcement algorithms).

---

From: John Tamplin <[email-masked]>
Date: Sun, 31 Jul 2011 13:09:24 -0400

> playing.) Fragmenting a 0 length string is silly, but harmless.

You could imagine sending a 0-length fragment would be useful as sort of a
keep-alive in the middle of a streaming message when the next chunk of the
message hasn't been generated yet.  Weak, admittedly.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Tobias Oberstein <[email-masked]>
Date: Sun, 31 Jul 2011 10:12:51 -0700

thanks for your explanations .. very helpful.

1. - 3.: ok, got it. nice example with 1.;)

> > "If the two origins are scheme/host/port triples, the two origins are
> > the same if, and only if, they have identical schemes, hosts, and
> > ports."
> >
> > Does that mean that with browsers, a JS script coming from (http,
> > somehost, 80) is not allowed to contact (ws, somehost, 80), because http
> != ws?
> >
> 
> needs to worry about hosts that don't participate in cross origin enforcement
> algorithms).

just to be sure to get that right:

A js served to a browser from http://somehost:80 can contact _any_ ws(s)://XXX:YYY ?

It's at the sole discretion of that other host to accept (depending e.g. on ws-origin) the ws ?

so for WebSockets in browsers, the "same origin policy" does not apply at all?

but the ws-origin header _will_ be set reliably by browser .. e.g. also for background WebWorkers stuff
spawned by the original served js?

ok.

How does that translate to cookie handling (in browsers)?

e.g. under what circumstances will a cookie A set by the original js serving http://somehost:80 be
delivered in the headers of an ws outgoing from that js?

or, is that browser implementation dependent?

sorry for that trail of Qs, but the answer was somehow completely unexpected for me ..