Why not rely on existing models?


#1

I think a stand alone http parser is still necessary, simply because it is a fundamental building block for most web frameworks nowadays.
1. Compatibility
I’m not sure about other people, but when I write a web framework I will assume people who use my framework are not necessary have nginx and apache installed. And someone eventually, like I did, will probably want to build a fronted web server as well, in that case, having a standalone will make things a lot easier.
2. Reverse-Proxy
Some applications are using frontend server such nginx as a reverse-proxy server and proxy over unix domain socket (for example, node.js). In that case, even with a frontend web server, a http parser is still necessary.
3. Optimization
If someone eventually written a web framework that are subject to use within a private network only, let’s say a computational hub, and somehow they decide to use HTTP, totally rely on frontend server will make a lot of optimization impossible.
For example the sendfile() system call. If an application has the ability to generate http header, it can easily optimize the performance of the server when serving file-related-content by using sendfile(), or TCP_CORK + sendfile() in linux, and also a lot of TCP related optimization. This just cannot done by using a frontend server.
Michael

This trend seems to have started with Rails. It has a few advantages:

1. You can use the embedded server in development and testing. This is *way* easier than installing Apache on your development machine or CI setup and configuring it to point to your application.

100% agree with that

2. In production, you can configure Apache or nginx to reverse proxy for the app; this configuration is almost entirely agnostic to the application itself, so you can modify the application's behavior without playing with the frontend web server.

3. The frontend proxy and backend web server communicate over a plain old socket, so they can run as different user accounts or even in separate VMs.

Basically, embedding a web server and reverse proxying for it isolates the application from the frontend server and simplifies the management of both.

I’m not really sure this is a pros or cons. Having to run multiple processes and use sockets increase code complexity and surface for attacks. It increase the number of services started so the number of processes to watch.

In some scenario, this is better, in some others, this is worst.

As I’ve said on my first e-mail, I don’t say standalone swift HTTP server must not exist. I’ve just said it could be interesting to think about others patterns.

Allowing behavior like WSGI where you can use both scenario is IMHO the best solution ever, so it can fit for all needs.

Best regards,
Yoann Gini

···

Le 26 oct. 2016 à 10:59, Brent Royal-Gordon <brent at architechies.com <https://lists.swift.org/mailman/listinfo/swift-server-dev>> a écrit :


(Yoann Gini) #2

Hi

I think a stand alone http parser is still necessary, simply because it is a fundamental building block for most web frameworks nowadays.
1. Compatibility
I’m not sure about other people, but when I write a web framework I will assume people who use my framework are not necessary have nginx and apache installed. And someone eventually, like I did, will probably want to build a fronted web server as well, in that case, having a standalone will make things a lot easier.

That’s why I advocating for a dual scenario like WSGI. In some scenario you want something autonomous.

2. Reverse-Proxy
Some applications are using frontend server such nginx as a reverse-proxy server and proxy over unix domain socket (for example, node.js). In that case, even with a frontend web server, a http parser is still necessary.

From a performance point of view it might be more interesting to avoid reverse proxy behavior and use modules. It avoid increasing the number of open files, the RAM used, etc. I know it’s trendy nowadays to waste resources but swift on the server side can bring new capabilities to software developers and extend server usage on SMB market, for example.

If we can avoid, by design, to waste the few resources SMB has, it could be great.

3. Optimization
If someone eventually written a web framework that are subject to use within a private network only, let’s say a computational hub, and somehow they decide to use HTTP, totally rely on frontend server will make a lot of optimization impossible.
For example the sendfile() system call. If an application has the ability to generate http header, it can easily optimize the performance of the server when serving file-related-content by using sendfile(), or TCP_CORK + sendfile() in linux, and also a lot of TCP related optimization. This just cannot done by using a frontend server.

Pretending to be able to get better static content performance than engines require a lot of self-confidence…

And in all this talk we're missing one major point of my initial comments: security. New HTTP parser implementation automatically means brand new security breaches and related work to find them and fix them…

Best regards,
Yoann Gini

···

Le 27 oct. 2016 à 11:11, Michael Chiu via swift-server-dev <swift-server-dev@swift.org> a écrit :