4 ms·

It's tempting to consider using an http server in your program. But also consider wrapping your c/c++ programs in fastcgi loop and have nginx run behind it. It

It's tempting to consider using an http server in your program. But also consider wrapping your c/c++ programs in fastcgi loop and have nginx run behind it. It removes a lot of complexity from your code.

CapacitorSet 9y ago
>It removes a lot of complexity from your code. Not to mention, Nginx implements quite a lot of features that are probably missing in LibHTTP, or implements them in a more performant way.
- halayli 9y ago
  yep, more secure, and battle tested. And one additional subtle advantage is that it leads you to make better architectural decisions because it eliminates state.
emmelaich 9y ago
Surely this is just an added feature to a existing program. Having it inbuilt is useful for testing. Also not sure whether doing a fastcgi loop and requiring another http server to frontend it really is simpler!
- halayli 9y ago
  try embedding a web server inside your program and have it manage threads, event loops, and not be vulnerable to security attacks and compare it with a simpe nginx config pointing to your application and you’ll get an idea which one is simpler. not to mention you’ll need to get around all the quirks of whatever lib u use, learn its api, and deal with platform compat.
  - emmelaich 9y ago
    An embedded web server typically doesn't have to be very performant. It's just for convenient runtime access to the programs innards. In fact in some cases it may only accept one client at a time.
ythn 9y ago
Are there any supported fastcgi libraries these days? It seems like the official C/C++ one (fastcgi.com) disappeared from the internet.
- cjhanks 9y ago
  I tried to write one a while back, I haven't needed it for a while. https://github.com/cjhanks/libSimpleCGI https://github.com/cjhanks/libSimpleCGI
deleted 9y ago
[deleted]
frankzinger 9y ago
Or simply talk to nginx in HTTP. Here's Glyph of Twisted's take on it (in a nutshell: why convert HTTP into an HTTP-like protocol which is neither as well-standardised nor as well-documented?) : https://twistedmatrix.com/pipermail/twisted-web/2006-April/002598.html https://twistedmatrix.com/pipermail/twisted-web/2006-April/0... You could use a very stripped-down and thus potentially very efficient HTTP parser given that most of the work will be offloaded to nginx. Also, last time I checked, nginx didn't support request multiplexing/pipelining over FastCGI (as it does over HTTP). Instead, each HTTP request received by nginx would result in a new (FastCGI) connection to your application which is obviously suboptimal.
- deathanatos 9y ago
  > why convert HTTP into an HTTP-like protocol which is neither as well-standardised nor as well-documented? I have these same feelings every time I see uWSGI being used.
  - icebraining 9y ago
    The protocol is uwsgi, whereas uWSGI is the application, which doesn't have to use uwsgi :D
    - claviola 9y ago
      I think you mean WSGI is the protocol.
      - dfox 9y ago
        WSGI is the python-level API between web server and your application. uwsgi is one implementation of that which also has it's own network protocol (also called uwsgi)
jasode 9y ago
>nginx run behind it. It removes a lot of complexity from your code. There are good intentions with that advice but I think it's misleading. It doesn't take into account how http libraries like this one (and similar ones for C++ such as Proxygen[1] and Silicon[2]) are supposed to be used. The intended use case is to add an embedded webserver to your executable that's communicating with friendly and internal systems. That would be things like microservices and dashboards. You don't use those libraries to create external public-facing websites that would be under attack from hostile agents. You're correct: Do not re-invent NGINX by using the C http library. As an example proper use case, let's say you write an internal C program to process terabytes of image files. You think it might be nice to have a visual status of its progress/errors/throughput/etc. Instead of adding a GTK GUI to the code, you use the http library to expose a "web dashboard". You can then point an employee browser on the internal network at it to see its progress. For this use case, avoiding the http library and adding NGINX into the stack makes it more complicated. Another use case without HTML gui is exposing http endpoints for microservices. Again, it's internal communication between friendly agents. tldr: http libraries that are compiled into executables vs NGINX are for different use cases. [1] https://github.com/facebook/proxygen https://github.com/facebook/proxygen [2] http://siliconframework.org/ http://siliconframework.org/
- gtcode 9y ago
  Your described use case for a "friendly / internal" system has a limited definition in any non-trivial sized organization. It would only apply when all users of the embedded webserver already have root access to that server. This might make sense, for instance, in a small development team with a flat security hierarchy, but would be a red flag, security wise, otherwise.
  - jasode 9y ago
    >Your described use case for a "friendly / internal" system has a limited definition in any non-trivial sized organization. Facebook is a non-trivial size company that has lots of internal private-facing programs with embedded http connectivity. From that experience, they open sourced Proxygen http library which is one of the links I mentioned in the previous comment. Also, see the comment from VikingCoder which in turn links to reddit thread mentioning another big company like Google doing similar use cases with http libraries: https://news.ycombinator.com/item?id=15671936 https://news.ycombinator.com/item?id=15671936

