💾 Archived View for gemi.dev › gemini-mailing-list › 000137.gmi captured on 2023-12-28 at 15:41:45. Gemini links have been rewritten to link to archived content
View Raw
More Information
⬅️ Previous capture (2023-11-04)
🚧 View Differences
-=-=-=-=-=-=-
[SPEC-CHANGE] Small housekeeping updates
- 📧 Messages: 5
- 🗣️ Authors: 3
- 📅 First Message: 2020-05-23 10:26
- 📅 Last Message: 2020-05-24 14:31
1. solderpunk (solderpunk (a) SDF.ORG)
- 📅 Sent: 2020-05-23 10:26
- 📧 Message 1 of 5
Ahoy!
I pushed some small changes to the Gemini specification this morning,
which you can see at:
- gemini://gemini.circumlunar.space/docs/spec-spec.txt
- gopher://gemini.circumlunar.space/0/docs/spec-spec.txt
- https://gemini.circumlunar.space/docs/spec-spec.txt
These are fairly small, house-keeping style changes being made in
advance of the formal "unfreezing" of the spec come June. Most
server/client implementations should need only minor changes if any to
keep up with these, but authors, please do check/test rather than
assuming!
SUMMARY OF CHANGES:
Response headers now must use only a single space character to separate
the <META> content from the status code, instead of a mix of one-or-more
spaces and tabs (see section 1.3.1). This means the maximum size of a
valid response header is now 1029 bytes (including the CRLF), whereas
before it was unbounded.
It is now specified that content with a text/* media type may be
transferred via Gemini using bare LF line separators as well as the
canonical CRLF (see section 1.3.3).
Use of the Server Name Indication (SNI) extension to TLS is now
mandatory (see section 1.4)
IMPLICATIONS FOR SERVER AUTHORS:
If your server is using a tab character to separate status codes from
<META> content, you MUST switch to using a space.
IMPLICATIONS FOR CLIENT AUTHORS:
Client authors of a Postelian inclination probably don't need to change
anything in response to the change of response headers. If you really
want to you MAY refuse to parse headers using non-compliant whitespace,
but this will probably just require adding ugly code for little
benefit.
Check that your client can handle text/gemini content with
CRLF-separated lines without visibly displaying the CR. If you are
using built-in line splitting tools from your programming languages
standard library, chances are very good you are already fine in this
regard.
If your client is not using SNI, you MUST start using it.
IMPLICATIONS FOR CONTENT AUTHORS:
If you author your Gemini content on a pre-OS X Apple computer, '70s or
'80s vintage 8-bit microcomputer or MIT LISP machine, you should take
care to convert your line endings to CR or CRLF before uploading it to
your server of choice, or write your own server which does the
conversion before you. Please let the list know more about your amazing
life decisions!
Cheers,
Solderpunk
Link to individual message.
2. Katarina Eriksson (gmym (a) coopdot.com)
- 📅 Sent: 2020-05-23 14:18
- 📧 Message 2 of 5
solderpunk <solderpunk at sdf.org> wrote:
> If you author your Gemini content on a pre-OS X Apple computer, '70s or
> '80s vintage 8-bit microcomputer or MIT LISP machine, you should take
> care to convert your line endings to CR or CRLF before uploading it to
> your server of choice, or write your own server which does the
> conversion before you. Please let the list know more about your amazing
> life decisions!
>
You mean "convert your line endings to LF or CRLF", right?
--
Katarina
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200523/b786
0ca0/attachment.htm>
Link to individual message.
3. solderpunk (solderpunk (a) SDF.ORG)
- 📅 Sent: 2020-05-23 14:58
- 📧 Message 3 of 5
On Sat, May 23, 2020 at 04:18:24PM +0200, Katarina Eriksson wrote:
> solderpunk <solderpunk at sdf.org> wrote:
>
> > If you author your Gemini content on a pre-OS X Apple computer, '70s or
> > '80s vintage 8-bit microcomputer or MIT LISP machine, you should take
> > care to convert your line endings to CR or CRLF before uploading it to
> > your server of choice, or write your own server which does the
> > conversion before you. Please let the list know more about your amazing
> > life decisions!
> >
>
> You mean "convert your line endings to LF or CRLF", right?
Darn it, yes, I do. Why do I keep mixing those two up even after
thinking about this obsessively for several days?
Cheers,
Solderpunk
Link to individual message.
4. Martin Keegan (martin (a) no.ucant.org)
- 📅 Sent: 2020-05-24 00:46
- 📧 Message 4 of 5
On Sat, 23 May 2020, solderpunk wrote:
>> You mean "convert your line endings to LF or CRLF", right?
>
> Darn it, yes, I do. Why do I keep mixing those two up even after
> thinking about this obsessively for several days?
This must be how "CRFL" made its way into the spec ;)
Mk
--
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
Link to individual message.
5. solderpunk (solderpunk (a) SDF.ORG)
- 📅 Sent: 2020-05-24 14:31
- 📧 Message 5 of 5
On Sun, May 24, 2020 at 01:46:55AM +0100, Martin Keegan wrote:
> On Sat, 23 May 2020, solderpunk wrote:
>
> > > You mean "convert your line endings to LF or CRLF", right?
> >
> > Darn it, yes, I do. Why do I keep mixing those two up even after
> > thinking about this obsessively for several days?
>
> This must be how "CRFL" made its way into the spec ;)
Oh, flippin' 'eck! Fixed just now, thanks for pointing this out!
Cheers,
Solderpunk
Link to individual message.
---
Previous Thread: Updates to Gemini best practices
Next Thread: Call for AV-98 testing