Web客户端UploadFileAsync奇怪的行为进行报告 [英] WebClient UploadFileAsync strange behaviour in progress reporting

查看:148
本文介绍了Web客户端UploadFileAsync奇怪的行为进行报告的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要一些帮助,奇怪WebClient.UploadFileAsync()的行为。
我上传文件到远程HTTP服务器(nginx的)usind POST方法。该POST处理槽一个PHP脚本(地址指的)。

i need some help with strange WebClient.UploadFileAsync()'s behaviour. I'm uploading a file to a remote HTTP Server (nginx) usind POST Method. The POST is processed trough a PHP script (which Address refers to).

我这个简单的代码

public void uploadFile(string filePath)
{
    webClient = new WebClient();
    webClient.Credentials = new NetworkCredential(Constant.HTTPUsername,Constant.HTTPPassword);
    webClient.Headers.Add("Test", TestKey);
    webClient.UploadProgressChanged += webClient_UploadProgressChanged;
    webClient.UploadFileCompleted += webClient_UploadFileCompleted;

    try
    {
        webClient.UploadFileAsync(new Uri(Address), "POST", filePath);
    }
    catch (Exception error)
    {
        throw new CustomException(error.Message);
    }
}

和在UploadProgressChanged我简单地更新与ProgressPercentage一个进度给出。
的第一个问题是,进度百分比报道,用任何文件的大小为:

And in UploadProgressChanged i simply update a progressBar with the ProgressPercentage given. The first issue is that the Progress percentage reported, with any file size is:

[17.38.14] Progress: 0 Bytes Sent: 175 / 269264
[17.38.14] Progress: 1 Bytes Sent: 8367 / 269264
[17.38.14] Progress: 3 Bytes Sent: 16559 / 269264
[17.38.14] Progress: 4 Bytes Sent: 24751 / 269264
[17.38.14] Progress: 6 Bytes Sent: 32943 / 269264
[17.38.14] Progress: 7 Bytes Sent: 41135 / 269264
[17.38.14] Progress: 9 Bytes Sent: 49327 / 269264
[17.38.14] Progress: 10 Bytes Sent: 57519 / 269264
[17.38.14] Progress: 12 Bytes Sent: 65711 / 269264
[17.38.14] Progress: 13 Bytes Sent: 73903 / 269264
[17.38.14] Progress: 15 Bytes Sent: 82095 / 269264
[17.38.14] Progress: 16 Bytes Sent: 90287 / 269264
[17.38.14] Progress: 18 Bytes Sent: 98479 / 269264
[17.38.15] Progress: 19 Bytes Sent: 106671 / 269264
[17.38.15] Progress: 21 Bytes Sent: 114863 / 269264
[17.38.15] Progress: 22 Bytes Sent: 123055 / 269264
[17.38.15] Progress: 24 Bytes Sent: 131247 / 269264
[17.38.15] Progress: 25 Bytes Sent: 139439 / 269264
[17.38.15] Progress: 27 Bytes Sent: 147631 / 269264
[17.38.16] Progress: 28 Bytes Sent: 155823 / 269264
[17.38.16] Progress: 30 Bytes Sent: 164015 / 269264
[17.38.16] Progress: 31 Bytes Sent: 172207 / 269264
[17.38.16] Progress: 33 Bytes Sent: 180399 / 269264
[17.38.16] Progress: 35 Bytes Sent: 188591 / 269264
[17.38.16] Progress: 36 Bytes Sent: 196783 / 269264
[17.38.17] Progress: 38 Bytes Sent: 204975 / 269264
[17.38.17] Progress: 39 Bytes Sent: 213167 / 269264
[17.38.17] Progress: 41 Bytes Sent: 221359 / 269264
[17.38.17] Progress: 42 Bytes Sent: 229551 / 269264
[17.38.17] Progress: 44 Bytes Sent: 237743 / 269264
[17.38.17] Progress: 45 Bytes Sent: 245935 / 269264
[17.38.17] Progress: 47 Bytes Sent: 254127 / 269264
[17.38.18] Progress: 48 Bytes Sent: 262319 / 269264
[17.38.18] Progress: 49 Bytes Sent: 269220 / 269264
[17.38.18] Progress: 50 Bytes Sent: 269264 / 269264
[17.38.25] Progress: -50 Bytes Sent: 269264 / 269264
[17.38.25] Progress: 100 Bytes Sent: 269264 / 269264
[17.38.25] FileCompleted event raised!



所以,在网络上搜索,我发现,从50-> 100跳,是只是一个设计选择百分比report..and所以我与它的罚款。
奇怪的问题是,即使在50%(当整个文件被发送),网络接口仍然产生流量,并且还在上传。
事实上,你可以从上面的日志中看到的时间,它需要7秒,文件后发送,提高UploadFileCompletedEvent..in事实,同时,我还在发送文件通过HTTP。

So, searching on the web, i've found that the jump from 50->100, is just a design choice in percentage report..and so i'm fine with it. The strange issue is that even if at 50% (when the entire file was sent), the network interface still generate traffic and is still uploading. In fact, as you can see from the time in the log above, it takes 7 seconds, after file sent, to raise the UploadFileCompletedEvent..in fact, meanwhile, i'm still send the file over HTTP.

这里的问题是,我不能可靠地更新我的UI:进度条将增长至50%,但随后会被卡住等待上传completition(这是一个坏。行为,因为,具有大文件,此时显著增长)

The issue here is that i cannot reliably update my UI: the progress bar will grow until 50% but then it will be stuck waiting for upload completition (and this is a bad behaviour since, with large file, this time grows significantly).

现在的问题是:我如何能够可靠地保持更新有关文件上传进度用户

The question is: how can i reliably keep the user updated about file upload progress?

感谢。

PS该方法的工作原理完全正常,文件被正确地上传到远程服务器。 。唯一的问题是与进展的报告

P.S. the method works perfectly fine and the file is correctly uploaded to the remote server. The only issue is with the progress reporting.

推荐答案

我刚刚发现了这个问题:它在基本的HTTP认证。由于一些奇怪的原因,即使我指定凭据,Web客户端无需指定的HTTP标头的凭据提交的第一个POST请求。服务器与身份验证请求的答复后,提交第二次POST请求指定,正确的凭据。在这些2 retryies,我的应用程序发送文件的2倍! (这就是为什么我经历甚至在文件被完全发送上传活动)

I've just found the issue: it's in the basic HTTP Authentication. For some strange reason, even if i specify Credentials, WebClient submit the first POST request without specifying the credentials in the HTTP Header. After the server replies with a auth-request, it submit the second POST request specifying, correctly, the credentials. In those 2 retryies, my application sends the file 2 times! (That's why i experienced upload activity even after the file was completely sent)

解决方案是通过手动添加认证头(和删除Web客户端,强制HTTP基本身份验证.Credentials ..行:

The solution is to force the HTTP basic authentication by manually adding the Authentication header (and deleting the WebClient.Credentials.. line :

string authInfo = userName + ":" + userPassword;
authInfo = Convert.ToBase64String(Encoding.Default.GetBytes(authInfo));
req.Headers["Authorization"] = "Basic " + authInfo;

这路1号(只)POST请求,将与认证报头被正确提交,报告进度正常(只为分享,我在作为进度报告进度(e.ProgressPercentage * 2)对于上述的原因。

This way the 1st (and only) POST request, will be correctly submitted with Authentication header, and the report progress is correctly (just for sharing, i report progress in my progressbar as (e.ProgressPercentage * 2) for the reason above.

这篇关于Web客户端UploadFileAsync奇怪的行为进行报告的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