[swift-server-dev] Why not rely on existing models?
yoann.gini at gmail.com
Thu Oct 27 10:22:27 CDT 2016
> Le 27 oct. 2016 à 11:11, Michael Chiu via swift-server-dev <swift-server-dev at swift.org> a écrit :
> 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…
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev