Reverse protocol handling for WebSocketResource

I have a set of unit tests (in https://github.com/warner/magic-wormhole) that recently started failing when I combine autobahn-0.13.1 and Twisted trunk. It looks like https://github.com/twisted/twisted/commit/4f9e36d8ad21f9d73369f4d506bab30f61c2ad71 (landed 29-Mar-2016) is where the problem started (that’s the first revision after Twisted-16.1.1 was branched off that causes my project’s tests to fail).

The commit says:

Merge hide-request-transport-8191-5: Hide the transport backing the HTTPChannel object from twisted.web Resource objects.

And my tests are using WebSocketResource to put a websocket on a specific URL. I haven’t tracked down the specific failure yet, but it seems like the server is having an internal error when the client attempts to connect to it, or the server isn’t accepting the connection at all.

The relevant Twisted bug is at https://twistedmatrix.com/trac/ticket/8191 .

When I get some time (maybe next week), I’ll figure out how to run autobahn’s test suite against various versions of Twisted and see what happens.

[meejah]

@oberstet FWIW, I quickly rebased the patch from Twisted’s 3204 to Twisted trunk, and further hacked my example above so that it does self.transport.switchProtocol(..) and it works fine.

So, if that gets patched up and landed in twisted then potentially something like the hacked up MultiProtocol/MultiProtocolFactory (er, SwitchableProtocol I called it above) thing could also go into Twisted, and then all Autobahn would need is a factory-function that creates an appropriate instance of a MultiProtocolFactory (i.e. all the stuff I put in server2.py, and the predicates or something like them).

[glyph]

I only care about latency until WebSocket takes over.

My point about latency is that you may be serving both traditional-web-application and websocket/autobahn interfaces for the same application. I understand that you could do this a different way, but keeping all your services the same can really simplify deployment pipelines, and it’s definitely something that Twisted works hard to make possible, and Autobahn specifically allows for.

But, as @Lukasa explained - there’s no overhead beyond the initial TLS handshake for websocket connections anyway, since wss:// clients won’t advertise an ability to speak HTTP/2.