Illusory latency due to trailing slash redirects

[Charles E. Lehner]

On Sat, 27 Jun 2020 08:57:14 +0000
solderpunk <solderpunk at SDF.ORG> wrote:

> On the server side, server authors should take care when doing things
> like automatically generating directory listings to put trailing
> slashes in links to directories so that the redirect is not necessary.

Search engines and link aggregators could also help.

For example, GUS has this entry:
  gemini://gemini.circumlunar.space/servers
which is a redirect to:
  gemini://gemini.circumlunar.space/servers/

The search engine could try to detect that kind of redirect during the
crawl and update the entry.

On Sat, 27 Jun 2020 11:42:39 +0200
Philip Linde <linde.philip at gmail.com> wrote:

> A server that serves different content on //server and //server/ can
> be a huge pain in the neck. When I wrote my dillo plugin I noticed
> that it seems to apply this normalization in reverse before the URL
> is handed to the plugin. So "gemini://example.horse/" could only be
> seen on the plugin end as "gemini://example.horse", which also makes
> redirects to "gemini://example.horse/" loop back to
> "gemini://example.horse/". Redirect hell ensued!

I also noticed this. Dillo uses whichever URL was loaded first in the
session (with or without the "/"). It caches the resulting resource,
with the normalized URL as the cache key. So if you visit
"gemini://example.horse" first, then subsequently visiting
"gemini://example.horse/" retrieves the cached response for
"gemini://example.horse". And you can't remove the cache entry except
by starting a new Dillo process.

Since servers are redirecting "" to "/", I think adding the "/" in the
plugin like you are doing is the right thing to do, to work around what
I now consider a bug in Dillo. In the older dillo-gemini plugin, I did
not think to do that, but instead made redirects not automatic but just
an internal page with a link to the target URL (i.e. require user
confirmation) and work around the cache/normalization problem as a
user by manually adding a query string to the URL to get a new cache
key, e.g. visiting "gemini://example.horse/?"

-- 
Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200627/2dc0b44e/attachment.sig>