Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A little web server in C

github.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Show HN: A little web server in C

#71

Post by jacquesm »

samtho wrote: post #11

This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on…

> Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on because the minimal code version still needs its own transpiler, build system, linter, process managers, etc.

We built pianojacq.com without all that, just plain vanilla JS and a minimum of dependencies, see: https://gitlab.com/jmattheij/pianojacq

Re: Show HN: A little web server in C

#72

Post by treve »

samtho wrote: post #11

This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on…

I relate to the general concern about complexity creep a lot, but in the HTTP/1/2/3 case I'm just not terribly worried. So much effort has been put into backwards compatibility. The only potential true new concept that comes to mind is PUSH, which clients can ignore and mostly failed. HTTP/2 has been around for almost 10 years and I haven't seen a single implementation require it.

Re: Show HN: A little web server in C

#73

Post by robdelacruz »

adamrezich wrote: post #23

this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…

This site has a good tutorial for this. It recommends vultr (which is what I use), for $2.50 - $5 a month.

https://landchad.net/

Re: Show HN: A little web server in C

#74

Post by gpderetta »

friendzis wrote: post #65
bongobingo1 wrote: post #61

Earlier quoted context omitted.

> QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace Do you mind expanding on that with a sentence or two?

UDP is streams in the very classical definition: stream objects (bytes, probably, though a more faithful implementation would contain chunks/arrays) go out without predefined start/end. In other words, imagine that a single `read()` (or whatever) call returns random chunk from HTML source and it is your job to make sense of where in the space of whole page that chunk comes from. There is even no guarantee that consec…

> UDP is streams in the very classical definition

What do you mean exactly? UDP is not a stream protocol, it is an unreliable datagram one. A single read will return exactly one UDP datagram.

It is TCP where a read will return incremental data which is not necessarily aligned to what the other end wrote.

Of course QUIC builds a reliable stream abstraction on top of it, but that's not different from TCP.

Re: Show HN: A little web server in C

#75

Post by pjc50 »

amadvance wrote: post #68

Take care that select() is not good for a webserver. From manpage: WARNING: select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024)—an unreasonably low limit for many modern applications—and this limitation will not change. All modern applications should instead use poll(2) or epoll(7), which do not suffer this limitation.

Lol.

22 years ago, I worked for Zeus Web Server, which was built entirely around one-process-per-core webserving off select(), and it was so much faster than Apache for serving static content that the developers had built a business out of it. At the time it could saturate a gigabit ethernet link off the largest HP-UX server we could find.

Sure, you should use the modern interfaces, but 1024 connections per process can get you surprisingly far.

Re: Show HN: A little web server in C

#76

Post by pjc50 »

wahern wrote: post #40
GuB-42 wrote: post #24

Earlier quoted context omitted.

The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your cert…

Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is d…

> QUIC is destined to become a kernel-provided service like TCP

I think this might happen in the opposite direction to how you think: the prevalence of containers is likely to thin down the OS layer to just arbitrating the PCIe bus, and you'll get monolithic applications that handle all the layers inside themself. So the QUIC layer and the web server and the app-routing and the app itself will all happen inside the same process.

Re: Show HN: A little web server in C

#77

Post by pjc50 »

userbinator wrote: post #34
skulk wrote: post #10

Cool project, but this project demonstrates the reason I've stopped writing things in C. The standard library has garbage string functions and it seems every project has its own version of this file: https://github.com/robdelacruz/lkwebserver/blob/main/lkstrin... It's fun to write this (and read others' versions) the first 3 or 4 times, but it gets old quickly.

That's the "lazy, dumb" way of doing it --- write another string library. A much better way is to design your algorithms so they need a minimum of string manipulation, which is unfortunately on the more difficult side for text-based protocols like HTTP. Personally, I wish HTTP messages were closer to something like ASN.1 DER; there's little in the way of string manipulation necessary for those, and all the lengths ar…

> ASN.1 DER

This has also had serious security bugs because it's so hard to understand.

Re: Show HN: A little web server in C

#78

Post by gpderetta »

denotational wrote: post #37
dajtxx wrote: post #17

Earlier quoted context omitted.

I know it's not your code, but related to this comment, it looks like it missing a check for lks == null? https://github.com/robdelacruz/lkwebserver/blob/main/lkstrin...

That assert is checking a library invariant; it should never fail unless there’s a bug in the string library itself (although I’m not entirely sure this string library would tolerate a malloc failure from a quick glance through). This is distinct from checking the parameters; if lks is null then the user of the API has made an error. Some libraries may sanitise user parameters, others don’t. At any rate, an assert wo…

assert is an acceptable way to deal with precondition failures.

Re: Show HN: A little web server in C

#79

Post by msla »

pjc50 wrote: post #76
wahern wrote: post #40

Earlier quoted context omitted.

Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP. In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development. Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is d…

> QUIC is destined to become a kernel-provided service like TCP I think this might happen in the opposite direction to how you think: the prevalence of containers is likely to thin down the OS layer to just arbitrating the PCIe bus, and you'll get monolithic applications that handle all the layers inside themself. So the QUIC layer and the web server and the app-routing and the app itself will all happen inside the s…

Service VMs, in IBM-speak, where the "OS" is a hypervisor called VM.

Reinvented a bit later as libOS (library operating systems) and unikernels.

Even Linux got in on that a bit:

https://lwn.net/Articles/637658/

It isn't a stupid idea, but the only way to update anything is to rebuild the world. Luckily it's a small world after all.

Re: Show HN: A little web server in C

#80

Post by stevefan1999 »

I hate to say it, old man, we have Rust today and we can do things as efficient and as performant as you while being safer overall.

We have tokio to handle all the IO stuff, we have hyper to handle HTTP parsing, and we even have tungstenite to handle websocket out of the box. While I appreciate your work but it will not be practical to write C anymore in the modern age. Well, unless you need to target something LLVM isn't there yet and maybe you need some weird GCC toolchain (cough cough AVR)

Post reply on HN