Paste a URL to a photo and the studio downloads it into the same uploads/
directory a picked file goes to. Nothing downstream changes: face extraction, the
profile, the keyframes and LoRA training cannot tell the two apart, which is the
point — "extract the character from it" is the pipeline that already exists.

The part worth reviewing is that the STUDIO makes the request, not the browser.
On this box that process can reach coderai on 127.0.0.1:8776, every admin API it
exposes, and the whole LAN. So:

- every hop must resolve to a public address. Private, loopback, link-local,
  reserved, multicast and unspecified are all refused, by resolving the host and
  checking the ADDRESS rather than pattern-matching the string;
- redirects are followed by hand, five hops maximum, re-checking each one. A
  public URL that 302s to 127.0.0.1 is the standard way past a check done once;
- only http/https. ftp://, file:// and the rest are refused by scheme;
- 256 MB ceiling, enforced against Content-Length AND while streaming, since a
  server can lie about the first;
- the content must be an image or a video, by URL suffix or, for the many image
  URLs with no suffix at all, by content type.

--allow-private-fetch turns the address rule off for someone pulling from their
own NAS. It is a flag rather than a default so it is the operator's decision.

Verified against a running studio: loopback, 192.168/16, 169.254.169.254 and
ftp:// are all refused with the reason; a real public image over the internet and
a local one with the flag both land in uploads/ with the extension resolved from
the content type when the URL had none.

The tests also parse the page's script with node — the township page shipped a
dead <script> for four versions because nothing ever parsed what it served, and
this page now has a reason not to repeat that.

125 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY