💾 Archived View for bbs.geminispace.org › s › Gemini › 15697 captured on 2024-08-18 at 22:07:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
Valid Gemini response with invalid media type?
This is an interesting URL:
gemini://gemini.jorl.fi:1965/pub.key
It returns a status code 20, and a META of "text/plain\n" with a literal new line. A \r\n follows this, so per the Gemini spec, the META field contains a trailing \n character.
The Gemini spec says that "For [SUCCESS status] responses, <META> is a MIME media type as defined in RFC 2046." RFC-2046 defines the media type as part of the grammar for a `Content-Type` header:
https://www.rfc-editor.org/rfc/rfc2045#section-5.1
However it says nothing about leading or trailing whitespace in a media type definition. FWIW, passing ""text/plain\n" with a literal new line to C#'s standard mime parsing classes generates a Format Exception.
This makes me wonder about what valid 20 responses look like. If I send `20 ACIDUS` well "ACIDUS" is not a valid mime type as defined by RFC2046 (it lacks a type, a '/' literal, and a subtype). Is this an invalid Gemini response per the spec, or a valid response with just an invalid mimetype?
In other words, does a valid SUCCESS response require a valid mime media type? If so, what kind of error should a client display?
(All of this is assuming a non-empty META. The spec allows empty META, so a response of "20\s" means a success response with a media type of "text/gemini" and a charset of "utf-8". My questions is about a non-empty META with an invalidly formatted MIME media type)
Mar 21 · 5 months ago
You could read the new (in progress) spec to see if you find it clearer. The way I see it, gemini does not allow white space around and "text/plain\n" it's not a valid MIME type either.