1
Vote

The use of the "null" origin in the samples can be confusing

description

I started playing with the console sample and doing some basic prototyping. As time went on and the project changed I tried moving my prototype client.html file to a webserver and couldn't get my app that worked fine via file:/// to work over http://. After stepping through some failed requests I finally realized the problem was due to the "null" origin value specified when calling the WebSocketServer constructor which becomes invalid when the file is delivered via http.

It seems like a valuable feature would be to add an origin wildcard of "*" which would allow requests from any origin and possibly use that in the samples to avoid the pitfall I ran into. Or if nothing else maybe a comment showing the WebSocketServer constructor with an http based origin.

It seems like a conditional on the origin test like the following could easily make this feature possible:
if (hasRequiredFields && "ws://"+ClientHandshake.Host == Location && (Origin == "*" || ClientHandshake.Origin == Origin))

comments

jlewin wrote Dec 5, 2010 at 7:19 PM

After reading the spec I now realize how absurd the suggestion of a wildcard on origin would be.

I still believe the sample projects could better inform users of the origin functionality instead of forcing them down the path of troubleshooting. When returning to the original project I noticed there is already a large block of text that tries to address this issue:
        // the parameters describe where to listen for connections (the port) and which connections to accept (the origin and location)
        // it is important that these are correct, or the server might not accept the incoming connections
        // see http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol, to learn more about these parameters
While this is technically accurate, it might be more helpful in the beginner sample to put a concise comment that says something to the effect of "if you move client.html to a webserver the WebSocket connection will be refused until you update the origin to match the site (e.g. "http://example.com")" and/or include a commented line showing the difference:
//var nugget = new WebSocketServer(8181, "http://www.example.com", "ws://localhost:8181")

Finally, this problem would be much discoverable if the origin value was tested after determining the handshake data is invalid and a log entry was written explaining the connection was refused due to same origin policy:
            if (ClientHandshake.Origin != Origin)
            {
              // origin policy mismatch
              Log.Debug(string.Format("Handshake failed because the client origin ('{0}') does not match the authorized origin ('{1}')", ClientHandshake.Origin, Origin));
            }
            else
            {
              // the client shake isn't valid
              Log.Debug("invalid handshake received from "+state.socket.LocalEndPoint);
            }

rssingh wrote Jan 17, 2011 at 4:40 AM

Thanks jlewin, the last part was exceptionally useful (adding "Log.Debug(string.Format("Handshake failed because..."). It helped solve my issues immediately.