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 indi

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.