Althttpd: Simple webserver in a single C file

Post by the_arun » Wed, Jun 09, 2021, 3:52 AM UTC

chrismorgan wrote: post #68

lmilcin wrote: post #50

Earlier quoted context omitted.

Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes. The issue is that many (especially scripting) languages treat binary data as second class. The only real issue is that inspecting the binary message visually is little b…

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…

Post by user-the-name » Wed, Jun 09, 2021, 6:12 AM UTC

chousuke wrote: post #214

user-the-name wrote: post #174

Earlier quoted context omitted.

Why not? I do not see any reason to have a history at all for anything except to be able to go back to a specific version to track down a problem. Inaccurate history makes that less useful.

Typo commits and the usual iteration during development isn't "accurate history". Noise in commit logs provides negative value. Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list; whether it's a single commit that was perfect from the get-go or fifty that you had to re-order and rewrite twenty times does not matter at all; the final commit message should contain an…

Post by charsi » Wed, Jun 09, 2021, 10:26 AM UTC

textmode wrote: post #80

TazeTSchnitzel wrote: post #40

Earlier quoted context omitted.

Once you have to support HTTP/1.1 it's not really a text-based protocol, because support for chunked encoding is mandatory for clients. (Yes the chunk headers are technically text, but it's interspersed with arbitrary binary data. It's not something you can easily read in a text editor.)

I make most HTTP requests using netcat or similar tcp clients so I write filters that read from stdin. Reading text files with the chunk sizes in hex interspersed is generally easy. Sometimes I do not even bother to remove the chunk sizes. Where it becomes an issue is when it breaks URLs. Here is a simple chunked transfer decoder that reads from stdin and removes the chunk sizes. flex -8iCrfa Example Yahoo! serves ch…

Post by azernik » Wed, Jun 09, 2021, 1:39 PM UTC

user-the-name wrote: post #303

chousuke wrote: post #214

Earlier quoted context omitted.

Typo commits and the usual iteration during development isn't "accurate history". Noise in commit logs provides negative value. Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list; whether it's a single commit that was perfect from the get-go or fifty that you had to re-order and rewrite twenty times does not matter at all; the final commit message should contain an…

> Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list Why?

Post by azernik » Wed, Jun 09, 2021, 1:44 PM UTC

user-the-name wrote: post #174

azernik wrote: post #148

Earlier quoted context omitted.

Representing the history more accurately is not a useful design goal

Why not? I do not see any reason to have a history at all for anything except to be able to go back to a specific version to track down a problem. Inaccurate history makes that less useful.