MsiPackage does not follow redirects?

[applemuffinironman]

Looking for confirmation that MsiPackage does not / will not / cannot follow redirect responses returned from the DownloadUrl. If I'm wrong about my claim, I'd really appreciate some direction on possibilities for what I've done wrong.

Wix 3.11. Multiple installers each having a custom bootstrapper. Chains contain a mix of MSI and EXE, both remote (for support packages) and local (for our own products). No issues with ExePackage following redirects.

An example non-redirecting MSI that we use is msodbsql.

And example MSI that does (now) redirect is POSforDotNet.

When redirection happens from any provider so far (not just the POSforDotNet example above), we get a 302 response with a proper location header for the direct download. Logs present a chain of errors for the package: Failed to send request to URL..., Failed attempt to download URL..., Failed to acquire payload from.... These ultimately result, of course, in a package cache failure leading to full installer failure.

While attempting workarounds for the initial pair of external-provider MSIs triggering our own issue, I built a little Azure function app that returns a redirect response with a direct (secured/self-hosted) download link and also experienced the same issue. Now we've suddenly started having the same problem with the MS POSforDotNet package.

Since I have no historical network traces for comparison, I'm left only being able to guess that some providers are turning their original URLs into front doors for alternate storage and responding with 302 redirects to the new containers. But if MsiPackage can't follow redirects (or if we've unintentionally disrupted the event chain in our custom code), then we're left with something like downloading and self-hosting these MSIs in our own containers.

[bevanweiss]

Definitely not an area I've looked in before, but it does appear that redirects are handled by the Burn Engine
https://github.com/wixtoolset/wix/blob/ce73352b1fa1d4f9cded10a0ee410f2e786bd326/src/libs/dutil/WixToolset.DUtil/dlutil.cpp#L691-L699

I couldn't readily identify a difference between EXE / MSI, the download logic appears pretty agnostic of what kind of payload group, is to be retrieved.
https://github.com/wixtoolset/wix/blob/ce73352b1fa1d4f9cded10a0ee410f2e786bd326/src/burn/engine/apply.cpp#L1266

What are the precise error codes associated with the various messages?
i.e. the HRESULT associated with the message "Failed to send request to URL"

I'm just wondering if maybe on top of the 302, the new destination is requiring something else (like it's throwing a 403 because it didn't carry a redirect header or something).
Any chance you could put Wireshark or similar on it when doing the Burn initiated request?

[applemuffinironman]

Thanks so much for your response.

Have you ever been so far down the rabbit hole with one issue that when something else breaks everything starts looking exactly the same? Embarrassed to say that's what happened here. At least with the specific POSforDotNet package above.

Your recommendation to actually pay attention to the HRESULT helped me identify that this one is (now) just a simple HTTP-to-HTTPs redirect. Such a trivial fix.

And since I have trouble navigating the WiX source, those links are super-helpful.

All of this gives me some ideas for more elegantly handling our initial triggering issue with another MSI provider that has (as far as I can tell at this point) changed their download URL to redirect with added tracking headers.