Will edit this comment with more notes as I review it.

First thing I noticed is that Raspberry Pi / Other OS have the example dump into `temp.py` and then indicate that you should request `test.py` (while Win/Mac examples correctly have them create a `test.py` file), so that could be an issue for novices. (Novices running Linux? My son, for one ;) )

EDIT 1: Compile from Source has this issue, too.

EDIT 2: The bit about `directory/index.ext` definitely matches a lot of existing tooling, but not sure if it belongs in a tool that wants to avoid 20+ years of Web cruft? Extension-less files ought to work for the same outcome, right? Or alternatively if the extension would be unambiguous (eg `calculate.*` only matches `calculate.py` it could just be omitted?

EDIT 3: Handwriting query parsing code is not great. If you're not exposing explicit HTTP verbs (GET, POST, etc) or any of the HTTP headers (since I don't see any logic for handling the headers in the stdin) it's inconsistent to have the users hand-parse the query string or body, especially when it's error prone enough that you have more comments than code in that example. It may make sense to just point them at the Python's urllib library (particularly `urllib.parse.parse_qs` for this example to get a basic dictionary to work with).

EDIT 4: I just skimmed through three of the examples (a bash one, a C one, and a TS/Deno one). Besides the custom parsing logic in all of them, and keeping the "rapid prototyping / hacking" mentality of the project in mind (which I do agree is a good thing), what keeps nagging me is: "what's the off-boarding strategy?" Since it is not intended to be secure for real deployments, is it just "rewrite it in your language of choice"? It would be nice if there were examples of what to do if your prototype is ready to be converted into a "real" project with testing, security, etc in mind, even if it was just an essay on all of the stuff that QuickServ didn't do that a real web server needs to handle. Perhaps in the future user-contributed guides for particular languages and frameworks (eg "Convert your Python QuickServ prototype to Django") could also be added to help them move on more easily, since paradoxically for this project the easier it is to migrate away, the more likely people will use it.

Thanks for the feedback! This is very helpful, and I'll be sure to fix these things as soon as I get home from work!

Extension-less files should work fine as an alternative to index.ext pages :) The purpose of index in the demo was to show QuickServ behavior. I like the idea about using calculate.py if there are no other naming collisions for /calculate

As for the query parsing, here is a suggestion: couldn’t you convert that in shell argv automatically? If “name=foo&email=bar” becomes “--name=foo --email=bar” then devs can just use regular argv parsing utils from the language, and the same script can work both from the command line and under QuickServ

I spent a long time thinking about how to do query parsing and have been dissatisfied with what I could come up with.

This is the perfect solution! Thank you so much!

This is a lovely idea.

Thanks for making this, looks like you indeed can do a lot of fun things with this! Setup was very easy. But it seems IPv6 addresses are not formatted correctly, it should be http://[IP]:port.

Also, have you thought about adding support for websockets (not that I actually need this but I guess it might be fun)?

Great catch, thanks! And thanks for the kind words!

Websockets felt a little out of scope, at least for the first release. But when I end up needing to use them for a project, I might be tempted to add them :)

This has a lot of potential in education. Instead of installing lamp, just use this and quickly write something in python instead. Thank you so much!