2013-05-01 56 views
0

在FireFox中上傳掛好了一個問題今天已經出現了與FineUploader,這是昨天確定工作,並沒有任何改變的代碼的文件上傳部分。FineUploader - 超過350KB

該網站是在Windows Server 2008 R2的運行在IIS7和所有的服務包,並在MVC .NET 4.5運行。

在web.config具有所需的設置:

的httpRuntime targetFramework = 「4.5」 的maxRequestLength = 「2147483647」 和

requestLimits maxAllowedContentLength = 「2147483647」

,以允許較大的上載,並它在Visual Studio中的本地機器上工作沒有問題。

我也可以在本地計算機上運行IIS它和它的作品完美也。唯一的問題是它從實際的現場網站運行。不幸的是,我不能放棄現場。

當它在FF失敗,我得到「XHR返回的響應碼0」

對上傳的代碼(不包括對錯誤/完整等事件)是:

manualuploader = $('#uploader').fineUploader({ 
    request: { 
     endpoint: '/File/UploadFile', 
    } }); 

所以我不要限制代碼中的任何類型/大小等。

正如我所說,將工作時間的100%的文件在350KB左右,比任何東西,它總是在圍繞350-400kb標記(基於它停靠在百分比)凍結。幾分鐘後,它進入帶有XHR 0代碼的fineuploader錯誤調用。

它的工作原理每次在Chrome中確定的時間,有時在IE,但有時凍結約1.5MB並給出了相同的錯誤代碼,並在FF與錯誤凍結的100%的時間。

哦,我不認爲它超時,因爲它需要大約1或2秒獲得了400KB即使是在緩慢的連接,然後就崩潰前掛起。有任何想法嗎?

請求報頭: 接受的text/html,應用/ XHTML + xml的,應用/ XML; Q = 0.9,/; Q = 0.8 接受編碼的gzip,放氣 接受語言的en-US,帶; q = 0.5 緩存控制無緩存 連接保持活動 內容長度1861415 內容類型multipart/form-data;邊界= --------------------------- 170602977010532 曲奇__RequestVerificationToken = zL6gveyPJ9FY-KvAQq9xHAdrdKTlezzuzwTXfMLETYbXCgFS9XJKRonvJ7vebBK1f9YCueXq8td33cX_10Xx_hfseiaszXq76PGgCKmHE0M1 宿主中取出 附註無緩存 的Referer REMOVED 用戶-agent的Mozilla/5.0(Windows NT的6.1; WOW64; RV:20.0)嘗試分析XHR應答文本(當的SyntaxError壁虎/ 20100101火狐/ 20.0 X-請求-使用XMLHttpRequest

[FineUploader]錯誤:JSON。解析:數據突發結束時)

然後POST部分是(不包括在端部的垃圾這大概是隻是文件數據):

------------- ---------------- 170602977010532 Content-Disposition:form-data; name =「path」null ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqpartindex」0 ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqpartbyteoffset」0 ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqchunksize」1860320 ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqtotalparts」1 ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqtotalfilesize」1860320 ----------------------------- 170602977010532 Content-Disposition:form-data; name =「qqfilename」2013-04-21 19.05.30.jpg ----------------------------- 170602977010532 Content-Disposition:form -數據; name =「qquuid」e2732d70-3247-4555-bcbd-399aaa471d58 ----------------------------- 170602977010532 Content-Disposition:form-數據; NAME = 「qqfile」; filename =「blob」Content-Type:application/octet-stream

+0

發生此問題時,請根據螢火蟲發佈原始請求和原始響應。 IE10也有一個網絡選項卡,您可以在其中查看請求/響應,以便也可以使用。 – 2013-05-01 20:50:18

+0

響應代碼0也可能表示響應爲空。看起來好像某些東西,可能是網絡設備或防火牆,可能會干擾服務器端。 – 2013-05-01 20:58:20

+0

...以及回覆....的內容? – 2013-05-01 21:10:39

回答

0

似乎很清楚,這是一個服務器端問題。另外,你已經說過,它昨天運行良好,所以你的服務器環境中必須改變。根據日誌消息,可能會干擾請求。您需要花一些時間查看服務器日誌和代碼,並檢查端點和瀏覽器之間的任何設備,以確定發生了什麼問題。您的端點無法正確處理請求,或者在請求遇到您的端點代碼之前干擾請求。沒有太多的幫助可以提供,因爲我對服務器環境一無所知。你需要做一些故障排除。

+0

我已經將相同的代碼移植到了我的其他Windows服務器,並且它工作100% - 所以是它的服務器問題。如果我找到答案,我會立即調查並報告。 – user2340728 2013-05-01 22:09:14

+0

確定它不是服務器,我認爲它的FireFox和IE。我來嘗試使用他們的上傳器將文件上傳到eBay並得到同樣的問題。我也嘗試http://blueimp.github.io/jQuery-File-Upload/並得到同樣的問題!然而,它是可重複的,在美國的朋友可以得到它的發生,我的電腦的4個實現它,我的虛擬主機可以讓它發生在FireFox和IE ...他們最近更新了什麼導致此問題爲它的傳播不僅僅是我的機器? – user2340728 2013-05-05 17:00:07

+0

哦,我現在也發現了更多 - 如果客戶端機器是Windows Server 2008或2012,我可以上傳到eBay,我的站點和其他jQuery文件上傳站點就好了。但是運行Windows 7的站點不起作用。所有機器上的FireFox都是20.0.1版本。運行最新的OSX和所有更新的Safari也會發生此問題。更令人困惑的是,服務器2008突然之間出現了這個問題,它自從3-4周前安裝以來就沒有Windows更新。這很混亂。 – user2340728 2013-05-05 17:41:20