Gemini ALPN ID

[martijndeb]

I've adapted the example server to the following code; But i'm unable to connect to it; Kristall browser gives; 'The server timed out while answering your response.' and the console doesn't print out the request log, so it doesn't reach that code.

Now i'm running this under WSL1, which exposes all ports natively to 0.0.0.0, so it should be accessable (other services are). I've found netstat to mark the port as listening tho;

/mnt/c/Users/Martijn# /mnt/c/Windows/System32/netstat.exe -an | grep -i "listen" | grep -v "[::]" | grep 1965 TCP 0.0.0.0:1965 0.0.0.0:0 LISTENING

Do you see anything that jumps out?

'use strict'

const createCert = require( 'create-cert' );
const gemini = require( '@derhuerst/gemini' );

const onRequest = ( req, res ) => {
    console.log( 'request', req.url );

    if ( req.clientFingerprint ) {
        console.log( ' -> client fingerprint: ', req.clientFingerprint );
    }

    res.write( 'Hello world' );
    res.end( '!' );
}

const onError = ( fehler ) => {
    console.error( fehler );
    process.exit( 1 );
}

createCert( 'farmstead.test' ).then( ( keys ) => {

    const gServer = gemini.createServer( {
        tlsOpt: keys
    }, onRequest );

    gServer.on( 'error', onError );
    gServer.listen( 1965, ( fehler ) => {
        if ( fehler ) {
            return onError( fehler );
        }

        console.info( 'Started Farmsteading' );
    });
} );

[derhuerst]

Just to make sure, this is not due to the self-signed certificate that TLS clients usually don't trust by default? As you can see in examples/client.js, in Node.js one has to pass rejectUnauthorized: false.

[martijndeb]

I've now tried the client.js with that option, and av98 inside Windows and the same WSL host, neither of them seem to be able to connect. av98 immediately closes the connection with "ERROR: Errno[0] Error"

[derhuerst]

Huh, that's not a very helpful error message either.

I can imagine that the TLS handshake because this package uses gemini as ALPN ID, whereas other clients & servers might use a different one or none at all. Can you try without this line?

https://github.com/derhuerst/gemini/blob/5a23ee66f3f0018187a898b3ae4bd609ff9d4e3e/connect.js#L29

[martijndeb]

That seems to connect to my Hello World! I can work with that for now, but will that break other things?

[derhuerst]

FYI I have asked on the mailing list if we should adopt ALPN or drop it.

[derhuerst]

I don't know how to reply to the ALPN thread from a mailman digest email, so I'll just comment here:

It seems like a hack that just exists so that HTTP2 can work efficiently while still keeping the old http:// scheme.

Agreed. The client already knows that it has accessed a gemini:// URI. The server knows what the client is asking for.

This is only true if you assume that there's only one version of one protocol exposed per port.

From what I understand, ALPN was invented (by Google) pretty much just for clients and servers to decide early whether to user HTTP2 or not.

Although it was invented for that reason, it seems to provide more value than just telling apart HTTP1 & HTTP2: To solve the problem of protocol negotiation properly, at TLS level (which acts as the transport layer in this case). Not sure if they are being used, but there are other ALPN IDs registered than for HTTP (FTP, MQTT, IMAP, POP3, STUN, TURN).

[derhuerst]

@sexybiggetje PR welcome that comments out the gemini ALPN ID and adds a comment referring to this Issue.

[derhuerst]

Published as @derhuerst/gemini@1.0.4. 🎉