Integration with twisted.web.resource / URL handling?

#1

This is somehow related to another topic about URLs, but my goal is
different.

I'm trying to add websocket support to on existing twisted site,
instead of having to run a specific service on a different port.

For example: http://www.example.com/chat serve the html page and
ws://www.example.com/ws/chat is the websocket URL.

Adding a twisted.web.resource would be the most natural way,
unfortunately there is currently no such class.

Have anyone tried that, or is there a plan to achieve it?

It is somehow possible to achieve the same with the txwebsocket
project with a "handler" mechanism and a special twisted.web.Site
class. Not as clean as with a resource, and modulo it is for hixie-76
only, but it works.

0 Likes

#2

This is somehow related to another topic about URLs, but my goal is
different.

I'm trying to add websocket support to on existing twisted site,
instead of having to run a specific service on a different port.

Just as an addition for people who are ok with running on
_different_ port .. that is trivial, i.e.
https://github.com/oberstet/Autobahn/blob/master/testsuite/websockets/fuzzing_server.py

Its also easy to share session data between Web and WS objects when
running
a single Twisted reactor.

For example:http://www.example.com/chatserve the html page and
ws://www.example.com/ws/chatis the websocket URL.

Adding a twisted.web.resource would be the most natural way,
unfortunately there is currently no such class.

Have anyone tried that, or is there a plan to achieve it?

I did not try .. wasn't a goal to achieve. I'm not sure if
that can be done without modifying HTTPChannel or some other
code within Twisted itself. Dont know if there are appropriate
hooks. Because what needed to happen was, that after recognizing
a WS upgrade HTTP header, subsequent processing needs to be done
by the WS implementation, not the "normal" HTTPChannel etc any
longer.

For Autobahn, making that part/integrate of/with twisted.web
was not a goal and there are no plans to do so. My perspective is:
WS is - after the handshake - not HTTP any longer. Its also not
a "resource serving thing", like HTTP/twisted.web - its a connection
oriented full-duplex messaging channel. Quite a difference.

That said, if someone comes up with a clean/sane way of hooking
into HTTPChannel or the like, it could be a feature.

It is somehow possible to achieve the same with the txwebsocket
project with a "handler" mechanism and a special twisted.web.Site
class. Not as clean as with a resource, and modulo it is for hixie-76
only, but it works.

The author of txwebsocket has recently replied on the Twisted list
saying he plans to take up development again. Maybe look at that.

Just interested: why do you need to run Web and WS on same host/port?

Here is what we do regularily:

www.xyz.com:80
ws.xyz.com:80

are routed by firewall to

10.0.0.0:8080 and 8090 which are run by a single Twitsed reactor
serving twisted.web on 8080 and autobahn on 8090.

0 Likes

#3

> This is somehow related to another topic about URLs, but my goal is
> different.

> I'm trying to add websocket support to on existing twisted site,
> instead of having to run a specific service on a different port.

Just as an addition for people who are ok with running on
_different_ port .. that is trivial, i.e.https://github.com/oberstet/Autobahn/blob/master/testsuite/websockets...

Its also easy to share session data between Web and WS objects when
running
a single Twisted reactor.

Ok, but let's try to keep all traffic on one port: using non standard
ports increases the chances of failure due to firewalls in corporate
networks.

> For example:http://www.example.com/chatservethe html page and
> ws://www.example.com/ws/chatisthe websocket URL.

> Adding a twisted.web.resource would be the most natural way,
> unfortunately there is currently no such class.

> Have anyone tried that, or is there a plan to achieve it?

I did not try .. wasn't a goal to achieve. I'm not sure if
that can be done without modifying HTTPChannel or some other
code within Twisted itself. Dont know if there are appropriate
hooks. Because what needed to happen was, that after recognizing
a WS upgrade HTTP header, subsequent processing needs to be done
by the WS implementation, not the "normal" HTTPChannel etc any
longer.

For Autobahn, making that part/integrate of/with twisted.web
was not a goal and there are no plans to do so. My perspective is:
WS is - after the handshake - not HTTP any longer. Its also not
a "resource serving thing", like HTTP/twisted.web - its a connection
oriented full-duplex messaging channel. Quite a difference.

That said, if someone comes up with a clean/sane way of hooking
into HTTPChannel or the like, it could be a feature.

I came to the same conclusion. I'll try hooking the request from
higher level (Site?) and fork on github if i get some result quickly.

> It is somehow possible to achieve the same with the txwebsocket
> project with a "handler" mechanism and a special twisted.web.Site
> class. Not as clean as with a resource, and modulo it is for hixie-76
> only, but it works.

The author of txwebsocket has recently replied on the Twisted list
saying he plans to take up development again. Maybe look at that.

Just interested: why do you need to run Web and WS on same host/port?

Here is what we do regularily:

www.xyz.com:80
ws.xyz.com:80

are routed by firewall to

10.0.0.0:8080 and 8090 which are run by a single Twitsed reactor
serving twisted.web on 8080 and autobahn on 8090.

True, provided that you can configure the name resolution and put a
reverse proxy (haproxy was known to be a good solution for hixie-76,
probably still is with the recent drafts).
Since websocket is designed to be http compliant, my point is that
infrastructure and dependencies requirements could be limited to a
minimum set, ideally rely only on a flexible web server like twisted.

ยทยทยท

On 26 sep, 13:50, tgo <tobias.o...@gmail.com> wrote:

0 Likes

#4

Ok, but let's try to keep all traffic on one port: using non standard
ports increases the chances of failure due to firewalls in corporate
networks.

Yes, but the port visible externally can be 80 for both WS and plain
old HTTP. Just need to configure your own firewall to do the TCP
forwarding to the host running Twisted with WS on one port and
HTTP on the other.

At least in our network infrastr., its quite natural and doesnt add
anything, since any traffic needs to pass the firewall (ours) anyway.

> That said, if someone comes up with a clean/sane way of hooking
> into HTTPChannel or the like, it could be a feature.

I came to the same conclusion. I'll try hooking the request from
higher level (Site?) and fork on github if i get some result quickly.

cool. if you have questions, ping me. when you have something also,
maybe it makes sense to reintegrate back.

> Here is what we do regularily:

>www.xyz.com:80
> ws.xyz.com:80

> are routed by firewall to

> 10.0.0.0:8080 and 8090 which are run by a single Twitsed reactor
> serving twisted.web on 8080 and autobahn on 8090.

True, provided that you can configure the name resolution and put a
reverse proxy (haproxy was known to be a good solution for hixie-76,
probably still is with the recent drafts).
Since websocket is designed to be http compliant, my point is that
infrastructure and dependencies requirements could be limited to a
minimum set, ideally rely only on a flexible web server like twisted.

We dont run reverse proxies for doing that. Stateful TCP forwarding
is a feature of the firewall we use (OpenBSD PF).

And doing that - for us - doesnt add anything: firewall is in-band
always anyway ..

I would hesitate to put a HTTP rev proxy in-band with WS. I admit
I'm a OpenBSD fan. If PF doesnt suffice, there is relayd, which can
do Layer7 and is integrated with OBSD.

Configuring subdomains isnt a big deal also. So for us, this works
quite well and natural.

Anyway, I can see why that feature could make sense in other contexts.

0 Likes