💾 Archived View for gemi.dev › gemini-mailing-list › 000418.gmi captured on 2024-03-21 at 17:34:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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.
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:
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
---
Previous Thread: Trying to play catch-up on clients, authoring, and hosting.