I tried to download a file via Flurl and noticed that file had a gibberish name, but Chrome downloaded the same file with a readable name.
var client = new FlurlClient(baseUrl);
var request = client.Request(link)
.WithAutoRedirect(true)
.WithCookie(cookieKey, cookieValue);
var fileName = await request.DownloadFileAsync(".");
// nothing special
After some investigation my suspicion is that DownloadFileAsync (in case of Content-Disposition absence) does not respect redirects and tries to parse file name from the initial request url. But file name can be parsed only from redirected request url in my case and Chrome does exactly that.
I don't know if this behavior is governed by any RFC or something else, so I don't know if it is a bug or not.
Screenshot of the debug values from the breakpoint at DownloadFileAsync:

Versions
<PackageReference Include="Flurl" Version="4.0.0" />
<PackageReference Include="Flurl.Http" Version="4.0.2" />
I tried to download a file via Flurl and noticed that file had a gibberish name, but Chrome downloaded the same file with a readable name.
After some investigation my suspicion is that DownloadFileAsync (in case of
Content-Dispositionabsence) does not respect redirects and tries to parse file name from the initial request url. But file name can be parsed only from redirected request url in my case and Chrome does exactly that.I don't know if this behavior is governed by any RFC or something else, so I don't know if it is a bug or not.
Screenshot of the debug values from the breakpoint at

DownloadFileAsync:Versions