Re: Feasibility of an async HTTP server engine in Gambas (uvicorn-style) + question about JIT

[Claus Dietrich <claus.dietrich@xxxxxxxxxx>]

Dear Marc

Am 07.08.26 um 14:49 schrieb alarch@xxxxxxxxx:
> Dear Claus,
>
> Thank you again for sharing this.
>
> I went through the HttpServer.class in detail and I'm impressed by how 
> much ground it already covers (language negotiation, cookies, MIME 
> type detection for a dozen formats...). That's a lot of tedious 
> groundwork already done correctly.
>
> I tried to think through how this concept would extend to my own use 
> case: a small personal ERP/monitoring tool, potentially with several 
> browser tabs open at once, and pages backed by a database with 
> credentials. That led me to a few open design questions rather than 
> anything wrong with your code, more "what would need to change for a 
> different use case" than a review:
>
> 1. Since request data (GetURL, cookies, POST parameters...) is stored 
> on the server instance itself, I wonder what would happen with two 
> near-simultaneous requests from different clients (or even two tabs 
> from the same browser): would there be a risk of one request's data 
> overwriting another's before the response is sent? I started sketching 
> a version where each connection gets its own small Request object 
> instead, but I'm not sure if that's overengineering for typical use 
> cases or a real necessity.

My work is a few years old and actually served a special and rather 
simple purpose (optional web interface for remote control of a standard 
Gambas GUI app). For the moment I have no clue whether the present 
solution implies issues with regard to data integrity in case of a multi 
connection scenario. So I am not sure whether "client-related response 
objects" are required. Anyhow, this should be kept in mind as something 
which requires an answer.

> 2. For serving files directly from $GetURL (like the CSS/image/JS 
> branches), since the URL comes straight from the client, I was 
> wondering whether it's worth restricting it to a fixed subdirectory 
> (something like rejecting any URL containing ".."). Mostly thinking of 
> cases where the app also has, say, a config file with credentials 
> sitting nearby.
Client related permissions make sense to me.
> 2. I noticed Content-Length isn't sent in the response headers, and 
> the connection always closes afterwards. I assume this was a 
> deliberate simplification given HTTP/1.0-style behavior? I ask because 
> I think it would make asset-heavy pages (many small CSS/JS/image 
> requests) noticeably slower over a real network compared to 
> keep-alive, so I'm curious whether that's already on your radar as a 
> possible next step.
Yes, this was a simplification because of the very small scale of 
application. I was assuming that heavy asset pages would rather profit 
from compression than keep alive functions. But compression was also not 
implemented, because of the small scale of application. If I would take 
up this project again, I would clearly go for compression as first goal.
> I'd genuinely like to try building a small proof-of-concept on top of 
> your work, addressing these three points (isolated per-connection 
> request objects, restricted file serving path, optional keep-alive), 
> and share it back with the list so we can compare approaches. Would 
> that be alright with you, or would you rather handle it differently?
I would go ahead with A) transmission of length, B) compression (gzip) 
and C) keep alive. With this we would have implemented an essential 
range of low level HTTP requisites. All further mechanisms, which might 
be required for data integrity is something I would take up in a later 
stage.
> Best regards,
> Marc

Best regards

Claus