ninxsoft / mist-cli

A Mac command-line tool that automatically downloads macOS Firmwares / Installers.
MIT License
610 stars 29 forks source link

Caching Server Support? #134

Closed carlashley closed 1 year ago

carlashley commented 1 year ago

:bulb: Add support for pulling content through a Caching Server

Some of this content could possibly be pulled through a Caching Server to help speed up additional requests for similar files; the .ipsw files seem like a candidate, and I guess anything that comes from the "software update" servers would possibly be helpful as well.

:white_check_mark: Proposed solution

To implement pulling through a caching server, a new parameter (i.e. --cache-server would need to be provided that took an argument value specifying the cache server, for example: --cache-server http://example.org:port (the Apple caching service does not support https traffic); then, the URL of the content being requested needs to be transformed into the right format of http://example.org/path?source=netloc, which would end up being formatted like so: http://example.org:50420/2022SpringFCS/fullrestores/012-06874/9CECE956-D945-45E2-93E9-4FFDC81BB49A/UniversalMac_12.4_21F79_Restore.ipsw?source=updates.cdn-apple.com

Note, this content being from Apple should be cachable in this way.

:adhesive_bandage: Alternatives Solutions + Workarounds

There isn't really any way to bandaid/workaround this with mist-cli (or presumably the GUI version), mist itself needs to transform the URL's being fetched from Apple that contain the content in order for it to be cached.

:information_source: Additional context

grahampugh commented 1 year ago

I would request that looking for a caching server would be an option rather than the default (or, could be optionally disabled). I've seen hit-and-miss reliability getting the installers from a caching server when it works fine direct from the server.

I guess that so long as --caching-server is not supplied, it should go directly to Apple's servers, so that would provide that optional nature inherently.

I'd also advocate for the key name to be --caching-server rather than --cache-server, since that's it's name :-)

ninxsoft commented 1 year ago

Sounds great!

I'm thinking it should be off by default, and mist should gracefully fallback to the original URL if unable to find the resource on the specified caching server.

That should give a more pleasant user experience than simply failing if file not found when a caching server is specified.

ninxsoft commented 1 year ago

Even better: I have recently discovered that mist will add to an existing Content Caching server if supported files are missing.

No fallback logic required (provided the Content Caching server is setup correctly)