~rwa

.bay.de

https://clttr.info

mostly "ops", sometimes doing some "dev" just for the fun of it

Mastodon

Gemini Space

#43 gmni: build error [-Werror=stringop-overflow=] 20 days ago

Comment by ~rwa on ~sircmpwn/gmni

already fixed:

#41 Possible buffer overflows in download_resp 20 days ago

Comment by ~rwa on ~sircmpwn/gmni

I think this is already fixed: https://git.sr.ht/~sircmpwn/gmni/tree/master/item/src/util.c#L85

#21 Don't split UTF-8 chars across lines a month ago

Comment by ~rwa on ~sircmpwn/gmni

This issue probably also leads to the behaviour that lines with multibyte UTF-8 characters are wrapped too early cause every byte is counted as a char.

#47 gmnisrv: improve cgi handling when x permission is missing a month ago

on ~sircmpwn/gmni

REPORTED RESOLVED FIXED

#46 gmnisrv: "freeze" when a cgi-enabled URI is accessed with missing index file 2 months ago

on ~sircmpwn/gmni

RESOLVED FIXED REPORTED

#46 gmnisrv: "freeze" when a cgi-enabled URI is accessed with missing index file 2 months ago

Comment by ~rwa on ~sircmpwn/gmni

Not fixed for me as of 02a386b5

#47 gmnisrv: improve cgi handling when x permission is missing 2 months ago

Ticket created by ~rwa on ~sircmpwn/gmni

When gmnisrv tries to serve a cgi script that misses the +x permission for the gmnisrv user the following happens:

  • error execlp: Permission denied is logged -> fine
  • no response to the client is sent -> should be a status 42 or more likely 50
  • a [defunct] fork of gmnisrv stays as long as the main process is not closed

#46 gmnisrv: "freeze" when a cgi-enabled URI is accessed with missing index file 2 months ago

Comment by ~rwa on ~sircmpwn/gmni

I tracked it down to the special handling of cgi-enabled routes, when the requested file does not exist. But to be honest: i currently don't get behind the idea of this special handling, but there's a strange feeling it might be there for a reason.

diff --git a/src/serve.c b/src/serve.c
index 74bb979..11bcb0c 100644
--- a/src/serve.c
+++ b/src/serve.c
@@ -398,32 +398,6 @@ serve_request(struct gmnisrv_client *client)
        struct stat st;
        while (true) {
                if ((n = stat(real_path, &st)) != 0) {
-                       if (route->cgi) {
-                               const char *new;
-                               strcpy(temp_path, client_path);
-                               new = basename((char *)temp_path);
-
-                               size_t l = strlen(new), q = strlen(pathinfo);
-                               memmove(&pathinfo[l + 1], pathinfo, q);
-                               pathinfo[0] = '/';
-                               memcpy(&pathinfo[1], new, l);
-
-                               strcpy(temp_path, client_path);
-                               new = dirname((char *)temp_path);
-                               strcpy(client_path, new);
-
-                               strcpy(temp_path, real_path);
-                               new = dirname((char *)temp_path);
-                               strcpy(real_path, new);
-
-                               if (route_match(route, client_path, &url_path)) {
-                                       n = snprintf(real_path, sizeof(real_path),
-                                               "%s%s", route->root, url_path);
-                                       assert((size_t)n < sizeof(real_path));
-                                       continue;
-                               }
-                       }
-
                        client_submit_response(client,
                                GEMINI_STATUS_NOT_FOUND, "Not found", NULL);
                        return;

#46 gmnisrv: "freeze" when a cgi-enabled URI is accessed with missing index file 2 months ago

Ticket created by ~rwa on ~sircmpwn/gmni

gmnisrv "freezes" when you access a route with cgi=on, no index specified in the config and the called URI does not contain a path to a cgi script.

E.g. you only have a script.sh in the root dir and call gemini://gemini.capsule (instead of gemini://gemini.capsule/script.sh).

Expected behaviour is to return a 51 NOT FOUND.

I assume currently it gets stuck in serve_request and does not respond to any request (no matter which route is accessed).

#42 First paragraph of text put above ToC 4 months ago

Comment by ~rwa on ~sircmpwn/man.sr.ht

I came across this "issue" as well, but it may be "by design" when you think about it this way:

title

first paragraph, introduction to the page

table of contents

content