Limiting Upload Sizes with ASP.NET, Page 2
Limiting the File Size
So far, so good. But at this point, the user can upload images of any arbitrary size. This is not good for either network traffic or database size, and raises the possibility of a nasty denial of service attack. So, the next step is to limit the uploaded file size to a reasonable value. The customer chose 128K as their maximum image size.
Your first thought might be to check the ContentLength property of the uploaded file to see if it's within the expected size, and to bail out of the procedure if it's too large. Unfortunately, this is only half of a solution. While that check would prevent the file from getting to the SQL Server database, it still requires the entire file to be uploaded first, potentially clogging the network. Fortunately, ASP.NET provides a better solution
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <httpRuntime maxRequestLength="128"/> ...
The maxRequestLength attribute of the httpRuntime tag specifies, in KB, the largest HTTP request that the application will accept. The default is 4096 KB, which is a little large for most applications. Be careful about setting this too low, though, as it applies to every request, not just uploaded files. If you're moving a lot of data around in ViewState, for example, you could run afoul of a too-low setting.
With this change to the Web.Config file, large files won't even be accepted by the server. But the user experience could use some work. Figure 2 shows what happens if the user tries to upload a large image with this setting in place.
ASP.NET rejects the request in the rudest way possible, telling the client that there's no such page.
Telling the User What Happened
To get a better error message across to the user, you need to turn to another corner of the application. If your first impulse is to put a Try/Catch block in the page load to catch the error, think again: ASP.NET doesn't load the page at all in this situation. You have to move up the processing chain to the error event in the global.asax.vb file, which is called for every error in the application.
The strategy I settled on was to catch the error, and then redirect the user back to the original page with an error message. That way, they'll get a chance to try again with a different file. To start the process, I added some code to the global.asax.vb file:
Sub Application_Error(ByVal sender As Object, _ ByVal e As EventArgs) ' Fires when an error occurs ' Check to see whether we came ' from the upload form If Path.GetFileName(Request.Path) = _ "UploadForm.aspx" Then ' Get the error details Dim appException As System.Exception = _ Server.GetLastError() Dim checkException As HttpException = _ CType(appException, HttpException) ' Verify the expected error If checkException.GetHttpCode = 400 And _ checkException.ErrorCode = -2147467259 Then ' Error 400 = bad request, user ' tried to upload a file that's too large Session("ImageTooLarge") = True Server.ClearError() ' Go to the original target page Response.Redirect("UploadForm.aspx") End If End If ' For other errors, just accept the default processing End Sub
The next step was to add a label control to the original upload form. The control's name is lblTooLarge, its text is a warning that the image is too large, and its Visible property is set to False. Then I modified the Page_Load procedure of the upload form:
Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load If Not IsPostBack Then ' Check to see whether we were redirected ' from the error page If Session("ImageTooLarge") = True Then lblTooLarge.Visible = True Exit Sub End If Else ' Get the uploaded data Dim upfile As HttpPostedFile = _ UploadFile.PostedFile ' Remaining code unchanged ... End If End Sub
If the user tries to upload a file, the error gets caught in the global.asax file. At that point, the code retrieves the error details and verifies that this is the error that happened; I don't assume that it's the only possible error in the application! If it is, the code sets a flag in the session state and hands control back to the upload form. The upload form checks for the flag and makes the label visible so that the user will know what they did wrong.
ASP.NET Comes Through Again
Although I didn't know how to put together every piece of this puzzle when I was hit with the original requirements, I wasn't surprised to find that ASP.NET could handle them all. If you work with ASP.NET you've probably found, as I have, that it is an extremely well thought-out framework that covers most of what you'd like to do with a Web application. The flip side to that, of course, is that there's a lot to learn. Hopefully you can take at least some of the snippets from this example and use them in your own future applications.
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his latest book, Coder to Developer from Sybex. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.