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

271–280 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#271

Post by SQLite »

0xbadcafebee wrote: post #135

> As of 2018, the althttpd instance for sqlite.org answers about 500,000 HTTP requests per day (about 5 or 6 per second) delivering about 50GB of content per day (about 4.6 megabits/second) on a $40/month Linode. The load average on this machine normally stays around 0.1 or 0.2 Interesting. If the load avg is consistently low, it could mean they're over-paying for CPU. If this was a non-dedicated AWS instance you mig…

Linode doesn't follow the cafeteria pricing style. You buy a package. $40/month is the minimum for us to get the disk space and I/O bandwidth we need. We could get by with less CPU, perhaps, but the extra memory and extra cores do reduce latency and they are nice to have on days when SQLite is a top story at HN. (Load avg has been running at about 0.95% all day today.)

Re: Althttpd: Simple webserver in a single C file

#272

Post by gallier2 »

ectospheno wrote: post #261
spacechild1 wrote: post #260

Earlier quoted context omitted.

> Sure enough, the function StrAppend potentially overflows a size_t size How should this happen in practice? The three strings would have to be larger than the available address space...

Yeah. The function in question is called in only one place. It would seem you’d need to send the web server more than a size_t of data for this to be an issue.

In most places it uses int for string and buffer sizes lengths. It wouldn't surprize me if 2GiB of data could trigger several overflows.

Re: Althttpd: Simple webserver in a single C file

#273

Post by taejo »

jrockway wrote: post #250
scruple wrote: post #227

Earlier quoted context omitted.

> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.

I think it's pretty easy to make poor use of HTTP to the same end. Imagine you're dumping traffic between a client and a server and the exchange is: GET /asdfasdfasdfdsaf X-Asdf-Asdf: 83e7234 HTTP/1.0 202 X-83e7233: 1 X-83f730b: 4 It's text, but you still have no idea what's going on. Overall, I think it's kind of a wash. It's basically equally easy to take a documented text or binary protocol and write a working par…

> Still not sure how to send an email that consists of a single dot on its own line though.

A line starting with a period is escaped by adding an extra period; the receiving side removes the first character of a line if it is a period.

Re: Althttpd: Simple webserver in a single C file

#274

Post by admax88q »

pjc50 wrote: post #154
chrismorgan wrote: post #68

Earlier quoted context omitted.

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.

I guess if you're going to pick the absolute worst example of a binary protocol.

Re: Althttpd: Simple webserver in a single C file

#275

Post by knome »

jrockway wrote: post #250
scruple wrote: post #227

Earlier quoted context omitted.

> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.

I think it's pretty easy to make poor use of HTTP to the same end. Imagine you're dumping traffic between a client and a server and the exchange is: GET /asdfasdfasdfdsaf X-Asdf-Asdf: 83e7234 HTTP/1.0 202 X-83e7233: 1 X-83f730b: 4 It's text, but you still have no idea what's going on. Overall, I think it's kind of a wash. It's basically equally easy to take a documented text or binary protocol and write a working par…

>Still not sure how to send an email that consists of a single dot on its own line though.

It seems you prefix any line of data starting with a period with an additional period, to therefore distinguish it from the end of mail period.

https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2

Re: Althttpd: Simple webserver in a single C file

#276

Post by e12e »

rkeene2 wrote: post #253
e12e wrote: post #243

Earlier quoted context omitted.

> 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. Could you expand on that? What type of files, how many clients? I seem to recall plain apache2 from spinning rust streaming fine to vlc over lan - but last time I did that was before HD was much of a thing... Now I seem to stream 4k hdr over ZeroTie…

You might want to try filed ! This was for serving MPEG4-TS files with, IIRC, H.264 video and MPEG-III audio streams -- nothing fancy -- from a server running a container living on a disk attached via USB/1.1. While USB/1.1 has enough bandwidth to stream the video, the other HTTP servers were too slow with Range requests, because they would do things like wait for logs to complete and open the file to serve (which is…

> a server running a container living on a disk attached via USB/1.1.

Ah, ok. That makes sense. USB 1.1 can certainly challenge cache layers and software assumptions.

I do wonder how far apache2 might have been pushed, dropping logs and adjusting proxy/cache settings.

Re: Althttpd: Simple webserver in a single C file

#278

Post by pdimitar »

skeeter2020 wrote: post #228
pdimitar wrote: post #109

Earlier quoted context omitted.

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.

This is fine if its how your team develops but not for everyone. We don't care about full history in branches; maybe it has more detail than main/master but it should still be contextually meaningful. I'd never approve a commit into main with the message "merging PR #xxx" either; it's redundant (merging), has no summary about what it actually does and relies on an external system (your PR/MR process) for details. I d…

Well sure, the title was just an example. It usually is more like this:

"Encrypt project's sensitive fields (#1234)"

With the number being a PR or an issue # (which does contain a link to the PR).

I do care about history in branches though. And many others do. I agree that it varies from team to team.

Re: Althttpd: Simple webserver in a single C file

#279

Post by cogburnd02 »

tyingq wrote: post #151
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.

What are your thoughts on darkhttpd?

https://unix4lyfe.org/darkhttpd/

Re: Althttpd: Simple webserver in a single C file

#280

Post by asveikau »

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.

Looks like test code, rather than something that runs when serving in production.

It fails an assert if the parse doesn't work I guess?

Post reply on HN