💾 Archived View for gemi.dev › gemini-mailing-list › 000438.gmi captured on 2024-06-16 at 13:15:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
twins, a Gemini server written in Go, is now available. Features: - Serve static files - List directories (when enabled) - Reverse proxy requests - TCP - FastCGI - Serve system command output - Reload configuration on SIGHUP twins makes it easy to host a Gemini site. Domains, paths and resources are specified via YAML. Dynamic sites powered by PHP, Python, etc. may be hosted using FastCGI. twins includes the response body size in the media type header by default. This enables user experience improvements in Gemini clients, such as indicating download progress. It is possible to disable this feature. Website: gemini://twins.rocketnine.space Repository: https://gitlab.com/tslocum/twins
> twins includes the response body size in the media type header by default. This > enables user experience improvements in Gemini clients, such as indicating > download progress. It is possible to disable this feature. For anyone wondering what that looks like: ? gemget --header -o- gemini://twins.rocketnine.space/ Info: Started gemini://twins.rocketnine.space/ Header: 20 text/gemini; charset=utf-8; size=1128 It looks like a nice server, but to be honest I would remove this. Serving non-standards is not what Gemini is about imo, and it's how the Web became what it is today. And clients in general should be strict and not accept things out-of-spec. For example Amfora won't allow non-standard status codes, even if the first digit matches a known code. It doesn't check for non-standard MIME params, but maybe it should? Anyway, thanks for sharing. How was the experience of the server development? makeworld
It was thus said that the Great colecmac at protonmail.com once stated: > > > twins includes the response body size in the media type header by default. This > > enables user experience improvements in Gemini clients, such as indicating > > download progress. It is possible to disable this feature. > > For anyone wondering what that looks like: > > ? gemget --header -o- gemini://twins.rocketnine.space/ > Info: Started gemini://twins.rocketnine.space/ > Header: 20 text/gemini; charset=utf-8; size=1128 > > > It looks like a nice server, but to be honest I would remove this. > Serving non-standards is not what Gemini is about imo, and it's how > the Web became what it is today. And clients in general should be > strict and not accept things out-of-spec. For example Amfora won't > allow non-standard status codes, even if the first digit matches a > known code. It doesn't check for non-standard MIME params, but maybe > it should? So what are the standard MIME parameters for text/plain? text/markdown? text/html? multipart/alternate? And what should a client do when it encounters a non-standard MIME parameter? -spc
November 6, 2020 11:15 PM, colecmac at protonmail.com wrote: > It looks like a nice server, but to be honest I would remove this. > Serving non-standards is not what Gemini is about imo, and it's how > the Web became what it is today. And clients in general should be > strict and not accept things out-of-spec. For example Amfora won't > allow non-standard status codes, even if the first digit matches a > known code. It doesn't check for non-standard MIME params, but maybe > it should? I don't agree that clients should be strict, because that adds more trouble onto a client. Take 2 minutes and try to find how to parse MIME types and parameters in Python. ... See how easy that was? Just use a method in the cgi module, or maybe even a third party lib. Now take 2 minutes and try to find a Python library that can tell when a non-standard mimetype parameter is used. ... You probably couldn't find anything. I sure couldn't. This doesn't even take into account the lack of forward compatibility (what happens if a new mimetype gets defined with new parameters? now what, every client *must* update to handle it?) Just my 2 cents, Robert "khuxkm" Miles
On Sat, Nov 7, 2020 at 12:17 AM Sean Conner <sean at conman.org> wrote: So what are the standard MIME parameters for text/plain? If you go to <https://www.iana.org/assignments/media-types/media-types.xhtml>, the IANA registration for MIME-types, you'll find links under text/plain to RFCs 2046 (optional charset parameter), 3676 (optional format and delsp parameters), and 5147 (not sure why it's here; no parameters). text/markdown? > The same process gets you to RFC 7763 (mandatory charset, optional variant). text/html? Charset (optional). > multipart/alternate? Boundary (required) > And what should a client do when it > encounters a non-standard MIME parameter? > Ah. Now that's from RFC 2045: Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize. The last sentence is the critical one. Add any parameters you want, because clients must ignore them. As for parsing, per RFC 2045 just use split() to split by semicolons; the first result is the type/subtype, and on each of the rest, strip out all spaces and then split them on the equal sign to separate name from value. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Do what you will / this Life's a Fiction And is made up of / Contradiction. --William Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201108/6d29 b6f6/attachment.htm>
---