💾 Archived View for rawtext.club › ~sloum › geminilist › 005841.gmi captured on 2023-09-08 at 17:11:59. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[announce] Delegation of responsibility for spec finalisation

Juan J. Martinez jjm at usebox.net

Tue Mar 2 08:09:03 GMT 2021

- - - - - - - - - - - - - - - - - - -

On 02/03/2021 00:23, Scot wrote:

[...]

After writing C and Python client and server implementations

last fall, and examing packet traces, my conclusion was that

this does not work with most TLS libraries. Mostly, they will

close the connection in both directions if they receive a

close_notify. Some of this is documented here [1]. This in

turn causes problems for programming languages which

expect a given library to behave in a certain way. For example,

Python still does not allow sending a close_notify from the

client after the request has been delivered and before

receiving the response [2].

So, in my opinion, the simplest thing would be to utilize the

<CR><LF> of the Gemini request to indicate that the client

is finished sending its request.

Three benefits of this approach would be:

1. All Gemini clients will keep working right now without changes

2. Because the <CR><LF> can be explicitely sent by a client

application and explicetely examined by the server application,

without broken TLS libraries intervening, it is easy to correctly

implement

3. Gemini client authors will not experience intense frustration

at the sad state of TLS library support for half-open close_notify

(this is the voice of experience speaking...)

I'm not in any way a TLS expert, but I think you're right: TLS 1.2 uses a duplex-close policy (while TLS 1.3 uses a half-close policy, so that should work better).

IMHO the spec should probably refer to the RFC when available and perhaps make a recommendation, but getting into specific details on how the TLS implementation must behave is hairy and probably not practical.

As long as the spec is clear, real world can differ and still work, and that's OK.

Regards,

Juan

-- Website: usebox.net/jjm/Twitter: @reidrac