Add an easy way to keep track of `52 gone` files

[shtrophic]

Hey there. Gemini spec says about return code 52:

The resource requested is no longer available and will not be available again. Search engines and similar tools should remove this resource from their indices. Content aggregators should stop requesting the resource and convey to their human users that the subscribed resource is gone.

Now, implementing this with gmid seems cumbersome to me, as the only possibility I see is for a location block matching all gone files to then block return 52 [...]. I don't think this either scales well nor is the intended use of the location directive.

What about adding an option where there is a section in gmid.conf, similar to types where you list files or locations that when accessed return 52.

Something like:

goners {
    /that-post-i-didnt-like.gmi
    /posts-that-i-didnt-like/*
    include /path/to/file/with/posts/i/didnt/like.txt
}

What do you think? Then, it would be easy to either edit gmid.conf or the included "gonerfile" and then reload with SIGHUP.

[omar-polo]

hello @Sir-Photch

I like the idea to allow administrators to easily return 52 Gone instead of 51 Not Found.

If we go with a goners block, it has to be per-virtual host at least, but I'm wondering if we shouldn't extend location to multiple matches. Maybe it's orthogonal to this issue, but at least with OpenBSD httpd I've recently missed a way to express a match for multiple patterns easily.

Also, in #41 I was thinking of adding a way to define collections of data in separate files and reuse them across the config (the scope of that issue is just for CRLs and allowlists, but could be expanded.) Something similar to OpenSMTPD' tables.

Maybe I'm just exaggerating, but maybe something like this could work out?

table goners file:/path/to/file
# or maybe inline
table goners {
	/that-post-i-didnt-like.gmi
	/posts-that-i-didnt-like/*
}

server example.org {
	# ...
	location <goners> {
		block return 52
	}
}

(side note: I'm also regretting that we don't have a way to capture a submatch in location and reuse it in a block return. it could be very useful for batch redirects)

This has the issue that it's always obvious from the configuration when a location would match, since it depends on the content of a table, but for the intended use cases could be very helpful in reducing the clutters. Think also about proxying only certain paths (or the opposite.)

What do you think?

[shtrophic]

Your table approach would be more flexible so I suppose it to be the right way to do it.
A future gmidctl could then also be used to alter these tables...