Building a Website with C++
blog.sourcerer.io
blog.sourcerer.io
cout << "<body>\n";
...
cout << getenv("QUERY_STRING");
cout << "</body>\n";
Followup: http://www.oilshell.org/blog/2017/09/29.html
Also if you want to use a native language for web sites (which I don't), Go is a better choice, as the standard library has html/template which protects you from naive injections:
I'm not sure about the "chock full of potential security issues". You have to be careful with trusting environment variables as the Bash guys learned, but I don't know what else there is that is specific to CGI.
Slashdot used apache mod_perl back then. It never forked a process per request.
Edit: Seems I was wrong about the date, it was actually 28-Jul-1997[1], nevertheless slashdot was only launched two months later, and as the link above witnesses didn't seem to have used it at first.
[1]: https://web.archive.org/web/19971210053529/http://perl.apach...
https://en.wikipedia.org/wiki/FastCGI
Also: DOS attacks against capacity sound positively benign compared to what they translate to on cloud : DOS on your credit card.
I dont find any reasons at all. That article ist just a clickbait nonsens.
We can just "flag" articles like this one.
In my case, I just prefer coding in that language over PHP et al. It's on a $2.50/mo VPS and I can spawn a new instance in five minutes if need be. Every memory access (for strings, vectors, etc) go through containers with bounds checking. The server/webapp itself runs as its own unprivileged user. If the server crashes, it'll stay offline and give me a core dump, which should let me find and fix the bug in my library.
The code's open, too: https://gitlab.com/higan/higan/blob/master/nall/http/server....
It's certainly not 100% perfect security, but what really is? Between Heartbleed, Meltdown, Spectre, weekly Wordpress exploits, etc ... I don't think the risk is particularly higher.
(aside: the forum runs on PHP on another VPS instance; separation of security concerns.)
It's fun. We learn and better ourselves by making mistakes. My idols are the folks breaking through the security of the Switch et al. They had to learn somewhere: by doing things everyone else told them not to.
Don't worry, I would never use this stuff in production at a company.
It’s super simple UI to start an instance with a basic script (like update distro and developer tools etc). Lastly, you can pass in your pub keys and just ssh directly without doing it yourself the moment you log in for the first time.
All in all highly recommend it!
Remarking on that, Digital Ocean is nothing special, but they have added some nice features in the past year or two. I like that their control panel supports multiple teams with permissions, I like that it has a nice tag-based firewall, the DNS service works fine, and it has an S3 clone called Spaces which is pretty handy. I believe they also announced recently that private networking would be isolated per-team instead of being the entire data center, another networking improvement that most low-end VPSes do not provide.
All in all, if you just need a low end VPS, I would say there's no fault in going with something like Vultr, but Digital Ocean adds a few extra features that might be more useful if you're developing a medium-complexity system. Of course though, at that point, you probably want to at least consider Google Cloud Platform, a reasonably cost-effective host with very rich features. (And AWS, but my feelings for AWS have shrunk in recent times after having better experiences with GCP consistently at my day job.)
In an absolute emergency, their GUI portal will let you log in as root via password.
Pretty great. Infinitely better than anyone else I've ever used (especially InMotion Hosting that corrupted my SQL database, and misconfigured Apache to return my PHP source code to every visitor.) Not perfect, but very reliable uptimes.
If I had to nitpick:
The New Jersey instance lost the ability to reach it over IPv6. Their support staff wanted root access to my box to take a look. Nice that they were willing to do that, but I just moved to Chicago instead. IPv6 with the exact same configuration works fine there.
Their two-factor authentication does not allow SMS as a backup option. I don't like printing out codes.
Like everyone else, their bandwidth scaling is really poor. You have to scale up your entire server, even if you really don't need the CPU, memory or disk space. The price increases quadratitically while the bandwidth increases linearly.
You have to e-mail them your driver's license or something to enable SMTP. I think their fine print says they'll fine you $250 for every spam mail you send or something scary like that.
...Wow. The other stuff is par for the course really, but that sounds, a bit insane.
On the other hand, I assume (hope?) they just mean port 25 stuff, not encrypted SMTP...
While plain CGI is a slower, the advantage is that you don't have long running and potentially idle processes for low traffic periods, and process isolation is a little security boost.
I chose to have a slightly slower startup time, which hopefully remain constant in a load balanced cluster, to gain the advantages above.
I would even expect that you can write non-trivial CGI application whose startup time is smaller than the additional overhead from parsing of the FastCGI protocol.
Casablanca, but I'm not sure how active is the project nowadays.
I am still unsure if its satire or not.
I am personally a big fan of CROW [2] and have used it many times in the past.
[1] https://softwareengineering.stackexchange.com/questions/5362... [2] https://github.com/ipkn/crow/blob/master/README.md
See this 7 year old message by Richard Hipp (of sqlite):
https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
https://news.ycombinator.com/item?id=3036124
This server takes over a quarter million requests per day, 10GB of traffic/day, and it does so using less than 3% of of the CPU on a virtual machine that is a 1/20th slice of a real server.
I only saw one reason: performance. Did I miss some? Do people have other good use cases that justify paying the dev cost of using C++ for a web server? I'd guess with caching and a decent backend, it would be fairly hard to demonstrate a true need for performance that requires C++, but I'm sure there are a few demanding applications out there that need it.
Since a web page's throughput is usually network bottlenecked and not CPU bound, I'm curious (just for fun) what the max possible performance benefit of going C++ is, especially behind a CGI interface?
There's probably a small latency benefit at all times, and I'd guess there's a throughput benefit that is only visible if you're doing more than a few thousand requests per second..?
Preferably one would use some kind of network protocol with a native management console, but nowadays it is fashionable to have a mini webserver exposing a Web UI instead.
I did? I just read the article again, and I don't see any mention of IOT or small or embedded devices aside from Docker, can you point me to what you saw? The article is assuming Apache is running...
> Do people have other good use cases that justify paying the dev cost of using C++ for a web server?
What makes you say that? The modern routers I've used all run a full embedded Linux like BusyBox, and they have no need for compiled high performance panels. It'd be more expensive and less portable to write the admin panel in C++, and I can't really think of any strong benefits that would make it worth using C++. I would have assumed they run a scripting language. But I'm checking some of the OS projects now instead of assuming.
Poking around, I see that Tomato is a busybox distribution, all the Linux tools including httpd are C (not C++), and the admin panal pages are .asp (written in VBScript).
DD-wrt appears to have PHP admin panels.
Looks like Asuswrt-Merlin uses .asp.
M0n0wall is all php.
Let me know if you find one with admin panels in C++, I'm interested.
This isn't even counting the dev time difference
Can you quantify & explain what you mean by notable? I've written a lot of C++ and also a lot of scripted web services like node.js and flask (python). For most normal websites, I doubt that you could make significant and noticeable performance improvements to a decent scripted backend by switching to c++, from the user's point of view. A latency savings of a millisecond or two across the board I could buy, but making it obviously faster to a user, I'm skeptical, unless the site has non-traditional high performance requirements.
You can see that that was precisely my question, right? Did you mean to reply to the parent comment? The article says the reason to use C++ over rails or node or another scripting language is "performance", the parent comment to mine said that the performance difference would be "notable". I'm asking exactly what you're asking -- what is performance, what is notable?
On top of that, I did define performance loosely in my comment -- as something that is noticeably faster to the user. If a user running Chrome can feel the difference on a site, and the only difference is the language it was written in, then I could buy that C++ gives better "performance". I suspect it's rather difficult to write a custom C++ web server and make it load or run any faster, from the point of view of the person on the other end, than a generic rails/flask/nodejs web site, for most sites.
you know, there might be MORE THAN ONE user
so if server is done in, say, python, then user #11 will get slowdown. With C++, slowdown might start with user #50 (or 100, or ...)
For typical large OO codebase some kind of tracing GC is almost always better than various reference counting and tracking schemes. For the unpredictability the problem has to do with the fact that even simplest C++ statement might cause the compiler to generate several kilobytes of inlined code.
> various reference counting and tracking schemes.
Reference counting doesn't always have repeatable performance.
Maybe for a program image started from scratch on exactly the same non-real-time input. But then almost anything has repeatable performance for that, including ordinary mark-and-sweep garbage collection.
My other point was that for anything other you do not want to use C++.
Edit: and also "when used in certain ways" is exactly the problem with C++ I tried to point out. The language and it's interactions with real implementations is simply too complex for any kind of useful analysis.
No "would" about it C++ web sites are real and have been around for a long time. I'm thinking of sites running on Windows using "ISAPI".
https://github.com/Qihoo360/evpp - network library for developing high performance network services in TCP/UDP/HTTP protocols
https://github.com/rep-movsd/see-phit - C++ HTML template engine that uses compile time HTML parsing
https://github.com/boostorg/beast - HTTP and WebSocket built on Boost.Asio in C++11
https://github.com/emweb/wt - Wt, C++ Web Toolkit
(for implementing an RFC 3161 (crypto timestamp) service.
It's a fork of https://github.com/cesanta/mongoose
(The Civetweb fork exists due to Mongoose license switch from MIT to GPLv2)
Go is rather performant and in contrast to C++ memory safe.
C++ is a language that can be used like a sawed-off shotgun propped against a developer's foot, and with a hair trigger. Granted, it does not _have_ to be used this way, but it can be.
A good developer can be "safe by default" and can use profile-directed optimization to speed up areas that are performance critical. A great developer can build proofs that such performance improvements maintain safety guarantees. For the average developer, following modern C++ development practices creates code on par with other languages in terms of both safety and performance.
For most languages, a lot can be done in terms of optimization, profiling, and security. Even in higher-level languages, an FFI is available to rewrite critical portions of code in a lower level language for performance improvements. Careful attention to detail can provide critical performance improvements in any language without compromising on safety. Getting there requires model checking or formal methods, but that is also becoming more of a part of modern development practices.
This is not specific to C++, but it is worse in C and C++ given the nature of these languages.
It also doesn't help that management even cares less about QA than those devs.
Rust is essentially a bet on the impossibility of working around that trade-off in C++. And they are right, it is impossible to close that gap completely. C++ simply doesn't have the language features to enforce all necessary ownership rules without a performance penalty.
But I see trouble on the horizon for Rust, because that gap is quickly shrinking to its formally irreducible minimum as more C++ libraries are adopting a "modern" style. What's left of that gap may be too small to fit an entire new programming language built around fixing this single issue.
Memory management in Rust is so dominant in terms of syntax and in terms of restrictions imposed on common idioms that it must be either embraced or rejected wholeheartedly.
This is just my personal opinion obviously, not any sort of truth or prediction.
I feel that way myself now, but figured that I was just too close to have a mainstream opinion about it :)
I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
edit: edited the link
Go is slower than C++.
C has very low startup time compare to say Java. And process fork-exec isn't as heavy weight under Linux as in Windows.
Oh come on, C++ is a systems programming language and certainly can handle this, so “futility” seems over the top. Hell, you can write cgi handlers in assembly.
Around 94 I wrote Cygnus’ web interface (and then cron job too) to our big system in sh. Sure, I wouldn’t make the same choice today, but it’s hardly absurd.
CGI in 2018 seems a bit passé...
well, at least in terms of not keeping the server process up all the time, only when it's used.
To combine "only running when necessary" and "not restarting for every request when there's a lot of requests", I made a thing: https://github.com/myfreeweb/soad — little wrapper listens on a socket, spawns your server with the socket passed in, terminates the server when there were no new connections in a while, rinse, repeat.
Or perhaps you might want to use a belt sander to refinish your table without removing the tablecloth from the table first. Not all the things one “might want to do” are good ideas, even if there’s a wikihow on best ways to do them.
C++ is a great language but it’s a very hard language to wield correctly. The odds there is an exploitable buffer overflow or injection attack buried deep in some part of the code are simply too high compared to memory managed languages with standard libraries designed from the ground up for web-facing applications.
There is almost literally no chance that this is the case. The amount of pointless boilerplate code that you'd have to write would be many, many, many times in excess of a thin API layer.
There may be some advantages to writing a middle tier application server in either of these languages, but using a system language to manage a web front-end is effectively like using a hatchet to shave. Sure, the hatchet is faster at cutting wood than a safety razor, and if one is careful, it could be used to remove stubble, but chances are that one is not clearly thinking about the problem at hand to suggest such a tool.
There aren't many options when you just have a few hundred KB.
Modern C++ has a lot of great stuff to help, but the sense of safety you get when you use Rust is something else entirely.
Languages are not panaceas. Rust and D are both hard languages, as is C++. Selecting one of these only makes sense if the application warrants it. Each have advantages and disadvantages. I don't really think any of them are suited to web development, but claiming that D or Rust would be a more productive web development language than C++ seems equally silly to seriously considering C++ as a web development language.
Because D is very obviously C++ but better. Rust isn't, though. But D, down to the very name, has lots of things that appeal to C++ users. It has advanced metaprogramming, is multiparadigm, it compiles down to machine code, and has very similar syntax to C++.
D has had other influences, but it is written by C++ compiler writers who think they can do better than C++. I say this as someone raised on C++ and who is now trying D. It is a very natural progression to make, if you're inclined to try something new.
Furthermore, Vibe.d is kind of a burgeoning "killer app" for D. D's package manager, for example, was originally made for Vibe.d. This isn't the only way in which Vibe.d has influenced D development. Vibe.d is one of the most popular D libraries. It's the only D library I know that has its own published book,
https://dlang.org/blog/2017/09/13/the-making-of-d-web-develo...