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

Show HN: Hosting my website using my C web server

github.com

Post reply on HN
Print view View original

151–160 of 160 posts

Re: Show HN: Hosting my website using my C web server

#151

Post by pdp11ty »

theideaofcoffee wrote: post #29

Awesome! I used to think (well, I still do) that getting a barebones service up and running using the system APIs at the lowest level like this is so satisfying. It's sort of magical, really. And to see it serve real traffic! I'm kind of surprised that the vanilla poll() can put up numbers like you were seeing, but I guess it's been a while since I've had to do anything event related/benchmark at that level. I love t…

People seem to forget that all of their amazing, wonderful abstractions are, at their core, doing exactly this: opening sockets, reading from them, writing to them, etc. There is nothing new under the sun.

Re: Show HN: Hosting my website using my C web server

#152

Post by deadlocked »

tnolet wrote: post #89
dartos wrote: post #84

Earlier quoted context omitted.

I run many server programs on my homelab. Each is running on a different port, but I want them all accessible publicly from different URLs and I only want to expose port 443 to the internet. I also want to have TLS autorefresh for each domain. I need a reverse proxy for the former and caddy does both. If you’re running a single server and that server does TLS termination then you don’t really need a reverse proxy.

e.g. Virtual hosting as we called it in the Apache days

Virtual hosting is only similar in that it allows you to serve content based on the requested FQDN (or, indeed, destination port of the request).

Re: Show HN: Hosting my website using my C web server

#153

Post by remram »

TZubiri wrote: post #146
knowitnone wrote: post #123

Earlier quoted context omitted.

does that mean recompile every time them HTML is changed? No thanks :)

A nice intermediate I use is baking the paths into the source code, so that I only recompile when I add files, but I can hot-swap contents without even restarting the server. Although if you start caching contents in memory (which is faster) you would have to at least kill the server and restart it. Or signal a reload.

Seems like the worst of both worlds. You need to recompile for content changes, and you need to distribute multiple files.

Re: Show HN: Hosting my website using my C web server

#154

Post by remram »

jpc0 wrote: post #131

> No Transfer-Encoding: Chunked (responds with 411 Length Required, prompting the client to resend with Content-Length I've always wanted to undertake a project similar to this but chunked encoding has always been the thing that put me off the idea... I never even though about just not supporting that :) I've written many http/1.1 servers in the past but only for internal stuff that I also controlled the clients. Gue…

Chunked encoding is pretty easy no? Just write the full size and \r\n, you can send as one chunk.

It does mean you have to read the client's headers to see if it was requested, though.

Re: Show HN: Hosting my website using my C web server

#155

Post by remram »

knowitnone wrote: post #124
a2128 wrote: post #92

Earlier quoted context omitted.

For a blog? If you don't put anything important on the server itself I can't imagine a hacker could do much. Maybe put a nasty image on your front page, or put their Bitcoin address pretending it's the place to send donations, but it would take a lot of time and effort to remain hidden for hardly any gain.

or take over your server?

Unless your server has very unusual features, or there are VERY serious kernel vulnerabilities, all an attacker can do is read files accessible to the server's user or run code as the server's user.

And possibly serve attacker-controller content to other users.

Re: Show HN: Hosting my website using my C web server

#156

Post by dartos »

com2kid wrote: post #140
dartos wrote: post #84

Earlier quoted context omitted.

I run many server programs on my homelab. Each is running on a different port, but I want them all accessible publicly from different URLs and I only want to expose port 443 to the internet. I also want to have TLS autorefresh for each domain. I need a reverse proxy for the former and caddy does both. If you’re running a single server and that server does TLS termination then you don’t really need a reverse proxy.

Every page off of my (static HTML file!) home page[1] is actually a distinct microservice sitting behind a reverse proxy. I can throw some new experiment together, built it with whatever tooling I want, give it a port number, and let nginx route to it. It removes a lot of friction from "I wonder if making this service is a good idea?" and because I am self hosting I am not tying myself down to any of the "all in one"…

Microservice maximalism.

Re: Show HN: Hosting my website using my C web server

#157

Post by v3ss0n »

nineteen999 wrote: post #53
v3ss0n wrote: post #46

Nginx is C web server.

So is Apache and OpenBSD httpd and probably too many others to name. Node.js is written in C/C++ as is Litespeed, probably Cloudflare Server as well. Microsoft IIS is written in C++. So that accounts for about the top 5 ...

Heh ,Then python and php are included as C web servers too

Re: Show HN: Hosting my website using my C web server

#160

Post by jpc0 »

remram wrote: post #154
jpc0 wrote: post #131

> No Transfer-Encoding: Chunked (responds with 411 Length Required, prompting the client to resend with Content-Length I've always wanted to undertake a project similar to this but chunked encoding has always been the thing that put me off the idea... I never even though about just not supporting that :) I've written many http/1.1 servers in the past but only for internal stuff that I also controlled the clients. Gue…

Chunked encoding is pretty easy no? Just write the full size and \r\n, you can send as one chunk. It does mean you have to read the client's headers to see if it was requested, though.

This is chunked encoding from the client...
Post reply on HN