Hi,

thanks for your message. The URIs have been removed from the storage, index will be updated within an hour or so.
We'll crawl the capsule by default with the next crawler run.

Adding a bookmark for the url under the cursor is now available per
command "GemivimAddCursorBookmark".
Additionally removing of bookmarks is exposed via the newly introduced
"GemivimRemoveBookmark" and "GemivimRemoveCursorBookmark" commands.
---
 README.md            |  5 ++++-
 autoload/gemivim.vim | 25 ++++++++++++++++++++++++-
 plugin/gemivim.vim   |  3 +++
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 5d1d18e..4110db1 100644
--- a/README.md
+++ b/README.md
[message trimmed]

Relative links without prefix and relative links with ./ prefix
were treated incorrect, leading to wrong URIs being generated.

Due to a drift to dynamic capsules backed by CGI scripts some assumptions needed to be revised:
- getting the current URI with <cfile> led to query strings being skipped.
- appending index.gmi whenever a file does not end with .gmi did not honor
query strings as well, that results in strange file names.
Both issues have been fixed.
---
 autoload/gemivim.vim | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/autoload/gemivim.vim b/autoload/gemivim.vim
index cecb652..6394e10 100644
[message trimmed]

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

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é

Hi,

usually defunct links will be removed after 30 days (plus a few days depending on recrawl intervall).

I've manually removed the capsule you mentioned a few weeks ago.

regards
rwa

Hi,

thanks for your message. This has already been fixed yesterday. :)

regards
rwa

Hi Javier,

> and I got it working until last Thursday (the 26th).
> But today, when I was about  release my fix, I noticed it didn't work anymore.
We've installed some updates on Thursday, both for the Debian base system
as well as updated python dependencies.

> I tried building my own version of geminispace.info to debug it but I
> can't reproduce it that way, it works fine. I would appreciate it if
> someone with access to the server can help me debug this by looking at
> the logs. I just made a bunch of requests to
> "gemini://geminispace.info/42cgierror" so the requests are easy to find.

this is a stack trace of one of the requests:

Otherwise we end up using the client certificate
of a previous request and the current request will
fail with a SSL error 26.
---
closes ~sircmpwn/gmni#67

 src/client.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/client.c b/src/client.c
index 127a56c..0044122 100644
--- a/src/client.c
+++ b/src/client.c
@@ -187,6 +187,8 @@ gemini_request(const char *url, struct gemini_options *options,
[message trimmed]

---
In download_resp() the length check for the default
path handler checked the wrong buffer...missed that
one in the last patch.

 src/util.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/util.c b/src/util.c
index dd1fa37..45704e7 100644
--- a/src/util.c
+++ b/src/util.c
@@ -82,9 +82,9 @@ download_resp(FILE *out, struct gemini_response resp, const char *path,
 		}
[message trimmed]