💾 Archived View for bbs.geminispace.org › u › skyjake › 4152 captured on 2023-12-28 at 17:09:35. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Re: "Bliz server side scripting for Gemini."
@michaelnordmeyer Using a non-gemtext server-side source format certainly has drawbacks, as you note. It would in practice be a more convenient alternative to CGI for serving dynamic content.
Aug 12 · 5 months ago
🍵 michaelnordmeyer · Aug 12 at 18:31:
@skyjake Wouldn't it be better to write a general Gemini reverse proxy? Then you could proxy to any language, runtime, whatever.
@michaelnordmeyer a general reverse proxy for gemini is not workable due to tls client certs, it works for non-cert urls though, some kind of cgi proxy might work or a http one that proxies gemini content
🍵 michaelnordmeyer · Aug 30 at 12:18:
@alexlehm I'm meant a reverse proxy you host for yourself, not for other people's capsules. Why would such a proxy not be able to handle client certs?
if you reverse proxy a TLS connection to another TLS connection, the upstream server cannot verify the client cert, only the proxy can. Passing additional paramters like the cert hash could work, but gemini directly does not
🍵 michaelnordmeyer · Aug 30 at 12:30:
Well, my idea of the proxy is to terminate TLS there, like you would terminate HTTPS requests for API ingress. Depending of the hosted content, the apps behind the proxy should know as little as possible about what's going on in front of the proxy.
yes, HTTPS would not work with client certs either, you have to add some metadata to the internal request. someone suggested using the PROXYv2 protocol. (I have to say that I have not tried anything yet, so I mostly guessing how it would work)
Bliz server side scripting for Gemini. — found this today. looks interesting.