-- Leo's gemini proxy

-- Connecting to gemi.dev:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

Yeah, I know I'm asking a lot at this point, bear with me please, I'd
just like have a little clarification.

I was browsing gemspace using netcat just to get a feel the typical
responses, and how others write gemtext, and first thing I noticed is in
gemini://gemini.circumlunar.space/ the index page has link lines with
label separators of multiple whitespace characters, so I referred back
to the spec to see if I missed something, and indeed I did, 5.4.2 says
"<whitespace> is any non-zero number of consecutive spaces or tabs",
and I noted that, now I'm wondering if this applies to headings to,
as in the whitespace after #, ## and ###.

Ali Fardan <raiz at stellarbound.space> wrote:

>
> now I'm wondering if this applies to headings to,
> as in the whitespace after #, ## and ###.
>

Yes, you can line them up if you want. Like so:

 ```
#   Heading 1
##  Heading 1:1
### Heading 1:1:1
 ```

--
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/6a1e
81e1/attachment.htm>

On 2020-10-27 06:36, Katarina Eriksson wrote:
> Ali Fardan <raiz at stellarbound.space> wrote:
>
>>
>> now I'm wondering if this applies to headings to,
>> as in the whitespace after #, ## and ###.
>>
>
> Yes, you can line them up if you want. Like so:
>
> ```
> #   Heading 1
> ##  Heading 1:1
> ### Heading 1:1:1
> ```

Thanks for clarifying.

On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space> wrote:
> I was browsing gemspace using netcat ...

This made me curious so I started up netcat. According to the spec,
the request is `<URI> <CR> <LF>`. I thought this was correct, but I
just lose the connection when sending the line feed:

 ```
$ nc gemini.circumlunar.space 1965
gemini://gemini.circumlunar.space/
$
 ```

Any suggestions?

--
jeff

On Wed Oct 28, 2020 at 10:58 AM EDT, Jeffrey Horn wrote:
> On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space>
> wrote:
> > I was browsing gemspace using netcat ...
>
> This made me curious so I started up netcat. According to the spec,
> the request is `<URI> <CR> <LF>`. I thought this was correct, but I
> just lose the connection when sending the line feed:

SSL. Try this:

openssl s_client -servername example.org -connect example.org:1965

On Wed, Oct 28, 2020 at 11:00 AM Drew DeVault <sir at cmpwn.com> wrote:
> openssl s_client -servername example.org -connect example.org:1965

This worked well, thank you!

--
jeff

Jeffrey Horn <jrhorn424 at gmail.com> writes:

Hi, I don't think netcat does tls.  One thing you could do is to use
openssl:

#+begin_src bash
echo -e "gemini://gemini.circumlunar.space:1965/\r\n" | openssl s_client
-connect gemini.circumlunar.space:1965 -ign_eof
#+end_src

this command establishes a connection, sends <URL><CR><LF> and then
reads the response ("20 text/gemini")



> On Sun, Oct 25, 2020 at 7:02 AM Ali Fardan <raiz at stellarbound.space> wrote:
>> I was browsing gemspace using netcat ...
>
> This made me curious so I started up netcat. According to the spec,
> the request is `<URI> <CR> <LF>`. I thought this was correct, but I
> just lose the connection when sending the line feed:
>
> ```
> $ nc gemini.circumlunar.space 1965
> gemini://gemini.circumlunar.space/
> $
> ```
>
> Any suggestions?
>
> --
> jeff

On OpenBSD, I tried (after having a quick read of nc manpage) this:


$ nc -cv -Tnoverify gemini.circumlunar.space 1965


Well, when first I typed in

gemini.circumlunar.space

in that, I got an 53. Then I tried

gemini://gemini.circumlunar.space

and got

31 gemini://gemini.circumlunar.space/

and then did ''as directed'' to get the real page.

Why was I getting 53 there? Any idea?