CapacitorSet 9y ago

>It removes a lot of complexity from your code. Not to mention, Nginx implements quite a lot of features that are probably missing in LibHTTP, or implements them in a more performant way.

halayli 9y ago
yep, more secure, and battle tested. And one additional subtle advantage is that it leads you to make better architectural decisions because it eliminates state.

emmelaich 9y ago

Surely this is just an added feature to a existing program. Having it inbuilt is useful for testing. Also not sure whether doing a fastcgi loop and requiring another http server to frontend it really is simpler!

halayli 9y ago
try embedding a web server inside your program and have it manage threads, event loops, and not be vulnerable to security attacks and compare it with a simpe nginx config pointing to your application and you’ll get an idea which one is simpler. not to mention you’ll need to get around all the quirks of whatever lib u use, learn its api, and deal with platform compat.
- emmelaich 9y ago
  An embedded web server typically doesn't have to be very performant. It's just for convenient runtime access to the programs innards. In fact in some cases it may only accept one client at a time.

ythn 9y ago

Are there any supported fastcgi libraries these days? It seems like the official C/C++ one (fastcgi.com) disappeared from the internet.

cjhanks 9y ago
I tried to write one a while back, I haven't needed it for a while. https://github.com/cjhanks/libSimpleCGI https://github.com/cjhanks/libSimpleCGI

deleted 9y ago

[deleted]

frankzinger 9y ago

Or simply talk to nginx in HTTP. Here's Glyph of Twisted's take on it (in a nutshell: why convert HTTP into an HTTP-like protocol which is neither as well-standardised nor as well-documented?) : https://twistedmatrix.com/pipermail/twisted-web/2006-April/002598.html https://twistedmatrix.com/pipermail/twisted-web/2006-April/0... You could use a very stripped-down and thus potentially very efficient HTTP parser given that most of the work will be offloaded to nginx. Also, last time I checked, nginx didn't support request multiplexing/pipelining over FastCGI (as it does over HTTP). Instead, each HTTP request received by nginx would result in a new (FastCGI) connection to your application which is obviously suboptimal.

deathanatos 9y ago
> why convert HTTP into an HTTP-like protocol which is neither as well-standardised nor as well-documented? I have these same feelings every time I see uWSGI being used.
- icebraining 9y ago
  The protocol is uwsgi, whereas uWSGI is the application, which doesn't have to use uwsgi :D
  - claviola 9y ago
    I think you mean WSGI is the protocol.
    - dfox 9y ago
      WSGI is the python-level API between web server and your application. uwsgi is one implementation of that which also has it's own network protocol (also called uwsgi)

jasode 9y ago

>nginx run behind it. It removes a lot of complexity from your code. There are good intentions with that advice but I think it's misleading. It doesn't take into account how http libraries like this one (and similar ones for C++ such as Proxygen[1] and Silicon[2]) are supposed to be used. The intended use case is to add an embedded webserver to your executable that's communicating with friendly and internal systems. That would be things like microservices and dashboards. You don't use those libraries to create external public-facing websites that would be under attack from hostile agents. You're correct: Do not re-invent NGINX by using the C http library. As an example proper use case, let's say you write an internal C program to process terabytes of image files. You think it might be nice to have a visual status of its progress/errors/throughput/etc. Instead of adding a GTK GUI to the code, you use the http library to expose a "web dashboard". You can then point an employee browser on the internal network at it to see its progress. For this use case, avoiding the http library and adding NGINX into the stack makes it more complicated. Another use case without HTML gui is exposing http endpoints for microservices. Again, it's internal communication between friendly agents. tldr: http libraries that are compiled into executables vs NGINX are for different use cases. [1] https://github.com/facebook/proxygen https://github.com/facebook/proxygen [2] http://siliconframework.org/ http://siliconframework.org/

gtcode 9y ago
Your described use case for a "friendly / internal" system has a limited definition in any non-trivial sized organization. It would only apply when all users of the embedded webserver already have root access to that server. This might make sense, for instance, in a small development team with a flat security hierarchy, but would be a red flag, security wise, otherwise.
- jasode 9y ago
  >Your described use case for a "friendly / internal" system has a limited definition in any non-trivial sized organization. Facebook is a non-trivial size company that has lots of internal private-facing programs with embedded http connectivity. From that experience, they open sourced Proxygen http library which is one of the links I mentioned in the previous comment. Also, see the comment from VikingCoder which in turn links to reddit thread mentioning another big company like Google doing similar use cases with http libraries: https://news.ycombinator.com/item?id=15671936 https://news.ycombinator.com/item?id=15671936