Help needed: Return error condition to SL app

Feb 22, 2010 at 6:13 PM

Hi, I have the FileUploader working fine in my sample silverlight application. However I want the AsyncHttpHandler to be able to return information about possible error conditions to the client (e.g. unsupported media type, quota exceeded, ...). The code in ProcessFile (UploaderControlHandler.cs) indicates that raising an exception during processing of the file would all that is needed.

When throwing an exception the SL app fails in ReadHttpResponseCallback (HttpFileUploader.cs) when trying to call webRequest.EndGetResponse(...) and the exception returned is always the same (...Not found....).

Any ideas? Did I miss anything here or is there an implementation issue?

Feb 22, 2010 at 7:22 PM

In UploadControlHandler.ProcessFile, you'll see that exceptions are caught and stored.  In EndProcessRequest, if there was an exception, it is simply written to the response (very basic implementation).

In HttpFileUploader.ReadHttpResponseCallback, around line 220-224, it reads this error message.  If there was no error in processing, the response should be empty.  If there was an error, the response contains some text.

If the call to EndGetResponse is failing, then there must be something else going on... I just tried it out, and if I modify the provided example to throw an exception from within the try block in UploadControlHandler.ProcessFile, the desired behavior is observed.  Perhaps you could post an example of the modification to your http handler that causes the silverlight app to fail?

Feb 22, 2010 at 8:07 PM


thanks for the reply. I double checked and yes you are 100% right. No matter where I place the "throw ...." it works as expected.

My issue was that I wanted to perform the checks as early as possible, so I checked for processFileState.FirstChunk and somehow broke the logic of the UploadControllHandler.ProcessFile.

Sorry, probably just worked too many hours today :-)

Again many thanks for the quick reply and for this great project.

Feb 23, 2010 at 4:00 PM

Ok, now I finally found the reason for the error I experienced earlier. My error generation was done during "processFileState.FirstChunk" and the file was large enough to have multiple chunks.

If an exception is thrown at that point in time, the SL App fails during EndGetResponse as described. While I can do the error checking during "processFileState.LastChunk" (and everything works as expected) it would be much better to be able to perform certain checks as early as possible. Just think of uploading 100MB just to find out that the mimetype is not allowed or that you do not have sufficent permission or space left.

To reproduce add to the UploaderControlHandler.cs in ProcessFile:

if (processState.FirstChunk) throw new Exception("Not seen in silverlight");

And upload a file large enough to be split into multiple chunks (above causes no problem if the file is small and has only one chunk).


Any ideas how to make an early check work when having multiple chunks without confusing the SL app, which thinks it needs to send more data?

Feb 23, 2010 at 5:58 PM

I just tried it, and I'm still not getting an error... I added the line that you suggested in ProcessFile, and uploaded a 75 MB file.  The first chunk throws an error, and everything works as expected: uploading that file aborts, and the UI shows "Error" for that file.  The error message is shown in a tooltip on the Error label.

If I'm reading your message correctly, the very first response that it tries to read in HttpFileUploader.ReadHttpResponseCallback is throwing an error when calling webRequest.EndGetResponse?  Something about the response your web server is sending the silverlight client is causing it to become unreadable, or it's losing the connection after sending the request somehow... I'm not really sure.  Perhaps you could post the code for your UploaderControlHandler?

Feb 23, 2010 at 8:15 PM

That's really strange... I just unpacked to ZIP I downloaded yesterday (to make sure I work with the latest release).

Adjusted the sandbox path in the web.config and added a dummy error check. Nothing else was changed (btw. I'm using VS2008, so the solution was converted on initial load, but I do not think that this is an issue at all). Well... it fails. Not if the file is small (e.g. 1KB), but if it's large (tried with 16MB SL 3 Toolkit MSI).

Here's the code I have added:

.... Line 43++ of UploaderControlHandler.cs ....

/// <summary>
        /// Process the file.
        /// </summary>
        private void ProcessFile(object State)
            UploaderControl2ProcessFileState processFileState = State as UploaderControl2ProcessFileState;
                // the path to where this file will be written on disk
                string sandboxPath = Path.Combine(Sandbox.UploaderControlSandboxPath, processFileState.Guid);

                if (processFileState.FirstChunk)
                    throw new Exception("Does not arrive in SL");

                // Is it the first chunk or is the upload for this file being canceled? Create the file on the server
                if (processFileState.Cancel || processFileState.FirstChunk)
                    // if the file already exists in the sandbox, delete it
                    if (File.Exists(sandboxPath))
.... end of snippet ... no changes 

The 3 lines added are the only changes.

Uploading a small file results in "Error" in SL App filelist with a tooltip "Does not arrive in SL", which is the desired result. When uploading a large file I get a "Not found" error (exception details as in German, so I do not post them here. If the details would be helpful, I can post them).


Hope this helps to reproduce the issue. Anyhow many thanks for the support !


Feb 23, 2010 at 9:27 PM

I think that I have reproduced the problem:

By default, the uploader uses a chunk size of 3 MB.  And by default, ASP.NET allows a request size of 4 MB.

If your chunk size exceeds the maximum allowed request size, you will get the "not found" error.  You can configure the maximum request size in web.config: (httpRuntime maxRequestLength attribute)

There is also a setting on the file uploader to specify the chunk size (on the ASP.NET server control UploaderControl, ChunkSizeMB property).

Feb 24, 2010 at 5:30 AM

Hm, I'm not 100% sure, but this does not seam to fit with my issue.

I have not modified the default file uploader chunk size and hove not changed anything to the projects web.config, except the sandbox path.

So all chunk sizes should be like on your system. Also if there would be a chunk size issue, an upload without throwing an "test" excepetion would also fail, right?

And it does not. If I comment out the throw line added early all works as expected, no matter what file size is used.

Maybe something else causing the trouble?

Feb 28, 2010 at 12:30 PM

Solved !

Actually the issue is quite simple to solve. One need to read the request data prior to performing the check and potentially throwing an exception and returning a response. Simple, isn't it?

Next I tried to use a response code != OK, but that failed also. But this is not an issue as the FileUploder handles any response containing data as an error. So the trick is really only to make sure that the request data is read and than do whatever is required. Even if the data of the first chunk is not needed to perform the checking (e.g. mimetype of the uploaded file, user quota, ..), the data needs to be read!

Hope this helps.