Closed carlashley closed 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 :-)
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.
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)
: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 supporthttps
traffic); then, the URL of the content being requested needs to be transformed into the right format ofhttp://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