On Wed Oct 28, 2020 at 11:57 AM EDT, Sudipto Mallick wrote:
> On OpenBSD, I tried (after having a quick read of nc manpage) this:
>
> Well, when first I typed in
>
> gemini.circumlunar.space
>
> in that, I got an 53. Then I tried
>
> Why was I getting 53 there? Any idea?

A properly formed gemini request is a fully qualified URL with a scheme
and authority.

Hope that helps!

Chris

On 10/28/20, Chris Vittal <chris at vittal.dev> wrote:
> A properly formed gemini request is a fully qualified URL with a scheme
> and authority.

Let me quote from the Gemini protocol specification:

2 Gemini Requests

Gemini requests are a single CRLF-terminated line with the following structure:

<URL><CR><LF>

<URL> is a UTF-8 encoded absolute URL, of maximum length 1024 bytes.
**If the scheme of the URL is not specified, a scheme of gemini:// is
implied.**
(Emphasis mine.)

Please clarify what should it be.

On Wed, 28 Oct 2020 12:04:28 -0400
"Chris Vittal" <chris at vittal.dev> wrote:

> A properly formed gemini request is a fully qualified URL with a scheme
> and authority.

Not in this case. In a request, it is only necessary to specify the
authority and optionally a path. From the spec (0.14.2):

> If the scheme of the URL is not specified, a scheme of gemini:// is
> implied.

So the server really should treat both requests as equivalent.

Furthermore, I think it's wrong of the server not to serve the same
resource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".
The spec says that the URI is syntactically compatible with the generic
URI syntax except that the userinfo subcomponent of the generic
authority is not allowed. Serving different content for "/" and
unspecified path is another difference from the generic URI syntax that
is not specified. RFC 3986:

> In general, a URI that uses the generic syntax for authority with an
> empty path should be normalized to a path of "/".

This is a should and not a must, but I also think it's bad behavior
practically to force a client to make another request for something
that should really be an implementation detail in the server. I also
don't see any practical reasons one might want to distinguish the two.

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201028/31ef
aa61/attachment.sig>

On Wed Oct 28, 2020 at 1:49 PM EDT, Philip Linde wrote:
> On Wed, 28 Oct 2020 12:04:28 -0400
> "Chris Vittal" <chris at vittal.dev> wrote:
>
> > A properly formed gemini request is a fully qualified URL with a scheme
> > and authority.
>
> Not in this case. In a request, it is only necessary to specify the
> authority and optionally a path. From the spec (0.14.2):
>
> > If the scheme of the URL is not specified, a scheme of gemini:// is
> > implied.
>
> So the server really should treat both requests as equivalent.

I believe that the reason this doesn't work is because
"gemini.circumlunar.space" is treated as a relative path with no
authority. Making a request for "//gemini.circumlunar.space" works.
Perhaps this should be clarified in the specification.
Or perhaps schemes should always be required to avoid confusion.

> **If the scheme of the URL is not specified, a scheme of gemini:// is
> implied.**
> (Emphasis mine.)

That is correct. I misspoke. Apologies

The issue here is that the URL text of 'gemini.circumlunar.space' is not
an absolute URL. It has no scheme, no authority, and a path of
'gemini.circumlunar.space'. The spec does state that the scheme is
unnecessary, but the authority is.

 From the spec:
> This scheme is syntactically compatible with the generic URI syntax
defined in RFC 3986, but does not support all components of the generic
syntax. In particular, the authority component is allowed and required
Even setting the scheme to gemini, 'gemini.circumlunar.space' would be
treated as 'gemini:gemini.circumlunar.space', so still with no
authority, rather than what we want, which would be
'gemini://gemini.circumlunar.space' stripping the scheme off of this, we
get '//gemini.circumlunar.space' which I have no idea if servers will
properly handle.

Chris

On Wed, 28 Oct 2020 13:51:50 -0400
Chris Vittal <chris at vittal.dev> wrote:

> The issue here is that the URL text of 'gemini.circumlunar.space' is not
> an absolute URL. It has no scheme, no authority, and a path of
> 'gemini.circumlunar.space'. The spec does state that the scheme is
> unnecessary, but the authority is.

