Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make it possible to unambiguously detect a SockJS request #85

Open
jkarneges opened this issue Jul 19, 2015 · 4 comments
Open

make it possible to unambiguously detect a SockJS request #85

jkarneges opened this issue Jul 19, 2015 · 4 comments

Comments

@jkarneges
Copy link

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_id path 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.

@brycekahle
Copy link
Contributor

What about a HTTP header? That way it doesn't change any URL semantics which people might be depending upon.

@jkarneges
Copy link
Author

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.

@brycekahle
Copy link
Contributor

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

@jkarneges
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants