sockjs-protocol
sockjs-protocol copied to clipboard
make it possible to unambiguously detect a SockJS request
I'm the developer of Pushpin, an HTTP/WebSocket proxy server with SockJS support. The way the SockJS feature works is you enable it on one or more URI paths, and Pushpin will translate the SockJS protocol from a client into a native WebSocket connection with the origin server.
The downside to the current implementation is that it has to be explicitly enabled per path. This is because SockJS requests aren't unambiguously identifiable. The way it works now is you set sockjs=/some/path in the configuration, such that a POST to /some/path/{arbitrary-string}/{arbitrary-string}/xhr is intercepted as a SockJS-related request and an outbound WebSocket connection is made to /some/path on the origin server.
It would be awesome if there were a way to automatically detect SockJS requests made to any path, so that explicit configuration like this is not required.
A couple of ideas:
- Have the client add a query parameter like
?sockjs=true. - Have the
server_idpath segment be more identifiable. The spec says this should be a three digit number but it could be prefixed with a unique string, e.g..sockjs-000.
Either of these approaches shouldn't break existing servers.
What about a HTTP header? That way it doesn't change any URL semantics which people might be depending upon.
A header would be the ideal way, but I don't think a header can be set in all cases (e.g. jsonp, websockets), so a fallback would be needed.
Are you running a SockJS server? If you return a base_url in the info response, you can control the url that the client connects to. This would allow you to use a URL that you can detect as SockJS. See https://github.com/sockjs/sockjs-client/blob/5af2fce8ec2c33be207b95b45b10c3cd14223532/lib/main.js#L186
Pushpin does support the /info endpoint, but this is also too ambiguous to match all paths on. Can't just hijack all GET requests to URIs ending with /info under the assumption it's SockJS-related.