Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

151–160 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#151

Post by tyingq »

geocrasher wrote: post #146

I have yet to try running this for anything, but I do appreciate how it really sticks to the "do one thing well" ethos. Modern web servers can be extremely complicated with a lot of moving parts. This boils it down to just one thing and lets a person focus on the project instead of the infrastructure. Granted, it's very simplistic, but that's its strength.

I do respect the technical chops around sqlite. However, I think a "fork for every single http request" server isn't really useful in many situations.

That the sqlite website is able to run this way is more a testament to Linux's work on a lightweight/fast fork() than anything else. This would perform terribly on a more traditional Unix.

Re: Althttpd: Simple webserver in a single C file

#153

Post by Iwan-Zotow »

daitangio wrote: post #107
lmilcin wrote: post #50

Earlier quoted context omitted.

Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes. The issue is that many (especially scripting) languages treat binary data as second class. The only real issue is that inspecting the binary message visually is little b…

Yes and no. Debugging a binary protocol is a bit more difficult then a text one; which is the reason HTTP is ascii based.

> which is the reason HTTP is ascii based.

well, other side of HTTP was telnet in the terminal - this is why it is ASCII to begin with

Re: Althttpd: Simple webserver in a single C file

#154

Post by pjc50 »

chrismorgan wrote: post #68
lmilcin wrote: post #50

Earlier quoted context omitted.

Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes. The issue is that many (especially scripting) languages treat binary data as second class. The only real issue is that inspecting the binary message visually is little b…

And capitalisation issues, and encodings… give me a binary protocol to parse any time. They’re normally comparatively well-defined, whereas text protocols are seldom properly defined and so have undefined behaviour left, right and centre, which inevitably leads to security bugs—or even if they are well-defined, they’re probably done in a way that makes your language’s string type unsuitable, and makes parsing more co…

People say this, but then there's ASN.1 which has had critical security bugs in: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=asn.1

I will agree that exhaustively defining text protocols is extremely hard, starting from character set / encoding and getting worse from there.

Re: Althttpd: Simple webserver in a single C file

#156

Post by slver »

ktpsns wrote: post #2

Here is the actual single C-code file: https://sqlite.org/althttpd/file?name=althttpd.c Something I absolutely love about text based protocols such as HTTP/1 is how easy you can implement it in any virtually programming language. Sure, the implementation is not top-of-the-notch, but it just damned works, it is portable, it is understandable by humans. That's something what's got lost with HTTP/2 and HTTP/3, respectiv…

It's not a property of text-based protocols, rather it's a property of simple protocols. HTTP/1 is not merely text based, it's ASCII based (technically ISO-8859-1, which includes ASCII). One char, one byte, one encoding. HTTP itself is mostly very simple, text "name: value" pairs separated by newlines, followed by arbitrary content as the body.

I think the solution is to start with a simple protocol and upgrade to more complex protocols after that. While technically you don't need to support HTTP/1 to support 2 and 3, the upgrade over TCP happens mostly in that way.

Re: Althttpd: Simple webserver in a single C file

#157

Post by jiofih »

throwaway525142 wrote: post #140
jiofih wrote: post #139

Earlier quoted context omitted.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

You're not saying anything new as far as I can tell. Your grandparent already said what you said. I only disputed the "this costs next to nothing" part, which you don't seem to comment on.

I was commenting exactly on that. You think having every commit build, at the cost of destroying history, is gaining something.

I think representing history correctly is best, and agree that “squashing buys you next to nothing” other than visually pleasant output. Clearer?

My favorite approach is rebase + non-ff merge. Best of both worlds.

Re: Althttpd: Simple webserver in a single C file

#158

Post by dmux »

ankurpatel wrote: post #150

Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…

>but if plan is to use it for HTTP server to serve production web traffic performance is really bad.

But it seems to be "good enough", no? As stated on the page, it serves 500k requests a day.

Were you running your tests using xinetd or stunnel?

Re: Althttpd: Simple webserver in a single C file

#159

Post by SQLite »

ankurpatel wrote: post #150

Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…

Indeed. And a Citation biz-jet is way faster, flies higher, goes further, and carries more passengers than a Carbon Cub. On the other hand, the Citation costs more, burns more gas, takes more maintenance, and is more complex to fly, and you should not try to land a Citation on a sandbar in a remote Alaskan river.

Choose the right tool for the job.

Changing the https://sqlite.org/ website to run off of Nginx or Apache instead of alhttpd would just increase the time I spend on administration and configuration auditing.

Re: Althttpd: Simple webserver in a single C file

#160

Post by mbreese »

michaelmior wrote: post #141
mbreese wrote: post #70

Earlier quoted context omitted.

The use of text for popular protocols is for a reason — computers don’t write programs, people do. And while CPUs prefer binary, it’s easier for programmers to read/write/reason about text. This makes it easier to work with a new protocol. From a practical perspective, with a binary protocol, it can be difficult to use across different languages or add support for a new language. If you use the simplest possible enco…

Except it quickly gets messy when you start dealing with real data and making sure encoding and escaping is done correctly. > with a binary protocol, it can be difficult to use across different languages This is also true of text protocols that aren't well-designed. I don't think it's necessarily the case that binary protocols are more difficult to deal with. You just have a different set of concerns to address. > If…

> I don't think it's really any more difficult to write a simple protocol that uses binary data compared to text.

I don’t really think so either… I mean, I’ve done both and it’s really not terrible to use binary. I think text is marginally easier to parse, but once to have the routines to read the right endian-ness, the advantage is minor. As you said, the biggest concern (as always) should be the design. A good design can be implemented easily with either mode.

However, it is significantly easier to debug a text protocol. Attaching a monitor or capturing packets is easier with text as the parsers are much easier and more generic.

Post reply on HN