We are currently running version 1.9.2113.15971 of the file upload control.  Its been in our production enviornment for a while now.  There are infrequent but consistent errors in which we get an exception thrown and logged on our server (see below) and the web logs shows that a 302 (page redirect) followed by a 400 (malformed web request) happen on the page that receives file posts.  The post page only purpose is to recieve an file post and is handled by the file uploader.  Not sure what is happening with the redirect or what is causing the 400.

The application event log exception looks similar to what happens when a user cancel's an upload on our site (throws an excption also).  But typically, that is gracefully handeled and a 302 and 400 do not occur.

Wondering if the 2.0 version would or has addressed this situation.  Since we can not reliably reproduce this error its hard for us to eval the trial of the 2.0 component outside of our production environment.

 

**************Event Log***************************

Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Date:  
Time:  
User:  N/A
Computer: 
Description:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/19/2007 9:49:24 AM
Event time (UTC): 11/19/2007 5:49:24 PM
Event ID: 23a7535d2e3644dfa4f2b0f901cb7b89
Event sequence: 87861
Event occurrence: 2
Event detail code: 0
 
Application information:
    Application domain: /LM/W3SVC/1290615110/ROOT-1-128399437046469958
    Trust level: Full
    Application Virtual Path: /
    Application Path:
    Machine name:  
Process information:
    Process ID: 2724
    Process name: w3wp.exe
    Account name: 
 
Exception information:
    Exception type: Exception
    Exception message: Reqest was aborted
 
Request information:
    Request URL: ...
    Request path: /flash_file_upload.aspx
    User host address: 74.239.42.202
    User: 
    Is authenticated: False
    Authentication Type: 
    Thread account name: ...
 
Thread information:
    Thread ID: 5
    Thread account name: ...
    Is impersonating: False
    Stack trace:    at Mediachase.FileUploader.McHttpModule.694a7e1d01f817ae(Object 337e217cb3ba0627, EventArgs fbf34718e704c6bc)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 

Control throws "Request was aborted" error if incoming http stream is destroyed (ex: is closed by IIS, user cancels upload and so on).

I can suggest that if  page is redirected to login page, then user session expired? And you can increase session timeout to solve problem.

To help you I need more information:
Can you show me sequence of 400 and 302 errors from web logs?
Can you detect client browser version?

The user was on IE7 in Windows.

I attached a text file with a web log for one user who triggers this event.  Their session does not time out and they immediately (and successfully) post another file to our server.  The page flash_file_upload.aspx in the log does not do a redirect or have any session based checks...it just accepts the file post and moves the posted file from the file uploader temp directory into another directory.

Log 2007-10-12 14:42:09 does a 302 redirect from that page and then appears to continue posting the file looking at the next line 2007-10-12 14:45:25.  In our logs the last parameter is bytes transfered. 

So, when the user "cancels" the download and triggers the stream aborted exception, can you think of any situation where the mediachase component would do a 302 redirect?  Or why the page would continute to post the remainder of the data and get a 400?

We do have the file uploader configured to do a redirect if the posted file is too big...but thats set for 10mb and the bytes transfered in this scenario is way less.

Thank you for the log file.

gradylen:

So, when the user "cancels" the download and triggers the stream aborted exception, can you think of any situation where the mediachase component would do a 302 redirect?  Or why the page would continute to post the remainder of the data and get a 400?

About 302, Mediachase FileUploader control redirects page if you turn on redirect and

if(content_length/1024 < McHttpModule.httpPostMinSize)

or

if(content_length/1024 > McHttpModule.httpPostMaxSize)

MinSize and MaxSize is integer that represents the minimal POST request size in kilobytes.

About 400, I've discovered several ASP.NET problems when HTTP 400 can be thrown:

http://forums.iis.net/t/1105360.aspx

http://www.eggheadcafe.com/community/aspnet/6/2787/bad-request.aspx

http://www.egilh.com/blog/archive/2006/04/27/2632.aspx

http://support.microsoft.com/kb/826437

gradylen:

We do have the file uploader configured to do a redirect if the posted file is too big...but thats set for 10mb and the bytes transfered in this scenario is way less.

Show me your fileuploader web.config section.

Please, comment Redirect attribute, wait and compare old and new result.

I'm waiting for your response.

<Mediachase.FileUploader.McHttpModule>

<httpPost BufferSize="65536" MaxSize="10000" Redirect=".\upload_error.aspx"/>

<progressState Mode="InProcess"/>

<httpFile TempStorage="LocalDisk" TempStoragePath="c:\whatever\"/>

<pageFilters>

<allow RequestPath="*"/>

<deny RequestPath="*WebForm*"/>

</pageFilters>

</Mediachase.FileUploader.McHttpModule>

 

What is the default minimum size parameter for an upload? 

 

I looked at those links on the 400's and don't think they apply.  We are using the 2.0 framework (most are 1.1 problems) and the URL requests are less than 260 chars.  I can upload the same exact offending files from our tests machines and not trigger the issue...and users who run into the issue successfully upload files before and after the failed one.  It may just be something about our operational environment (firewall, load balancer, etc) and not the mediachase component, but we are at a loss for what it is since 98% of the time everything works fine.

 

config section is ok

>> What is the default minimum size parameter for an upload?
0 (Zero)

>> I looked at those links on the 400's and don't think they apply.
Ok

I can suggest to comment Redirect=".\upload_error.aspx" attribute and compare results, may be it give me more info.