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