I think the confusion around this stems from the phrasing in the Gemini
spec where on one hand it says that the scheme may be omitted but on
the other hand that in that case "gemini://" is implied, which in its
whole is more than just the scheme.

Strictly speaking, ":" is not part of the scheme, (and "//" is not part
of the authority), so what we'd really end up with when omitting the
scheme from the absolute URI is "://gemini.circumlunar.space".

"//gemini.circumlunar.space" is only defined in RFC 3986 as a "relative
reference" as opposed to an "absolute URI".

The Gemini spec could really use some clarification here, guided by a
careful reading of RFC 3986 in order to get the terminology right and
define the allowed syntax in those terms.

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201028/76f7
9d98/attachment.sig>

Netcat (ncat) does support SSL connections with the --ssl flag.

Here's my little "gemget" Guile script I wrote that lets me poke around
Geminispace from the command line whenever I'm not inside a proper
Gemini client. It's also useful for scripting in situations where you
might use wget with HTTP(S).

-----------------------------------------------------------------------------
#!/usr/bin/env guile
!#

(let ((args (command-line)))
  (if (not (= 2 (length args)))
      (display "Usage: gemget <GEMINI_URL>\n")
      (let ((url (cadr args)))
        (if (not (string-prefix? "gemini://" url))
            (display "GEMINI_URL should begin with gemini://\n")
            (let ((server (caddr (string-split url #\/))))
              (system (simple-format #f "echo ~S | ncat --ssl ~S 1965" url server)))))))
-----------------------------------------------------------------------------

Just save this in a file called gemget somewhere on your PATH and you
can use it like this:

-----------------------------------------------------------------------------
gjohnson at euclid ~ $ gemget gemini://gemini.circumlunar.space/
20 text/gemini
# Project Gemini

## Overview

Gemini is a new internet protocol which:

* Is heavier than gopher
* Is lighter than the web
* Will not replace either
* Strives for maximum power to weight ratio
* Takes user privacy very seriously

## Resources

=> docs/	Gemini documentation
=> software/	Gemini software
=> servers/	Known Gemini servers
=> https://lists.orbitalfox.eu/listinfo/gemini	Gemini mailing list
=> gemini://gemini.conman.org/test/torture/	Gemini client torture test

## Web proxies

=> https://portal.mozz.us/?url=gemini%3A%2F%2Fgemini.circumlunar.space%2F&f
mt=fixed	Gemini-to-web proxy service
=> https://proxy.vulpes.one/gemini/gemini.circumlunar.space	Another
Gemini-to-web proxy service

## Search engines

=> gemini://gus.guru/	Gemini Universal Search engine
=> gemini://houston.coder.town	Houston search engine

## Geminispace aggregators

=> capcom/	CAPCOM
=> gemini://rawtext.club:1965/~sloum/spacewalk.gmi	Spacewalk

## Gemini mirrors of web resources

=> gemini://gempaper.strangled.net/mirrorlist/	A list of mirrored services

## Free Gemini hosting

=> users/	Users with Gemini content on this server
-----------------------------------------------------------------------------

Have fun and happy hacking!
  Gary

--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

On Wed Oct 28, 2020 at 3:20 PM EDT, Gary Johnson wrote:
> Netcat (ncat) does support SSL connections with the --ssl flag.

Only GNU netcat, also known as worst netcat.

On 10/29/20, Drew DeVault <sir at cmpwn.com> wrote:
> On Wed Oct 28, 2020 at 3:20 PM EDT, Gary Johnson wrote:
>> Netcat (ncat) does support SSL connections with the --ssl flag.
>
> Only GNU netcat, also known as worst netcat.
>
The OpenBSD netcat supports TLS with the -c flag.

By the way, how lucky am I?! https://builds.sr.ht/~smallick/job/330000

On Wed Oct 28, 2020 at 4:01 PM EDT, Sudipto Mallick wrote:
> The OpenBSD netcat supports TLS with the -c flag.

Hm, not my distribution of OpenBSD netcat.

> By the way, how lucky am I?! https://builds.sr.ht/~smallick/job/330000

Not as lucky as 333333 will be

It was thus said that the Great Philip Linde once stated:
> On Wed, 28 Oct 2020 12:04:28 -0400
> "Chris Vittal" <chris at vittal.dev> wrote:
>
> > A properly formed gemini request is a fully qualified URL with a scheme
> > and authority.
>
> Not in this case. In a request, it is only necessary to specify the
> authority and optionally a path. From the spec (0.14.2):
>
> > If the scheme of the URL is not specified, a scheme of gemini:// is
> > implied.
>
> So the server really should treat both requests as equivalent.

  The specification is technically incorrect, at least in my reading of the
RFC and specifically of the BNF of the URL (I say, having written a URL
parser based closely on the BNF [1]).  The BNF starts [2]

   URI-reference = URI / relative-ref

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty

   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

   relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty

  The specification should say:

	If the scheme of the URL is not specified, a scheme of gemini: is
	implied.

> Furthermore, I think it's wrong of the server not to serve the same
> resource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".

  I'm not aware of any server that does otherwise.  There are servers out
there that play around with trailing '/'  elsewhere in the URL [3], but not
at the root.

  -spc

[1]	https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

[2]	The URI-reference rule is listed third---I think this is a mistake
	on the part of the RFC,

[3]	gemini://gemini.conman.org/test/doc1
	gemini://gemini.conman.org/test/doc1/

On Wed, 28 Oct 2020 17:59:21 -0400
Sean Conner <sean at conman.org> wrote:

>   The specification should say:
>
> 	If the scheme of the URL is not specified, a scheme of gemini: is
> 	implied.
>

The colon also isn't part of the scheme, but the URI as a whole. If one
can omit both the scheme and the colon, then the slightly adjusted
"absolute URL" becomes what RFC 3986 calls a "relative reference",
e.g. "//gemini.circumlunar.space". Omitting the scheme from an absolute
URI (which I assume is what the Gemini spec refers to with
"absolute URL") would leave us with "://gemini.circumlunar.space".

Both our conclusions require similarly liberal interpretation of the
Gemini spec, though your interpretation is easier to describe in terms
of modifications to the rules already defined in RFC 3986.

>   I'm not aware of any server that does otherwise.  There are servers out
> there that play around with trailing '/'  elsewhere in the URL [3], but not
> at the root.

As demonstrated by Sudipto Mallick above, gemini.circumlunar.space does
otherwise. Request "gemini://gemini.circumlunar.space" and you get one
response (a 31 redirect code), but if you request
"gemini://gemini.circumlunar.space/" you get a code 20 response with
the landing page. The URIs are not treated as equivalent, which they
should be after normalization.

The path isn't normalized in the same way, so it's not a concern there.

> [2]	The URI-reference rule is listed third---I think this is a mistake
> 	on the part of the RFC,

The order of the ABNF rules in the appendix bears no significance to
their interpretation. The rule named "URI" defines the URI syntax. The
rule named "URI-reference" defines a syntax for a sequence that is
either a URI or a relative reference. Gemini requests by my
interpretation uses neither, but the rule named "absolute-URI" (to
disallow fragments?), modified so that

  authority = host [ ":" port ]

and with the note about implied scheme, which interpreted literally
would normalize "://example.com" to "gemini://://example.com" and would
accept neither "example.com" nor "//example.com".

By your interpretation (which I agree makes most sense) it is more
succinct and correct to describe the Gemini URL as an RFC 3986 "URI"
with the rules modified so that

  URI           = [ scheme ":" ] hier-part [ "?" query ]
  authority     = host [ ":" port ]

--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201029/0b5b
9bec/attachment-0001.sig>

On 2020-10-28 18:11, Nicol? Balzarotti wrote:
> Jeffrey Horn <jrhorn424 at gmail.com> writes:
> Hi, I don't think netcat does tls.

It does: https://man.openbsd.org/nc#c

-- Response ended

-- Page fetched on Thu May 23 22:29:09 2024