231–240 of 345 posts
Earlier quoted context omitted.
from the linked thread: > I just cloned your repo. Everything is working fine. Breath, Zed. seems like he panicked and made it worse, then rage-quit
Right. Reading the entire conversation shows the parent messaging is FUD.
Sure it lives a single file, but considering the length, wouldn't it actually be better to split it into multiple files? I'm not that familiar with C, it seems to be a "thing" in C to just have giant files.
I've been thinking about this a lot recently. For most of my career I've been a Java programmer and for the majority of projects, each class is put in its own file. The amount of jumping (between files / following method calls) can get really tedious when you're trying to grok a code base. I've been working on Typescript projects recently where the standard has been to have slightly larger files -- possibly containin…
I mostly use C#, and a while back I settled on a middle ground, where closely-related classes and interfaces are grouped together in a single file.
When I'm working on web apps/APIs, I usually follow the "feature folder" concept too, where all the most central parts are together in the same file.
Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!
I would like to see something like: althttpd -exec some_executable {}.method {}.body So you could quickly call executable from a browser and redirect the output in the response.
Earlier quoted context omitted.
Recording state info in static variables makes it only suitable for embedded. I really hate when people do that. Static should only ever be const, init once, or something intrinsically singleton. There are very few exceptions.
Are you thinking of C++ issues with constructors? I don’t see anything wrong with the use of static variables in this single file C program. This isn’t a library; it’s a standalone web server.
But if this only ever wants to be an app binary, I guess it's sort of okay.
> 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.
Fork() on modern Linux is very fast/lightweight. This isn't true for all POSIXy operating systems though. This would perform really terribly, for example, on any Unix implementation from the early 2000s or before, and maybe on some current ones.
[0] https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234Here 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…
It's not a property of text-based protocols, rather it's a property of simple protocols. HTTP/1 is not merely text based, it's ASCII based (technically ISO-8859-1, which includes ASCII). One char, one byte, one encoding. HTTP itself is mostly very simple, text "name: value" pairs separated by newlines, followed by arbitrary content as the body. I think the solution is to start with a simple protocol and upgrade to mo…
This is not actually true of HTTP/2 (the upgrade doesn’t use HTTP/1), and slightly misleading of HTTP/3 (there’s nothing to upgrade because it sits beside TCP HTTP; but advertising HTTP/3 support is currently done over TCP HTTP).
Now for the details:
HTTP/2 upgrade is done at the TLS level, via ALPN. Essentially the client TLS handshake says “hello there! BTW do you do HTTP/2?” and the server either responds “hi!” and starts talking HTTP/1, or “hi! Let’s talk h2!” and starts talking HTTP/2.
So it’s perfectly possible (though not a good idea) to have a fully-functioning HTTP/2 server that doesn’t speak a lick of HTTP/1.
(HTTP/2 over cleartext, h2c, does use the old HTTP/1 Upgrade header mechanism, but h2c is more or less just not used by anyone.)
HTTP/3 upgrade, well, “upgrade” is the wrong word. It’s operating over UDP rather than TCP, so you’re not upgrading an existing HTTP thing to HTTP/3, you’re starting a new connection because you’ve learned that the server supports HTTP/3. This bootstraping is currently done by advertising h3 support via the Alt-Svc header (HTTP/1+) or by an ALTSVC frame (HTTP/2+), which the client can then remember so it uses the best protocol next time.
For best results, they’re working on allowing you to advertise HTTP/3 support on DNS, so that after a while it should be genuinely possible (though a very bad idea) to have a fully-functioning HTTP/3 server that doesn’t speak any TCP at all, yet works with sufficiently recent browsers in network environments that don’t break HTTP/3. https://blog.cloudflare.com/speeding-up-https-and-http-3-neg... is good info on this part.
Does z in zTmpNam or zProtocol signify global variable? https://sqlite.org/althttpd/file/althttpd.c Also, I'd like to complain about the hn hug of death, because it isn't happening.
Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery. All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2…
This?
Earlier quoted context omitted.
And capitalisation issues, and encodings… give me a binary protocol to parse any time. They’re normally comparatively well-defined, whereas text protocols are seldom properly defined and so have undefined behaviour left, right and centre, which inevitably leads to security bugs—or even if they are well-defined, they’re probably done in a way that makes your language’s string type unsuitable, and makes parsing more co…
> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.