Redirect loops and mazes

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> > Is this behaviour really desirable?
> > 
> > I vote for no.  The text/gemini files already support links to
> > non-gemini URLs.  Allowing server-directed redirects to non-gemini URLs
> > would simply mean that I could no longer be sure that a gemini:// URL
> > would access a gemini resource.  Meaning that I could no longer be sure
> > that the transaction is encrypted.  And that's just with gopher - the
> > server could make all sorts of surprising things happen on my computer
> > if the client happens to support other protocols.
> 
> Hmm, good question!
> 
> I share the intuition that cross-protocol redirects violate the
> principle of least surpise, and also make URLs non-transparent.  I mean,
> redirects do that to some extent anyway, which is why some clients (like
> Bombadillo) request explicit confirmation before following any (I may
> add this as a user-specifiable option to AV-98), but cross-protocol
> redirects are arguably as bad as it gets.
> 
> I think I'd be happy to explicitly forbid these in the spec, unless
> somebody can think of a compelling legitimate use case?

  Possible actions:

	client denies the redirect
	client denies redirects to non TLS-protocols
		otherwise, redirects
	client asks to redirect or not
	client asks to redirect to non-TLS protocol,
		othersise redirects,
	client warns user about redirect
	client warns user about redirect to non-TLS protocol
	client does redirect

  I think that covers all possible actions.  If it were left up to me, I
would probably say "ask for redirect to non-TLS, otherwise, warn (or
mention) about redirect".

  -spc