Scgi / Fcgi Support

[bzeller]

Hi all,

i'm currently looking into adding SCGI support to Tufao, since i don't want Tufao to do static file serving in a production environment.

I personally would go for scgi instead of fcgi because its much easier to implement, basically just a netstring containing the headers, followed by the request body.

I thought maybe we could hijack onReadyRead in a HttpServerRequest subclass, parse the netstring and assemble a Http compatible request and forward it to the already implemented http parser.

Otoh, a scgi connector needs to worry about less things, like there will be no websocket upgrades.

What solutions do you use currently? Is there maybe some request forwarder for apache that works on request uris? Like: GET index.html --> served by Apache vs: GET api/something --> served by Tufao

[exec-s]

You can't do websockets with fcgi.. Am 10.10.2013 14:06 schrieb "bzeller" notifications@github.com:

Hi all,

i'm currently looking into adding SCGI support to Tufao, since i don't want Tufao to do static file serving in a production environment.

I personally would go for scgi instead of fcgi because its much easier to implement, basically just a netstring containing the headers, followed by the request body.

I thought maybe we could hijack onReadyRead in a HttpServerRequest subclass, parse the netstring and assemble a Http compatible request and forward it to the already implemented http parser.

Otoh, a scgi connector needs to worry about less things, like there will be no websocket upgrades.

What solutions do you use currently? Is there maybe some request forwarder for apache that works on request uris? Like: GET index.html --> served by Apache vs: GET api/something --> served by Tufao

— Reply to this email directly or view it on GitHubhttps://github.com/vinipsmaker/tufao/issues/19 .

[vinipsmaker]

i'm currently looking into adding SCGI support to Tufao, since i don't want Tufao to do static file serving in a production environment.

Great. =)

I thought about CGI support, but I usually take too long just to think about a good interface. For instance (maybe a bit off-topic), the current Tufão session has the cute feature of use the same interface for server-side data and client-side data, but took me some time to think about the design (and I still want to improve usability).

I thought maybe we could hijack onReadyRead in a HttpServerRequest subclass, parse the netstring and assemble a Http compatible request and forward it to the already

This would be a good start.

Maybe the code resulting from "hijacking qt socket objects" could be used in async tests (another feature that is lacking) too.

The overhead of such design could be replaced in Tufão 2.x by some design more generic.

What solutions do you use currently? Is there maybe some request forwarder for apache that works on request uris?

Apache supports reverse proxying.

Most (if not all) configuration tutorials for Node.js may work. I cited Node.js, because it's quite popular and it would be easy to find such tutorials.

[vinipsmaker]

HTTP 2.0 will be released sometime. Some thoughts:

• It will be a binary procol and it will break current parsers
  • Most significant changes are:
  • The possibility of multiplexing. This is significant because frontend developers will use less hacks to decrease the number of requests.
  • Server-sent responses to non-yet-received-requests (it will populate client cache). It works similar to instruction prediction. This feature must be exported somehow (interface).
• The semantic of the headers will remains the same.

There was an interesting talk on linux.conf.au and they provided recordings: http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/51-HTTP2.0_And_You_-_Mark_Nottingham.mp4

Why am I posting this info on this issue? Tufão will probably need a way to mock/forge/create HTTP request objects, then HTTP 2.0 and HTTP 1.x can coexist. After the refactoring, it would be easier to introduce support for Scgi/Fcgi/...

Maybe the design of this framework can help: http://libqxt.bitbucket.org/doc/