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

[alarch@xxxxxxxxx]

Le 07.08.2026 17:00, Claus Dietrich a écrit :
> 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

Dear Claus,

Thank you for the detailed and open answer — I really appreciate it.

I agree with your priority order, with one small nuance: I think 
Content-Length transmission is actually a prerequisite for keep-alive to 
work correctly (the client needs to know where a response ends to safely 
reuse the connection for the next request), rather than a separate, 
independently-orderable item. So I'd frame it as: A) Content-Length 
(foundation for both what follows), B) compression, C) keep-alive on top 
of that foundation. But the practical order of implementation you 
propose sounds entirely reasonable to me either way.

On the multi-connection data integrity question: since we're both unsure 
whether it's a real issue or a theoretical one, I'll try to build a 
small test case (e.g. two overlapping slow requests) on top of a 
proof-of-concept to see whether it actually causes visible problems in 
practice, rather than assuming it does. I'll report back what I find — 
this seems like the kind of thing better settled by observation than 
speculation.

I'll start putting together a small proof-of-concept incorporating A/B/C 
above, plus the restricted file-serving path, and share it with the list 
once I have something concrete to look at rather than more 
back-and-forth in words. In the meantime, Benoît pointed me to gb.httpd, 
which I wasn't aware of and which might already solve part of what we're 
discussing at the transport level — I'll check whether it changes the 
picture before going further.

Thanks again for sharing your original work, it's been a great starting 
point.

Best regards,
Marc