如果下载成功,为什么 WebClient.OpenReadAsync 会返回长度为零的 e.Result?

发布于 09-26 07:32 字数 1117 浏览 7 评论 0原文

使用以下代码(来自 Silverlight 4 OOB 应用程序),我得到的结果流大小为零,即使下载整个文件 (900+MB) 需要时间并且没有报告错误。 Fiddler 还说整个文件已下载。

进度更改的处理程序(尽管下面未显示)被命中并报告下载百分比的增加。

这适用于较小的文件 (10MB)。

var wc = new WebClient();
wc.OpenReadCompleted += DownloadWholeFileOpenReadCompleted;
wc.DownloadProgressChanged += DownloadWholeFileDownloadProgressChanged;

wc.OpenReadAsync(new Uri(movie.DownloadUrl, UriKind.Absolute));


private static void DownloadWholeFileOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{
    if (e.Cancelled)
    {
        return; // this is not hit
    }

    if (e.Error != null)
    { 
        return; // this is not hit
    }

    using (var fs = new FileStream(tempFilePath, FileMode.OpenOrCreate, FileAccess.Write, FileShare.None))
    {
        var buffer = new byte[4096];
        int bytesRead;

        // <snip />

        // e.Result.Length this equals 0

        while ((bytesRead = e.Result.Read(buffer, 0, buffer.Length)) != 0)
        {
            fs.Write(buffer, 0, bytesRead);
        }

        fs.Close();
    }

    // <snip />
}

有什么想法吗?

Using the following code (from a Silverlight 4 OOB app) I'm getting a result stream with a size of zero even though it takes the time to download the whole file (900+MB) and no error is reported. Fiddler also says the whole file was downloaded.

The handler on progress changed (although not shown below) is hit and reports an increase in download percentage.

This works with smaller files (10MB).

var wc = new WebClient();
wc.OpenReadCompleted += DownloadWholeFileOpenReadCompleted;
wc.DownloadProgressChanged += DownloadWholeFileDownloadProgressChanged;

wc.OpenReadAsync(new Uri(movie.DownloadUrl, UriKind.Absolute));


private static void DownloadWholeFileOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{
    if (e.Cancelled)
    {
        return; // this is not hit
    }

    if (e.Error != null)
    { 
        return; // this is not hit
    }

    using (var fs = new FileStream(tempFilePath, FileMode.OpenOrCreate, FileAccess.Write, FileShare.None))
    {
        var buffer = new byte[4096];
        int bytesRead;

        // <snip />

        // e.Result.Length this equals 0

        while ((bytesRead = e.Result.Read(buffer, 0, buffer.Length)) != 0)
        {
            fs.Write(buffer, 0, bytesRead);
        }

        fs.Close();
    }

    // <snip />
}

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

笔芯2024-10-03 07:32:43

我的猜测是因为底层流是分块响应,并且 HTTP 响应中没有给出 Content Length 标头。因此,长度返回 0。在 中使用长度没有任何意义。类规范。根据规范:

您应该检查错误并
使用前取消的属性
返回的数据
财产。如果 Error 属性的
value 是一个 Exception 对象或者
取消的财产的价值是真实的,
异步操作没有
正确完成和结果
属性的值将无效。

所以我会忽略长度,检查这些字段,然后随心所欲地阅读。

My guess is because the underlying stream is a chunked response and no Content Length header was given in the HTTP response. So Length returns 0. There's nothing about using the Length in the class spec. According to the spec:

You should check the Error and
Cancelled properties before using the
data that is returned by this
property. If the Error property's
value is an Exception object or the
Cancelled property's value is true,
the asynchronous operation did not
complete correctly and the Result
property's value will not be valid.

So I would ignore Length, check those fields, and then read to your heart's content.

情绪2024-10-03 07:32:43

数据下载的默认限制为 4Mb。你增加了吗?

试试这个链接:http://forums.silverlight.net/forums/p/21513 /75649.aspx

<system.web>
    ... 
   <httpRuntime maxRequestLength="xxx" /> // Size in Kb
</system.web>

There is a default 4Mb limit for data downloads. Have you increased it?

Try this link: http://forums.silverlight.net/forums/p/21513/75649.aspx

<system.web>
    ... 
   <httpRuntime maxRequestLength="xxx" /> // Size in Kb
</system.web>
水溶2024-10-03 07:32:43

显然,使用 WebClient 和非常大的文件存在一个“已知问题”。在某些情况下,这可能与服务器未设置 Content-Length 的问题有关。

根据通过 Fiddler2 捕获的数据,标头设置正确。
因此,我假设这不是我的具体问题的原因。

显然,HttpWebRequest 不存在这个问题,因此我将考虑更改为使用它。

Apparently, there is a "known issue" with using WebClient and very large files. In some cases this may be linked to issues with the Content-Length not being set by the server.

Based on the data captured via Fiddler2, the header is being set correctly.
I am therefore assuming that this is not the cause of my specific issue.

Apparently, this issue does not exist with HttpWebRequest, so I'll look at changing to use that instead.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文