Redirect loops and mazes

[Bradley D. Thornton]

On 10/17/2019 12:06 AM, plugd wrote:
> Hi Sean,
> 
> Sean Conner writes:
>>   What about content being moved from Gemini to TOR? [1]  Or an archive file
>> that grew too big to be safely served from Gemini so a switch to HTTPS is in
>> order? (and you don't want to break an existing link)
> 
> In these edge cases, wouldn't it be preferable to simply serve up a
> text/gemini page with explicit information re the new link?
> 

I think so.

If the resource is a .gmi file that's been moved to say, a .html or
.gophermap on another protocol then there's almost certainly a link
pointing to the page that has been moved, and that link can be changed
to provide the correct new URL.

In the case of a link where a server redirect to the other protocol and
resource would be performed, again, simply changing the link itself in
the index.gmi would affect this change without having to hijack the
users client, expecting it to be aware of different protocols itself.

In the case where a resource has been moved and may have had outside
referrers, a .gmi file with a link to the new URL will retain control
over the action by the client.

So for those, I still don't see a compelling use case for out of band
server-side redirects.

But what if the resource is say, an iso file, and that image has been
moved somewhere else? I'm thinking an in-band server redirect to a .gmi
file explaining the new location along with a link would be better than
an out of band redirect to some other protocol.

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268