.bay.de
René Wagner
mostly "ops", sometimes doing some "dev" just for the fun of it
From René Wagner to ~rwa/geminispace.info
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.
From René Wagner to ~k1nkreet/public-inbox
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]
From René Wagner to ~k1nkreet/public-inbox
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]
From René Wagner to ~sircmpwn/sr.ht-discuss
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
From René Wagner to ~sircmpwn/sr.ht-discuss
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é
From René Wagner to ~rwa/geminispace.info
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
From René Wagner to ~rwa/geminispace.info
Hi, thanks for your message. This has already been fixed yesterday. :) regards rwa
From René Wagner to ~rwa/geminispace.info
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:
From René Wagner to ~sircmpwn/gmni-devel
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]
From René Wagner to ~sircmpwn/gmni-devel
--- 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]