Issue with onshape.com websockets about citadelcore HOT 6 CLOSED

I've been delving into this today, and the conclusion I've come to is that the context.RequestAborted cancellation token is getting canceled, which means the request is getting aborted, right?

The request is getting aborted before the socket is even created, it looks like to me, but I have no idea why. I'll keep examining this to see if I can get anywhere.

from citadelcore.

@kfreezen If that cancellation token is being flagged/set then it's being done by the internal processing of kestrel itself. I'd be curious to know why kestrel would be aborting the connection. Maybe timeout? I have not had a chance to look at this stuff yet because I've had a nagging problem in some server side code of mine draining all of my time this week. I'm going to crack into this stuff over the weekend though.

from citadelcore.

I've finally figured out where the problem lies, and it's not pretty.

In FilterWebsocketHandler.cs at line 64ish, we have

await context.WebSockets.AcceptWebSocketAsync();

cad.onshape.com sets a Sec-WebSocket-Protocol and expects a matching protocol header back from us. When no such header is returned, the browser aborts the connection, therefore causing the problem I was observing.

As far as I can tell, there is no way to force ASP.NET/Kestrel to return a matching protocol to the client browser on acceptance of the websocket connection.

The only fix I can come up with is adding a method to do what we want to ASP.NET Core's code, issuing a PR, and hoping it gets accepted.

from citadelcore.

@kfreezen Yikes. Well, there's probably exposed mechanisms buried in kestrel where we could handle it. First thing I'd check is to see if it's possible to build a connection handler like I did for handling HTTPS. You can get hold of the connection before kestrel does anything to it through an exposed interface. Might be a solution there. Worst case scenario you could do some reflection based hacks I guess to patch it.

from citadelcore.

@kfreezen Nope the solution is to reply with the server-selected subprocotol inline in the AcceptWebSocketAsync(... subproto here...) call.

What should be done though first is to establish the upstream client websocket connection, forward the Sec-WebSocket-Protocol header in that client connection, get the upstream server's selected protocol from the handshake result, and then pass that subprotocol to AcceptWebSocketAsync(...) to make sure we don't screw anything up acting as an invisible proxy.

from citadelcore.

wss://websocket.us.fleetmatics.com is not loading on https://reveal.fleetmatics.com/report/

Also a report of avery.com not working.

from citadelcore.