With recent migration of boost, some of our scripts broke. One of them was responsible for downloading the zip file. Here is the link for the file itself
- Request #3 is my browser loading the index page (including 200 javascript bundle files).
- Request #252 is when I clicked the
boost_1_69_0.ziplink, which triggered a HEAD request and a GET request to/ui/api/v1/download?repoKey=main&path=release%2F1.69.0%2Fsource%2Fboost_1_69_0.zip - Request #253 is the GET request which receives a 302 Found response redirecting the browser to the actual download link
- Request #256 is the download from the s3.amazon.aws.com site initiated by the browser
So, if you want to replicate what the browser is doing, your best bet is to do something like this:
Invoke-WebRequest -Uri "https://boostorg.jfrog.io/ui/api/v1/download?repoKey=main&path=release%2F1.69.0%2Fsource%2Fboost_1_69_0.zip" -OutFile "1.69.0.zip";
Invoke-WebRequst will automatically follow the 302 response returned by https://boostorg.jfrog.io/ui/api/v1/download?repoKey=main&path=release%2F1.69.0%2Fsource%2Fboost_1_69_0.zip and will download the file from the url specified in the Location header in the response.
PS
Your 15kb file that you download from https://boostorg.jfrog.io/ui/native/main/release/1.69.0/source/1.69.0.zip is another web page - try putting the url in your browser and see what happens.
CodePudding user response：
This works using the API. I've navigated to https://boostorg.jfrog.io/ui/native/main/release/1.69.0/source and used Chrome (F12) to debug what happens when clinking on the link to inspect what happens. But the regular link use the HEAD HTTP method, and return a 200 OK instead of a redirect. Invoke-WebRequest -Uri "https://boostorg.jfrog.io/ui/api/v1/download?repoKey=main&path=release%2F1.69.0%2Fsource%2Fboost_1_69_0.zip" -OutFile "C:\Data\Tmp\1.69.0.zip"