<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 27 oct. 2016 à 11:11, Michael Chiu via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">I think a stand alone http parser is still necessary, simply because it is a fundamental building block for most web frameworks nowadays.</pre><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">1. Compatibility </pre><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">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.</pre></div></blockquote>That’s why I advocating for a dual scenario like WSGI. In some scenario you want something autonomous.<br class=""><blockquote type="cite" class=""><div class=""><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">2. Reverse-Proxy</pre><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">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.</pre></div></blockquote>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.</div><div><br class=""></div><div>If we can avoid, by design, to waste the few resources SMB has, it could be great.<br class=""><blockquote type="cite" class=""><div class=""><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">3. Optimization</pre><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">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. </pre><pre class="" style="font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255);">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.</pre></div></blockquote>Pretending to be able to get better static content performance than engines require a lot of self-confidence…</div><div><br class=""></div><div>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…</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Best regards,</div><div class="">Yoann Gini</div></div>
</div>
<br class=""></div></body></html>