Hi,
i have a gemini capsule hostet at pages.sr.ht.
When requesting the capsule with an URI without port everything is fine, but explicitly specifying the port in the request make pages.sr.ht return a `PERMANENT FAILURE 51 File not found`.
Tested with different clients, can be verified via gemini://gmn.clttr.info:1965/
I don't think this is by intent.
regards
René
On Sun, Aug 06, 2023 at 03:41:33PM +0200, René Wagner wrote:
> Hi,> > i have a gemini capsule hostet at pages.sr.ht.> > When requesting the capsule with an URI without port everything is fine, but explicitly specifying the port in the request make pages.sr.ht return a `PERMANENT FAILURE 51 File not found`.> > Tested with different clients, can be verified via gemini://gmn.clttr.info:1965/
Works for me with a patched w3m.
Hi Rene :D
I've tried with the "simplest" client of all - OpenSSL. The results are as shown below.
My understanding is that both requests should serve the some content. This works for most capsulses/servers
out there, but not for sr.ht hosted capsules.
$ echo "gemini://gmn.clttr.info/" | openssl s_client -connect "gmn.clttr.info:1965" -crlf -quiet
depth=0 CN = *.clttr.info
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = *.clttr.info
verify return:1
20 text/gemini
# landing @ gmn.clttr.info
Welcome to my capsule / Willkommen in meiner Kapsel!
[...]
$ echo "gemini://gmn.clttr.info:1965/" | openssl s_client -connect "gmn.clttr.info:1965" -crlf -quiet
depth=0 CN = *.clttr.info
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = *.clttr.info
verify return:1
51 File not found
regards
René
On Tue, Aug 08, 2023 at 02:31:20PM +0200, René Wagner wrote:
> Hi Rene :D> > I've tried with the "simplest" client of all - OpenSSL. The results> are as shown below.> > My understanding is that both requests should serve the some content.> This works for most capsulses/servers out there, but not for sr.ht> hosted capsules.
The specs says in 1.2 Gemini URI scheme:
| Clients SHOULD normalise URIs (as per section 6.2.3 of RFC 3986) before
| sending requests (see section 2) and servers SHOULD normalise received
| URIs before processing a request.
and RFC 3986 in 6.2.3:
| http://example.com
| http://example.com/
| http://example.com:/
| http://example.com:80/
|
| In general, a URI that uses the generic syntax for authority with an
| empty path should be normalized to a path of "/". Likewise, an
| explicit ":port", for which the port is empty or the default for the
| scheme, is equivalent to one where the port and its ":" delimiter are
| elided and thus should be removed by scheme-based normalization. For
| example, the second URI above is the normal form for the "http"
| scheme.
[...]
> $ echo "gemini://gmn.clttr.info:1965/" | openssl s_client -connect "gmn.clttr.info:1965" -crlf -quiet> depth=0 CN = *.clttr.info> verify error:num=18:self-signed certificate> verify return:1> depth=0 CN = *.clttr.info> verify return:1> 51 File not found
AFAIU, both parties SHOULD normalise the path. Looks like neither one
does here.