You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
?sockjs=true
.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.
The text was updated successfully, but these errors were encountered: