Web dev in C

Who needs a huge server and scripting environment to run a simple site? Just open a socket, read until the second space, dump the requested file and close the socket.

Just think about all the electricity and time wasted because of wastefully starting Apache, parsing a complex config file each time, sending the script to PHP where it is parsed for the millionth time, generate the output, apply transformations to the headers, sending it out, keeping the socket open just in case there is another request, all for the convenience of not having to compile a script.

Apache doesn't start each time the script is requested.

You can use something like nginx instead of apache which is a piece of shit.

Proper caching mechanisms and a separate daemon for the server-side script interpreter is more efficient than a naive implementation in C.

CGI starts the entire process each time, since the program dies after shitting out its output. The act of mapping the executable to memory and initializing all that it needs to serve the request is expensive if it needs to be done hundreds to thousands of times a second. You're raping the kernel with all those socket init/close calls, all the memory map calls, and all the cleanup it has to do each time the request is done.

Your idea of how a web server works is also idiotic. You can't just "dump the file". Especially if the content is dynamically generated. That's why shit like chunked encoding exists. You won't know how long the content is until it's generated, and if you generate the entire thing before starting to send then you're increasing memory usage a substantial amount, and adding delays to the transfer. If you're going to close the socket each time you finish sending data, this is also extremely inefficient since even the simplest page usually has stylesheet and a few images, so you're adding in 5+ socket open/close calls, all the handshake overhead and the recalculation of the sliding window each time since you've destroyed the socket at that point, instead of just doing what HTTP does and just leaving it open. It's not "just in case", 99% of the time there will be more than one request.

Basically, you're retarded.

Most of my REST APIs at work are C++.
I'd rewrite them in C if it wasn't for my colleagues (C++tards)

I have half a textboard written in C (well, C++, but only for <threads> and std::string, and I planned on removing those later). I got distracted by the SQL needed and the Shiichan compatible BBCode compiler turned out to be a total clusterfuck.

I think I'll start working on it again, actually.

>>4
C11 has threads.h and POSIX has pthreads that is actually supported even in non-POSIX systems.

Enjoy eating bugs like shellshock or being 0wned for making retarded mistakes.

>>6

Sounds fun

>>6

0wned
pwned

computer/network ``security'' is so easy to break into that you have mentally disabled kids and manchildren who come up with and use such words or ``1337 speak'' to describe their ``penetration testing''.

It's pretty fun.

I wrote a toy webapp with C and SQLite, but eventually got bogged down in Greenspun's Tenth.

I think that Plan 9 C could make it even nicer.

>>2

CGI

Who says you need to use CGI? Just listen on a socket and parse HAX /anus HTTP/1.1\r\n, it's not hard.

I've done exactly that in Java and C, and if anything it was easier than writing a CGI since I didn't have to dick around with environment variables.

process startup

So long as you use static linking, this will be pretty cheap because the image will be cached.

keep-alive

This is a valid point. I've never bothered, but it shouldn't be too much trouble to keep the thread/process handling each client alive to serve another request.

Of course, if you weren't careful about reaping them you could open yourself up to DoS.

>>6

My face when I wrote the world's shittiest half-of-a-textboard in C because I didn't trust myself to get all the shell expansions right.

It was terrible, but I'm pretty sure it was secure.

>>9

but it shouldn't be too much trouble to keep the thread/process handling each client alive to serve another request

Actually well-done keep-avile is a PITA of gigantic proportions which can compare to implementing a correct HTTP cache handling mechanism.

>>10

I haven't put much thought into it, but why isn't it just
while(receive connection){
thread{
handle request
}
}
vs
while(receive connection){
thread{
while(receive request)
handle request
}
}

well-done

Well, that's something else entirely!

>>8
I need some penetration testing of my anus.

>>4
A shii_tchan compatible BBCode parser is very difficult. My attempt is at http://w5ch.heliohost.org/board.py

How do you pronounce iframe?

1. iFrame
2. IFRAME
3. I don't (faggot)
4. iframe

install BSD/Gentoo

I recently started working on something like this;
http://str8c.me/talk/

it is very basic and incomplete, but the HTTP server itself is around 400 lines and the BBS 400 lines too (including HTML), the code is on github
https://github.com/str8c/nhttp
https://github.com/str8c/nbbs

for more serious use you can do server side scripting in C with FCGI+nginx

>>1
I understand the appeal, but sometimes worse really is better. Half-assed gets the job done faster (or at all). Save C for when it matters.

VARNISH MY ANUS

>>15
Fucking horrible.

Why the fuck do you niggers keep reimplementing shitty protocols all the time? Cudder and his shitty HTML engine, you and your shitty HTTP server. There's uzbl/luakit and lighttpd for that.

Why do you not redirect your useless efforts to creating a new protocol that doesn't suck nigger dick?

>>19
No one would use it.

You can use Symta. It compiles to plain C.

int
parsereq(char *buf, int n, Req *req)
{
int i;

if(buf == 0 || req == 0)
return -1;

for(i = 0; i < 15 && isalpha(*buf); ++i)
req->method[i] = *buf++;
req->method[i] = '\0';

if(!methodOK(req->method))
return -1;

while(isspace(*buf))
++buf;

for(i = 0; i < MAXPATH && !isspace(*buf); ++i)
req->path[i] = *buf++;
req->path[i] = '\0';

while(isspace(*buf))
++buf;

if(strncmp(buf, "HTTP/1.0", 8) != 0)
return -1;

gethdr(buf, req->host, "host");

if(strcmp(req->method, "CHECK") != 0)
return -1;
if(strcmp(req->path, "/doubles") != 0)
return -1;

return 1;
}

When I make a shitty website, I don't want eight extra KILOBYTES of worthless memory management code and error checking code! I just want an WEBsite!! Not a “phpsite”. Not a “pythonsite”. Those aren't even WORDS!!!! C! C! C IS THE STANDARD!!!

>>20
Nobody will use your half-assed implementations of shitty protocols either.

Why do you even bother? If you're making something for fun, don't constrain yourself to smear yourself in shit with the apes.

>>24
I don't bother.

>>24
He can use it, the clients will just work.

>>26
Not if I don't pay them.

>>15
This is bad design.

If it ain't lisp, it's shit.

I agree that the program should open a socket itself though. CGI is stupid and should only be used for cheap webhosts. Even for a real website, a VPS is like, $20 a month these days. Just use nginx as a reverse proxy if you need to host multiple domains. CGI is basically just a a way to fill a few envar before starting the script anyway, and is mostly just a regular program without some sort of framework to waste resources for you.

'faggot'

Just need a template preprocessor for C. Shouldn't be hard.

>>31

It's really easy with Lex!

If you want to get really fancy, you could use Yacc as well, but if you go much further down that route you'll accidentally reinvent PHP!

>>32
I was being ironic, cocksucker. The proper form is to have it in another file.
// magic.html
"Name: <span style=\"color: green(\">%s"</span>"
// ...

// shitchan.c
// ...
sprintf(&posthtml,
#include "magic.html"
, name,...);

design my anus