Althttpd: Simple webserver in a single C file • Hacker News Board

Re: Althttpd: Simple webserver in a single C file

#241

Post by GordonS » Tue, Jun 08, 2021, 5:28 PM UTC

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…

> I'm also curious how much of that bandwidth couldn't be offset by a CDN or mirrors

As you say, at $40/m it's academic for a lot of people, but AFAIK, the whole site is static, so presumably if you put it behind Cloudflare’s free tier it would serve all but the file downloads from the edge. A pure guess, but I'd imagine that would mean serving 75% of requests from the edge.

Re: Althttpd: Simple webserver in a single C file

#242

Post by IanCal » Tue, Jun 08, 2021, 5:32 PM UTC

sangnoir wrote: post #168

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.

> 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 (li…

Can you not just skip all non-merge commits?

Re: Althttpd: Simple webserver in a single C file

#243

Post by e12e » Tue, Jun 08, 2021, 5:44 PM UTC

rkeene2 wrote: post #117

squiggleblaz wrote: post #28

Earlier quoted context omitted.

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/

> 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 ZeroTierOne over the Internet to my Nvidia Shield via just DLNA/UpNP (still to vlc) just fine. But I'm considering moving to caddy and/or http/webdav - as a reasonable web server with support for range request seem to handle skipping in the stream much better.

Re: Althttpd: Simple webserver in a single C file

#244

Post by dimitrios1 » Tue, Jun 08, 2021, 5:46 PM UTC

pdimitar wrote: post #220

dimitrios1 wrote: post #182

Earlier quoted context omitted.

Consider editing. Yes, a paper goes through revisions, which are holistic, and represent one iteration to the next. But in between those revisions, you can see markups, and editor notes as to why a change was performed. Sometimes those insights are just as useful as the packaged whole.

Everybody who ever wrote their own diffing program has considered that and that's not the problem. The problem is how does this approach scale in a repo with 50+ contributors? It doesn't, sadly.

> how does this approach scale in a repo with 50+ contributors?

You surely aren't going to have 50 contributors all simultaneously working on the same mainline or feature (or have 50 working together at the same time if ever, if you do, I'd say that's poor project management). The reality is a portion of the developers work on this feature in this part of the code base, a few over here, they'll be on their own branches or lines, and everything will be fine.

This scenario where we have 50+ devs all crashing and bumping into each other rarely happens, if ever. I have personally only seen one instance of it happen in kernel development. And even then it was relatively straightforward to sort out.

To go further, in a hypothetical scenario where there is one feature and 50+ open source developers are all vying to push their patches in, there is still going to be one reference point to work off of, and reviewers are going to base everything off that. It's a sequential process, not concurrent.

Re: Althttpd: Simple webserver in a single C file

#245

Post by Jach » Tue, Jun 08, 2021, 5:49 PM UTC

papaf wrote: post #224

Jach wrote: post #202

Earlier quoted context omitted.

I'm pretty familiar with a lot of Zed's doings but I had missed this one. I doubt it impacted the adoption much, losing one advocate like that isn't going to doom your project. I finally gave Fossil a serious try last year for a few months, just on my own but I don't think my opinions would change if I tried in a team setting. I still love the idea, but the execution is... ghetto. Serviceable, certainly, but ghetto i…

And git+[choice of issue tracker]+[choice of forum]+[choice of wiki]+[choice of project website]+etc. is the real competition against Fossil I think that this is only true for some projects. For some people, the ease of self hosted setup (one executable) and the fact that you can change the documentation, edit code and close bugs offline is a big win that no centralized service can compete with.

Sure, one executable is nice, that might be enough of a payoff for some people to overlook the rest. I think you may be underestimating the amount of choice that's out there though. For documentation alone there's countless options that don't require a centralized online thing. Three I'd use over Fossil again are 1) simple project doc/ folder with .md files inside (which you can render locally to look just like github with https://github.com/joeyespo/grip) 2) Doxygen or a language-specific equivalent if it's better 3) libreoffice docs stored either in the same repo or another one (perhaps a submodule).

For project management I'm less familiar with the options out there but I'd be surprised if there was nothing that gives a really stellar offline experience. I'd give a preemptive win to Fossil on the narrow aspect that your issue tracking changes can be synced and merged automatically with a collaborative server when you come back online, whereas if you stood up your own instance of Trac for instance I'm not sure if they have any support for syncing. If you're working by yourself, though, then there's no problem, Trac and many others work just like Fossil and stand up a local server (or are dedicated standalone programs) and work the same whether you're offline or online. But when I'm working solo I prefer low-tech over anything that resembles Jira (and I don't even really dislike Jira) -- I've played with https://github.com/dspinellis/git-issue as another offline/off-platform option but in my most recent ongoing solo project I'm quite happy with a super low-tech issues text file that has entries like (easy to make with https://github.com/dhruvasagar/vim-table-mode)

    +--------------+
    | Add thing    |
    +==============+
    | Done whens / |
    | other info   |
    +--------------+

and when I'm closing one I just move it to the issues-closed file as part of the closing commit. I might give it an identifier if I need to reference it in the code/over multiple commits.

Re: Althttpd: Simple webserver in a single C file

#246

Post by tdeck » Tue, Jun 08, 2021, 5:53 PM UTC

Iwan-Zotow wrote: post #153

daitangio wrote: post #107

Earlier quoted context omitted.

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

This is not true. HTTP was developed for the first (graphical) web browser, WorldWideWeb. It was specifically intended to serve HTML and images, neither of which is particularly well suited for browsing with telnet.

Re: Althttpd: Simple webserver in a single C file

#247

Post by Sohcahtoa82 » Tue, Jun 08, 2021, 5:55 PM UTC

TZubiri wrote: post #102

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…

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

I always wanted an HTTP response code for when the server detects a malicious request. Like, 430 DONT BE AN ASSHOLE

Re: Althttpd: Simple webserver in a single C file

#248

Post by jchw » Tue, Jun 08, 2021, 6:07 PM UTC

lmilcin wrote: post #50

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…

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…

They definitely don't have to be. I've echoed these sentiments before.

However, HTTP/2 and HTTP/3 certainly are, though the reasons why they are complicated have nothing to do with choosing to use a binary based format. (They are complicated for good reason, though, and I hope that browsers and servers can continue to support HTTP/1 as the baseline till the sun burns out, just to make life easier.)

Re: Althttpd: Simple webserver in a single C file

#249

Post by ulises314 » Tue, Jun 08, 2021, 6:23 PM UTC

This pretty much sounds like my networks class final project.

Re: Althttpd: Simple webserver in a single C file

#250

Post by jrockway » Tue, Jun 08, 2021, 6:23 PM UTC

scruple wrote: post #227

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…

> 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 parser. Neither format solves any intrinsic problems -- malicious input has to be accounted for, you have to write fuzz tests, you have to deal with broken producers. It's a wash.

People like text because they can type it into telnet and see something work, which is kind of cool, but probably not a productive use of time. I can type HTTP messages, but use curl anyway. (SMTP was always my favorite. "HELO there / MAIL FROM foo / RCPT TO bar / email body / ." Felt like a real conversation going on. Still not sure how to send an email that consists of a single dot on its own line though.)