I would want to make the Gemini service with both TLS and non-TLS with the
same port number, using xinetd and stunnel. Can this be done easily by
using these programs? (I would rather not use a different port number.)

As far as I know, the first byte of the client's message with TLS is not
going to be the same as the request of Gemini, so this should not cause
any ambiguity, but the implementation might not do that.

A environment variable could specify if it is TLS or not and if a client
certificate is available. This will be relevant if a file is requested
that requires a client certificate; this is the only case where TLS vs
non-TLS will be relevant, in which case it must issue a redirect.

--
Don't laugh at the moon when it is day time in France.

news@zzo38computer.org.invalid writes:

> I would want to make the Gemini service with both TLS and non-TLS with the
> same port number, using xinetd and stunnel. Can this be done easily by
> using these programs? (I would rather not use a different port number.)

To the best of my knowledge, this is not reasonably feasible. Normally,
services where you can run TLS and non-TLS on the same port have some
kind of STARTTLS mechanism, which Gemini lacks. Also, by spec, Gemini is
TLS-only; some people call Gemini-minus-TLS "Mercury" because of a
thought experiment by Solderpunk, but it's not widely deployed, and it's
generally considered that the only use of it is retrocomputing.

All that said... you might look into sslh[1], if you are interested. It
doesn't natively support Gemini or Mercury, but it ought to be possible
to add it. In the dim past, I used it to serve SSH and HTTPS on the same
port.

[1]: https://github.com/yrutschle/sslh

--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow