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

161–170 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#161

Post by speg »

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…

It serves sqlite.org just fine.

Most people don’t need FANG tools.

Re: Althttpd: Simple webserver in a single C file

#162

Post by tyingq »

ithkuil wrote: post #26
pjc50 wrote: 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.

Computers are insanely fast

Another comment shows 10 seconds on a relatively decent CPU from 2017. So it is a fairly heavyweight task, though I suppose could be rewritten to use more than one core.

Re: Althttpd: Simple webserver in a single C file

#163

Post by anthk »

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…

Gopher is easier than that.

Re: Althttpd: Simple webserver in a single C file

#164

Post by jhasse »

jiofih wrote: post #157
throwaway525142 wrote: post #140

Earlier quoted context omitted.

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.

No. They think having every commit build is gaining something.

You think the disadvantage (destroying history) is more important, but you can't say that it "buys you nothing".

Re: Althttpd: Simple webserver in a single C file

#165

Post by michaelmior »

mbreese wrote: post #160
michaelmior wrote: post #141

Earlier quoted context omitted.

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

That's fair. Although tools like Wireshark have made this much better.

Re: Althttpd: Simple webserver in a single C file

#166

Post by networked »

henvic wrote: 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!

Fossil has enough wiki and theming features to power a customized website and to let you edit its contents in the browser. I've joked that Fossil SCM is secretly "Fossil CMS".

My personal website, https://dbohdan.com/, is powered by Fossil. A year ago I was shopping for a wiki engine, didn't love any I looked at, and realized I could try something I was already familiar with: Fossil. It did take a few hacks to make it work how I wanted. The wiki lacks category and transclusion features and, at least for now [1], can't generate tables of contents. I've invented a simple notation for tags and generate a "tag page" [2] using a Tcl script [3]. The script runs every time I synchronize my local repository with dbohdan.com. The TOC is generated in IE11-compatible JavaScript in the reader's browser [4]. The redirects are in the Caddyfile (not in the repo). Maybe I'll migrate to a more full-featured wiki later [5], but I am enjoying this setup right now. I am happy I gave Fossil a try.

Fossil also has a built-in forum engine [6]. I am thinking of migrating a forum running on deprecated software to it.

Edit: My favorite music page and sitemap are generated on sync, too. [7] The sitemap uses Fossil's "unversioned content" feature to avoid polluting the timeline (commit history). [8]

-----

[1] In the forum thread https://fossil-scm.org/forum/forumpost/b635dc56cb?t=h DRH talks about implementing a server-side TOC.

[2] The page lists the tags and what pages are tagged with each. Tags on other pages link to their section of the tag page. https://dbohdan.com/wiki/special:tags.

[3] https://dbohdan.com/artifact/8297b54f5d

[4] https://dbohdan.com/artifact/d81bb60a0e

[5] PmWiki seems like a nice lightweight option—an order of magnitude less code than its closest competitor DokuWiki, very stable, and has a better page history view. Caveat: it is written in old school PHP. https://pmwiki.org/.

[6] https://fossil-scm.org/home/doc/trunk/www/forum.wiki

[7] https://dbohdan.com/wiki/music-links with https://dbohdan.com/artifact/053d0ff993, https://dbohdan.com/uv/sitemap.xml with https://dbohdan.com/artifact/c21444f7c9.

[8] https://fossil-scm.org/home/doc/trunk/www/unvers.wiki

Re: Althttpd: Simple webserver in a single C file

#167

Post by tyingq »

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.

Fork() on modern Linux is very fast/lightweight. This isn't true for all POSIXy operating systems though. This would perform really terribly, for example, on any Unix implementation from the early 2000s or before, and maybe on some current ones.

Re: Althttpd: Simple webserver in a single C file

#168

Post by sangnoir »

jiofih wrote: post #139
throwaway525142 wrote: post #110

Earlier quoted context omitted.

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.

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.

> Having commits that do not build represents the history more accurately.

Sure it does, but sometimes that level of detail in history is not helpful. Individual keystrokes are an even finer/"more accurate" representation of history; but who wants that? At some point, having more granular detail becomes noise - the root of the disconnect is that people have a difference in opinion on which level that is: for some (like you), it's at individual commit-level. For others (like me), it's at merge-level: inspecting individual commits is like trying to parse someone's stream-of-consciousness garbage from 2 years ago. I really don't care to know you were "fixing a typo" in a0d353 on 2019-07-15 17:43:32, but your commit is just tripping-up my git-bisect for no good reason.

Re: Althttpd: Simple webserver in a single C file

#169

Post by systems »

henvic wrote: 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!

long long long time ago Fossil destroyed code for Zed Shaw

And since that day, not one looked at Fossil the same way, at least not the same way they looked at git

https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...

I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit

Re: Althttpd: Simple webserver in a single C file

#170

Post by krferriter »

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…

And yet in years of using sqlite I have never once had a problem loading their website.
Post reply on HN