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

111–120 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#111

Post by jmaygarden »

api wrote: post #101
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…

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.

Are you thinking of C++ issues with constructors? I don’t see anything wrong with the use of static variables in this single file C program. This isn’t a library; it’s a standalone web server.

Re: Althttpd: Simple webserver in a single C file

#112

Post by emn13 »

sydthrowaway wrote: post #61
cube00 wrote: 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?

There wasn't a lot of point. Almost nobody needs this; but since everybody wants to do what the hyper-successful mega-scalers are doing...

Re: Althttpd: Simple webserver in a single C file

#113

Post by zaarn »

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.

The reason HTTP is ASCII based isn't because it's easier to debug. It's because back then the other end was as likely to be a human as a piece of software. Because HTTP in it's early days barely had headers or even formatting, so people typed "GET /" at the server directly or used the same method to send mail directly.

Nobody does that anymore and debugging is easily solved by converting your binary protocol to a textual form.

Re: Althttpd: Simple webserver in a single C file

#114

Post by layoutIfNeeded »

emn13 wrote: post #103
pdimitar wrote: post #100

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,…

I want to be able to tell why a given line of code was introduced. Seeing "Fix indentation" in the output of `git blame` won't help me with that.

Re: Althttpd: Simple webserver in a single C file

#115

Post by foxes »

Cthulhu_ wrote: post #48
foobar33333 wrote: post #14

I'd be putting this in 1000 layers of sandboxing since its a C program with network access.

Your point being? It's been serving sqlite.org just fine for all this time. You seem to be making some pretty big assumptions about security here without actually explaining what your specific concerns are.

I think the original comment is partially a joke. Maybe there isn't specifically anything wrong with this, but there is the fact that it is written in C. Historically there is a good precedent of this being an issue. C does not guarantee correctness to the same level as more modern languages.

If it was written in Haskell or Rust for example you could be more sure about correctness. I believe for something like this, correctness is fairly important. Not to mention you probably wont even lose speed. As for if the code is understandable, it is a 2600 lines of terse-ish C [0]. Do you really think about the entire blob at the same time?

[0] https://sqlite.org/althttpd/file?name=althttpd.c

Re: Althttpd: Simple webserver in a single C file

#116

Post by emn13 »

pdimitar wrote: post #109
emn13 wrote: post #103

Earlier quoted context omitted.

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.

But that's what a merge commit is - the diff along the merge commit is what the squashed commit would be; the only thing squashing does is "forget" that the second parent exists (terminology for non-git VCS's may be slightly different).

Why not merge?

Re: Althttpd: Simple webserver in a single C file

#117

Post by rkeene2 »

squiggleblaz wrote: post #28
terminalserver wrote: post #4

Interesting but why? There’s a bazillion web servers out there, surely one of them can do the job? What have I missed?

I don't know of any other well-known web server with the same featureset. For instance, it has no configuration file, it's run from xinetd statelessly/single-threaded, it runs itself in a chroot and it's short enough to be readable without specific effort. It also isn't brand new: it's been around since 2004. So that probably narrows the range of possible competitors even more. If you can find a webserver that meets…

filed [0] is written to be readable, and stateless, and runs from a chroot, and has no configuration file. It doesn't run from xinetd and it's multi-threaded, though.

I wrote it because no other web server could serve files fast enough on my system (not lighttpd, not nginx, not Apache httpd, not thttpd) to keep movies from buffering.

[0] https://filed.rkeene.org/

Re: Althttpd: Simple webserver in a single C file

#119

Post by emn13 »

throwaway525142 wrote: post #110
emn13 wrote: post #103

Earlier quoted context omitted.

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.

ideally your branch commits would usually build too; but admittedly, I tend to bisect by hand, following the --first-parent. I suppose if the set of commits were truly huge that might be more of an issue. And of course, there are people that have hacked their way to success here: https://stackoverflow.com/a/5652323, but that sounds a little fragile.
Post reply on HN