[SPEC] Encouraging HTTP Proxies to support Gemini hosts self-blacklisting

[Mansfield]

# Overview

I like the idea of supporting the creating-users freedom to choose to have
their content only accessible through the gemini protocol. (Of course this
support only goes so far - once content is available, it's available.
Stopping someone from taking what you've made available and doing what they
will with it... short of a legal license and litigation... ugh.)

So... I have an HTTP Proxy and, while I provide a robots.txt, I'd like to
explore going a step further. I'd like to provide a URL path prefix like:
/internal/blacklist

The process I'm thinking of is explained in more detail below, but the
result would be that the HTTP Proxy refuses to forward requests to
self-blacklisted Gemini hosts.


# An Example

Before the process, going to https://gem.ondollo.com/external/ondollo.com
would return the gemini/text content available at gemini://ondollo.com to
the requesting web browser.

After the process, going to https://gem.ondollo.com/external/ondollo.com
would *not* return the gemini/text content available at gemini://ondollo.com

Maybe the proxy could instead return a page that says... "The owner of this
content has requested that it only be accessible through the gemini
protocol and we respect that. Please use a Gemini client to access content
at gemini://ondollo.com. Here are some recommended clients: <list of one or
more clients>"

... or... the HTTP Proxy could just 404? 400? 204 Success and no content?
301 Moved permanently with a gemini URI? 403 Forbidden (not a *user* authz
issue... but a *proxy* authz issue...)? 410 Gone? 451 Legal? (As an aside:
there is a part of me that loves discussions/debates around what the right
HTTP status code is for a given situation... there's another part of me
that dies every time...)

I think I'll go for a 200 HTTP status and content that explains what
happened and encourages the user to access the content through gemini.


# A Possible Request Response Sequence

Here's a sequence I'm thinking of (given a creating-user and their gemini
server at gemhost, and a consuming-user and their web browser... and the
proxy at proxyhost... and 'somepath' - a sufficiently unique and random URL
path):

 1. The creating-user makes a new document on their server available at
<gemhost>/<somepath> with the content <proxyhost>
 2. The creating-user makes an HTTP GET request to
<proxyhost>/internal/blacklist/<gemhost>/<somepath>
 3. The proxy makes a Gemini request to <gemhost>/<somepath> and gets the
content that matches themself - their own proxyhost value
 4. The proxyhost adds the gemhost to their blacklist
 5. The proxyhost refuses to proxy requests to the gemhost

Thoughts? How would you tweak to get the desired outcome?


# An Alternative

An additional thought I had... the above feels like it might be too process
heavy (but... it's also super simple...). What if proxy server
implementations were encouraged to check gemini://<gemhost>/noproxy.txt
before a request? (Every request? Feels too much like the favicon. The
first request? What if the creating-user changes their mind?) If my proxy
checks that URL and gets a 20 status back, then it refuses to proxy the
connection. If it gets a 51 back, then it continues with proxying the
request.

So... who does the work? Proxy implementers would be encouraged to make
modifications with either approach... but the first approach has no work by
gemini server implementers, just creating-users. The second approach could
have some work by gemini server implementors... but little by
content-users... maybe they toggle a setting in the server to respond with
a 20 to /noproxy.txt requests?

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210221/3685d0f6/attachment.htm>