---
 autoload/gemivim.vim | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/autoload/gemivim.vim b/autoload/gemivim.vim
index 0e2d38f..d1e8aeb 100644
--- a/autoload/gemivim.vim
+++ b/autoload/gemivim.vim
@@ -21,8 +21,12 @@ function! s:info_msg(msg)
 endfunction
 
 function! s:tmp_file_name(url, mime_type)
-    let l:file = g:tmp_prefix . substitute(a:url, 'gemini://', '', 'g')
-    if a:mime_type ==# 'text/gemini' && a:url =~# '/$'
[message trimmed]

Hi Brett,

we needed to trigger of full reindex of the known content that caused some trouble.
This is now fixed and we are checking our monitoring.

regards

On Wed Jan 24, 2024 at 2:53 PM CET, Brett Coburn wrote:
> Thanks to m0xee on Station for figuring out the first part of my
> problem and directing me to this list. I can now resolve
> geminispace.info via IPv4, but my searches don't return any results,
> including searches for very generic terms like "test" and "gemini".
> Maybe there is some misconfiguration? Thanks!

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: