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

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

311–320 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#311

Post by ankurpatel »

e12e wrote: post #239
ankurpatel wrote: post #150

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…

> hitting it with artillery This? https://github.com/artilleryio/artillery

Yes

Re: Althttpd: Simple webserver in a single C file

#312

Post by user-the-name »

azernik wrote: post #307
user-the-name wrote: post #303

Earlier quoted context omitted.

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

Because when debugging with said history a week or a month down the line, or when someone else is debugging with said history, their human comprehension is essential for understanding why a certain event in the history is causing problems and what that event was intended to do.

That seems connected to the initial claim in only the most tenuous way.

Re: Althttpd: Simple webserver in a single C file

#313

Post by textmode »

charsi wrote: post #305
textmode wrote: post #80

Earlier quoted context omitted.

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…

I tried this but ended up with gibberish in my terminal. Also couldn't find an explanation for -a on flex's man page. I've never used the thing before.

The extra "a" is a typo but would have no effect. The "i" is also superfluous but harmless. Without more details on the "gibberish" it is difficult to guess what happened. The space before "int fileno (FILE *);" is required. All the other lines must be left-justified, no leading spaces, except the line with "int main()" which can be indented if desired.

Re: Althttpd: Simple webserver in a single C file

#314

Post by tdeck »

eloop wrote: post #302
tdeck wrote: post #246

Earlier quoted context omitted.

This is not true. HTTP was developed for the first (graphical) web browser, WorldWideWeb. It was specifically intended to serve HTML and images, neither of which is particularly well suited for browsing with telnet.

Not sure that is strictly correct. I vaguely remember a command line browser early in the piece. The inline image ability and tag came a bit later in the story when Andreessen put it into the NCSA's Mosaic browser. I've always wondered if it was that single thing that really made the web take off, more so than hyperlinking which had been around for quite a while. People like pretty pictures, especially advertisers.

You're describing the line mode browser:

https://en.wikipedia.org/wiki/Line_Mode_Browser

But that didn't just spit out the HTTP response - it parsed and rendered the HTML.

Re: Althttpd: Simple webserver in a single C file

#315

Post by azernik »

user-the-name wrote: post #312
azernik wrote: post #307

Earlier quoted context omitted.

Because when debugging with said history a week or a month down the line, or when someone else is debugging with said history, their human comprehension is essential for understanding why a certain event in the history is causing problems and what that event was intended to do.

That seems connected to the initial claim in only the most tenuous way.

In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.

Re: Althttpd: Simple webserver in a single C file

#316

Post by charsi »

textmode wrote: post #313
charsi wrote: post #305

Earlier quoted context omitted.

I tried this but ended up with gibberish in my terminal. Also couldn't find an explanation for -a on flex's man page. I've never used the thing before.

The extra "a" is a typo but would have no effect. The "i" is also superfluous but harmless. Without more details on the "gibberish" it is difficult to guess what happened. The space before "int fileno (FILE *);" is required. All the other lines must be left-justified, no leading spaces, except the line with "int main()" which can be indented if desired.

This is the script I am running - https://pastebin.com/65GxJ9i9. The - after This is what it produces for me when I run `lexit.sh us.yahoo.com` - https://stuff-storage.sfo3.digitaloceanspaces.com/ee.txt

Re: Althttpd: Simple webserver in a single C file

#317

Post by charsi »

charsi wrote: post #316
textmode wrote: post #313

Earlier quoted context omitted.

The extra "a" is a typo but would have no effect. The "i" is also superfluous but harmless. Without more details on the "gibberish" it is difficult to guess what happened. The space before "int fileno (FILE *);" is required. All the other lines must be left-justified, no leading spaces, except the line with "int main()" which can be indented if desired.

This is the script I am running - https://pastebin.com/65GxJ9i9 . The - after This is what it produces for me when I run `lexit.sh us.yahoo.com` - https://stuff-storage.sfo3.digitaloceanspaces.com/ee.txt

new pastebin. Had a typo in the old one- https://pastebin.com/4j9Z3eCc

Re: Althttpd: Simple webserver in a single C file

#318

Post by emn13 »

sangnoir wrote: post #269
IanCal wrote: post #242

Earlier quoted context omitted.

Can you not just skip all non-merge commits?

Sure, I can - but should I? That's the fundamental difference in opinion (which I don't think can be reconciled). I don't need to know what the developer was thinking or follow the individual steps when they developing a feature or fixing a bug, for me, the merge is the fundamental unit of work, and not individual commits. Caveat: I'm the commit-as-you-go type of developer, as most developers are (branching really is…

But the problem with this approach is that you're making it impossible to extract the actual changes when you do want them, whereas simply skipping non-merge commits is a minor inconvenience (`--first-parent` tends to cover it).

I mean, granted, it's not ideal. I think this is a bit of a problem with the low-level nature of git - Ideally it'd be easier to semantically bundle such sequences of commits such that it's be more reliably dealt with in the broader ecosystem (not every tool supports --first-parent), and in any case, there's nothing forcing you to maintain the first-parent-is-linear-mainline-history; that's just a tradition which, again, many common tools follow. Then of course there's the poor integration with git hosting (such as github) and git - I can blame a file, but I can't easily correlate that with the discussions in the PRs, and whatever correlation there is is purely online, with all the limitations of a single-vendor non-distributed system like that entails.

Ideally this wouldn't even be a tradeoff at all; it would be obvious how to track history both at the small scale and the larger scale (and perhaps even more?), but alas, it's what we have.

Out of curiosity - when you merge via squash, what kind of commit messages do you retain? Do you mostly concatenate the commit messages, or rewrite the whole thing?

Re: Althttpd: Simple webserver in a single C file

#319

Post by user-the-name »

azernik wrote: post #315
user-the-name wrote: post #312

Earlier quoted context omitted.

That seems connected to the initial claim in only the most tenuous way.

In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.

But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.

Re: Althttpd: Simple webserver in a single C file

#320

Post by jiofih »

azernik wrote: post #308
jiofih wrote: post #255

Earlier quoted context omitted.

Patch-perfect commits are an idealistic goal. The truth is that, as already mentioned, many of those typos and “dirty” commits can be the source of bugs that you’re looking for. Hiding them hides the history.

Problem is, when you're debugging later on you need to understand what a breaking commit does (or is intended to do) before knowing what it did wrong. Let alone the code review issue. In any multi-person project, it is just as important that your commit history be readable by a third party for information as that it be useful for your own personal debugging.

That’s solved by writing good commit messages from the start. Commiting junk or WIP is an easily fixable culture problem.
Post reply on HN