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

41–50 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#41

Post by chasil »

mro_name wrote: post #30
chasil wrote: post #25

Earlier quoted context omitted.

Similar is thttpd. I was not familiar with darkhttpd. Both of these are similar to the sqlite server in security design (chroot capability), but unlike in that a single process serves all requests and does not fork. I have used stunnel in front of thttpd, and chrome has no complaints. https://acme.com/software/thttpd/

althttpd has CGI, sometimes interesting.

The thttpd server also has CGI. I wrote about combining it with stunnel. The rfc-1867 tool is overly dated, and I've replaced it for my internal use:

https://www.linuxjournal.com/content/secure-file-transfer

Re: Althttpd: Simple webserver in a single C file

#42

Post by Cthulhu_ »

nneonneo wrote: post #33
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.

This loop doesn’t test them all - it tests every 1/127th integer, so it only runs about 16 million times.

And a modern CPU runs billions of instructions per second, so it shouldn't take too long at all. Depends on the implementation of the function as well though, and how the compiler can optimize, unroll or optimize both the function under test and the test itself.

Re: Althttpd: Simple webserver in a single C file

#45

Post by frou_dh »

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.

I like to remember that threading APIs were a later add-on after Unix had already existed for years. They're not fundamental like the Process is.

Isn't it an appealing model to not even have to talk about threads because every process is 1 thread by definition?

Re: Althttpd: Simple webserver in a single C file

#46

Post by Cthulhu_ »

lnxg33k1 wrote: post #20

One file of 2600 lines, guess if you give up common sense and follow this approach you can even create a kernel in one file

Whose common sense though? You seem to have one particular opinion on how to organize a project, but that's not the only one. Sometimes, having just one file is easier.

Re: Althttpd: Simple webserver in a single C file

#48

Post by Cthulhu_ »

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.

Re: Althttpd: Simple webserver in a single C file

#49

Post by mikkelam »

vmsp wrote: post #43

Blocks some referers by default: static const char *azDisallow[] = { "skidrowcrack.com", "hoshiyuugi.tistory.com", "skidrowgames.net", }; Anyone know why?

I remember seeing these crackers around back in the days. Skidrow at least cracted some grand theft auto games.

Not sure why they're blocked

Re: Althttpd: Simple webserver in a single C file

#50

Post by lmilcin »

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 bit more difficult. You can usually easily tell if your data structure is broken if it is in text form. What I do is I usually have some simple converter that converts the binary message to text form and this helps me inspect the message easily.

Post reply on HN