Recently I was working on a bit of PowerShell to download the awesome First Responder Kit from Brent Ozar Unlimited. The canonical URL for the FRK is
http://firstresponderkit.org/ but that’s a redirect to the GitHub repository where all the magic happens. I thought to myself:
Self! Rather than take a chance on that GitHub URL changing, use the “main” URL and
Invoke-WebRequestwill take care of the redirect for you.
So off to the PowerShell prompt I went and ran
Invoke-WebRequest -Uri http://firstresponderkit.org/ to start looking at the object returned so I could see what I needed to parse out to find my way to the true download URL.
Then Firefox (my default browser) opened, and I was staring at
I was expecting an
HTTP 30X redirect status code which, based upon previous experience,
Invoke-WebRequest would honor. Instead, I got a
200 OK which is the web server saying “yep, here’s your stuff, HAND!”
Hmmm…nope, nothing there. OK, in a past life I did some non-redirect redirects through page contents. Let’s look at the content of the page itself (if any):
Invoke-WebRequest -Uri http://firstresponderkit.org | Select-Object -ExpandProperty Content
Now we’ve got something. The web page itself has both a
-UseBasicParsing switch for
Invoke-WebRequest. From the docs:
Indicates that the cmdlet uses the response object for HTML content without Document Object Model (DOM) parsing.
This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system.
Looking closer at the output of
Invoke-WebRequest, there’s a
Links collection that looks pretty good.
So now I can dig a little deeper and send my script to the URL that Brent & Co. want me to go to, and continue my search for the one true First Responder Kit download link by crawling subsequent pages.
Invoke-WebRequest -UseBasicParsing -uri $((Invoke-WebRequest -Uri http://firstresponderkit.org).Links.href)