Evil forms on other websites could otherwise potentially be configured
to have action="https://gnusocial.example/api/statuses/update.json" or
whatever. XHR is already blocked with CORS stuff.

Really, why do browsers allow cross domain POSTs at all? Sigh. The web.

The risk of injection attacks using HTTP is too great to allow a
site that allows both HTTP and HTTPS...

magnet: would match, but now we have a zero-length lookahead which
requires the following character to be a question mark: magnet:?

Won't work with common_purify yet because there is no geo uri scheme for it

since we'll then get to /user/$id instead of /$nickname which is
good for future archives if someone changes their nickname...

Regular expression + avoid-redirection list now match each other.

Immensely useful when debugging and we want to put quotes around strings,
potentially stopping any "evil logging attacks" (where input data masks
as logging data).

The code was so involved there was even a comment asking for a refactor.

Now, File_redirection::where always returns a nice File_redirection
object instead of an array or string or nothing.  The object is
either one which already existed or else a new, unsaved object.

Instead of duplicating "does it exist" checks everywhere, do it in
File_redirection::where.  You either get what exists or something to save.

An unsaved File_redirection may be paired with an unsaved File.
You will want to save the File first (using ->saveFile()) and put the
id in File_redirection#file_id before saving.

Use an associated model to prevent race conditions on creating the
profile object.

Because inferring who you mean (especially in the presence of remotes) can suck