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

81–90 of 121 posts

Re: Show HN: A little web server in C

#81

Post by cpach »

jacquesm wrote: post #71
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

Hey, I really like the choice of default song you chose :)

Re: Show HN: A little web server in C

#82

Post by skaushik92 »

samtho wrote: post #13
skaushik92 wrote: post #12

Earlier quoted context omitted.

I see what you’re saying and agree that HTTP3 is complicated but I would that since it’s a backwards compatible standard, the added complexities are completely optional. For most use cases the basic protocol is perfectly suitable and only as the scale evolves does it require the additional complexity.

I understand what you’re saying, but if someone decides to post a link to their project that is an HTTP/3 server in under X lines of code but only implements HTTP/2 features, is it really an HTTP/3 web server?

Where does it say it is an HTTP/3 server? Looking at the tests it seems that it’s just a HTTP/1 server I think.

Re: Show HN: A little web server in C

#83

Post by friendzis »

gpderetta wrote: post #74
friendzis wrote: post #65

Earlier quoted context omitted.

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.

In the classical definition stream is "sequence of data elements", without any additional guarantees. In this context TCP is stream transformer/filter: stream of "raw" packets is transformed into payload stream.

> 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.

This is exactly what makes UDP a stream of datagrams. Data is defined over one single UDP datagram - UDP gives exactly zero guarantees about data across datagram boundaries. There is no first, there is no last, there is no next/previous datagram, there no guarantees and expectations whether more datagrams will follow.

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

Key word "reliable", which is subset of streams. In goes stream of datagrams, out goes ordered (and otherwise identified) stream of bytes. Reading your comment it seems that you equate "stream" with "asynchronously fetched buffer" meaning from C++ and others, which is a stricter definition of streams.

Re: Show HN: A little web server in C

#84

Post by ttymck »

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…

This is a result of trying to make HTTP "do everything well", right? Instead of leaving it to each application to select a layering of successive protocols tailored to it's needs, everything has been jammed into the HTTP spec, which has the nice property of giving you all its features in web browser clients (which is the delivery mechanism for this wide array of apps).

Certainly some applications need not have access to the entire HTTP suite. If the goal is not to offer a "full-featured" client then an HTTP client may not be terribly difficult, it can just fail gracefully if the other party tries to do something it doesn't support?

Re: Show HN: A little web server in C

#85

Post by mananaysiempre »

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…

> The fact QUIC uses UDP is an important aspect here because a performant userspace QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes

Only because the implementations of fds in popular kernels are absolute rubbish at allowing userspace to extend them, except for perhaps ptys. A userspace implementation of a protocol can make a domain socket or just pass the client one half of a socketpair, but it cannot change the way accept() behaves, let alone add its own sockopts.

Even if you extend a kernel to do this, I suspect there are going to be interesting security implications when processes can suddenly receive fds that behave in funny unexpected ways. Much like the current mess with Linux namespaces: not because the idea is inherently bad, simply because we waited this long to try it.

Re: Show HN: A little web server in C

#86

Post by easytiger »

stevefan1999 wrote: post #80

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…

> While I appreciate your work but it will not be practical to write C anymore in the modern age.

been hearing that for 20 years

Re: Show HN: A little web server in C

#87

Post by capableweb »

stevefan1999 wrote: post #80

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…

If you goal is to just reuse as much stuff as possible, which you seem allude to, then you should just use Apache/nginx/caddy directly. But the goal here doesn't seem to be that, so it makes sense to implement it without using as many libraries as possible.

Both approaches are valid and serve different purposes, you seem to have misunderstood the purpose here.

Re: Show HN: A little web server in C

#88

Post by jacquesm »

cpach wrote: post #81
jacquesm wrote: post #71

Earlier quoted context omitted.

> 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

Hey, I really like the choice of default song you chose :)

Bach WTK prelude 1? It was the first real piece I ever learned so that's why it's there :)

Re: Show HN: A little web server in C

#89

Post by gpderetta »

friendzis wrote: post #83
gpderetta wrote: post #74

Earlier quoted context omitted.

> 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.

In the classical definition stream is "sequence of data elements", without any additional guarantees. In this context TCP is stream transformer/filter: stream of "raw" packets is transformed into payload stream. > 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. This is exactly what makes UDP a stream of datagrams. Data is de…

I never heard of UDP defined as a stream (of packets), and it collides with the canonical definition of stream protocols from UNIX, BSD sockets, and the IP stack.

Re: Show HN: A little web server in C

#90

Post by easytiger »

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…

You need a VPS. Hundreds of providers available.
Post reply on HN