Handle keep-alive requests #4

2025-07-20T20:03:29-04:00

Wonshtrum commented

2025-07-20 20:03:29 -04:00

(Migrated from github.com)

Process pipelined requests of a client in a loop instead of closing after each request.
This should resolve/attenuate the built-in accept problem.
This is a crude PoC, not intended to be merged, TODO:

probably rename/separate in functions process-client/process-request
remove wc and cut

Process pipelined requests of a client in a loop instead of closing after each request. This should resolve/attenuate the built-in accept problem. This is a crude PoC, not intended to be merged, TODO: - probably rename/separate in functions process-client/process-request - remove wc and cut

bahamas10 (Migrated from github.com) reviewed

2025-07-27 01:29:01 -04:00

bash-web-server

					
				@ -237,0 +221,4 @@

							"$path/index.html"

							"$path/index.htm"

						)

						local try file

is this how we know a keep-alive request is done? (genuine question - idk keep-alive semantics)

bash-web-server

bash has some builtins for stat. i think it has finfo as well to stat the file and get information like file size in bytes.

bash has some builtins for `stat`. i think it has `finfo` as well to stat the file and get information like file size in bytes.

bahamas10 commented

2025-07-27 01:29:34 -04:00

(Migrated from github.com)

i threw some comments on this PR. i'm going to look into keep-alive myself more later but i think it should be possible and could be really useful.

i threw some comments on this PR. i'm going to look into keep-alive myself more later but i think it *should* be possible and could be really useful.

bahamas10 (Migrated from github.com) reviewed

2025-07-27 01:38:00 -04:00

bash-web-server

oh this could break. this gets the length of the string, but length might != byte count. for example:

$ a='🚀'
$ echo "$a"
🚀
$ echo "${#a}"
1
$ echo -n "${a}" | wc -c
       4

I don't immediately know a way to get the raw byte count from bash so we'd have to figure that out.

oh this could break. this gets the length of the string, but length might != byte count. for example: ``` $ a='🚀' $ echo "$a" 🚀 $ echo "${#a}" 1 $ echo -n "${a}" | wc -c 4 ``` I don't *immediately* know a way to get the raw byte count from bash so we'd have to figure that out.

Wonshtrum (Migrated from github.com) reviewed

2025-08-05 10:08:16 -04:00

bash-web-server

					
				@ -237,0 +221,4 @@

							"$path/index.html"

							"$path/index.htm"

						)

						local try file

The HTTP protocol is a mess, to be 100% compliant with all RFCs, you would need to parse some headers and the bodies. A simpler approach that would work for "body less" requests is to consider that requests directly follow each other until the connection is closed. Here I "detect" the connection close when the method field (the first to be parsed) is not set, meaning the parse-request function returned because it got EOF (not because it finished parsing a request). It would be cleaner to return an error code or a state, since I do not know bash at all, I chose a lazy option.

Wonshtrum (Migrated from github.com) reviewed

2025-08-05 10:13:56 -04:00

bash-web-server

That's an interesting problem. I do not know if bash can count bytes in a string.
Right now, I see two solutions:

close connection after this response (so revert to old behavior, since we do not know the length, we close delimit it), it shouldn't be too problematic, since directory listing generally come as a single request
write the output to a file and send it like any other file (considering we found a way to use the stat/finfo builtins)

That's an interesting problem. I do not know if bash can count bytes in a string. Right now, I see two solutions: - close connection after this response (so revert to old behavior, since we do not know the length, we close delimit it), it shouldn't be too problematic, since directory listing generally come as a single request - write the output to a file and send it like any other file (considering we found a way to use the stat/finfo builtins)

This pull request has changes conflicting with the target branch.

bash-web-server

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin Wonshtrum/patch-1:Wonshtrum/patch-1

git switch Wonshtrum/patch-1

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff Wonshtrum/patch-1

git switch Wonshtrum/patch-1

git rebase main

git switch main

git merge --ff-only Wonshtrum/patch-1

git switch Wonshtrum/patch-1

git rebase main

git switch main

git merge --no-ff Wonshtrum/patch-1

git switch main

git merge --squash Wonshtrum/patch-1