Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

101–110 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#101
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…

Recording state info in static variables makes it only suitable for embedded.

I really hate when people do that. Static should only ever be const, init once, or something intrinsically singleton. There are very few exceptions.

Re: Althttpd: Simple webserver in a single C file

#102
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…

Really simple, I implemented a couple. Remember that the letters after the status code are aesthetic, so make sure to put your style in there:

200 FINE 200 KTHX 404 MISS 403 NO 500 FUCK

Another similar server in one file is busybox httpd command if you are interested https://git.busybox.net/busybox/tree/networking/httpd.c

Re: Althttpd: Simple webserver in a single C file

#103
post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault.

Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail.

I suppose if your project is truly huge, it becomes worth it to reduce load on your VCS, but beyond that...

Re: Althttpd: Simple webserver in a single C file

#104
post #24

/* ** Test procedure for ParseRfc822Date */ void TestParseRfc822Date(void){ time_t t1, t2; for(t1=0; t1 There's only two billion integers, guess we can test them all. Well, substantially fewer than two billion with that skip. I wonder if that completes in a few seconds.

https://randomascii.wordpress.com/2014/01/27/theres-only-fou...

Re: Althttpd: Simple webserver in a single C file

#105

Earlier quoted context omitted.

Apache's thread-per-connection model used to run basically the entire internet until nginx came along and demonstrated 10k simultaneous connections on a single server. If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process

If you have 100 concurrent confections you're probably baking cookies.

To be fair, I think it would be ideal if every service would run their own 100 concurrent connections, instead of everyone using a service that handles 1 trillion.

Re: Althttpd: Simple webserver in a single C file

#107
post #50
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…

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.

Re: Althttpd: Simple webserver in a single C file

#108
post #35

> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.

So what was the point of the async/callback web programming revolution if processes were good enough?

Millions of concurrent connections. On 20 year old hardware with a small fraction of the power of today's.

Re: Althttpd: Simple webserver in a single C file

#109
post #103

Earlier quoted context omitted.

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge,…

Having full history in the feature branch is mandatory -- nobody is disputing that, myself included.

All due diligence is done there, not in the main branch.

The main branch only needs to have one big commit saying "merging PR #2169". If you need more details you'll go that PR/branch and get your info.

The "fix typo" commit being in the main branch buys you nothing. It's only useful in its separate branch.

Re: Althttpd: Simple webserver in a single C file

#110
post #103

Earlier quoted context omitted.

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge,…

Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing".

The "greater detail" part can cost me a lot of time.

Post reply on HN