File Upload or HTTP upload allows site visitors to send files to the Web server using standard forms. In the same way that there are form elements that allow you to enter text and others that allow you to choose items from a list, there is a form element that allows you to choose a file.
Like so many useful elements of HTML, file upload was not supported in Internet Explorer 3.0 but was added in version 3.02. It is available in Netscape Navigator from version 2.02 onward. Realistically, this means that you can rely on almost every visitor being able to upload files.
What does it look like? Well, check out the (nonfunctional) form below that is much like any other form element, except that you can use the browse button to choose files.
Here's the code for the above.
<form method="post" action="upload.asp" name="submit" enctype="multipart/form-data">
Enter Some Text: <input type="text" name="textfield"><br><br>
Choose A File: <input type="file" name="filefield"><br><br>
<input type="submit" name="submit" value="submit"><br>
</form>
There are only a couple of real differences. The input type of the file upload is "file," rather than "text." The enctype of the form is multipart/form-data. Multipart form data is an Internet standard covered by RFC 1867. (Request For Comments [RFC] are used by the Internet Engineering Task Force [IETF] and other standards bodies.) Multipart form data allows many different types of information to be sent over the Internet as one bundle. It's not very complicated in theory, but the practicalities can be. Different browsers implement a variety of nonstandard extensions to work around areas not covered by the RFC, and there are bugs that you must be aware of to make upload work reliably. And note that ASP doesn't support multipart form data as standard!
It is a horrible truth that although Microsoft browsers have supported multipart forms since Microsoft became interested in the Web, the standard form components it supplies for Web serving do not. There are a number of third-party ASP extensions designed specifically to solve this problem. For instance, SoftArtisans produces SAUpload and Persits produces ASPUpload.
This article uses examples from ABCUpload, which is a free product from WebSupergoo. Using ABCUpload, you need to write the following code to save the uploaded file:
This will save the file into the current directory as myupload.dat. By default, the file path is assumed to be a URL rather than a physical file location.
The Duplicitous Nature of Macintosh Files
Multipart form data was written to deal with standard files. However, Macintosh files are different from Windows files in three main ways:
Every file consists of two separate streams or forks. The data fork holds the basic file information that you would find in a Windows file. The resource fork contains a database of other associated information, such as picture previews, notes, and icons. So a bitmap (BMP) image might contain the BMP in the data fork and an icon, preview, and copyright note in the resource fork.
Macintosh files do not contain a file-type extension. Instead, they have a hidden type and creator code.
Macintosh file names can contain almost any character except for the colon character. This means that it is common to have Macintosh files containing slashes, question marks, and asterisks.
When Internet Explorer uploads a file from a Macintosh, it chooses to put all this information together into one big stream encoded as MacBinary. You can just rip out the data fork, and this is what most MacBinary-compatible upload components do. However, if you do this, you lose all sense of what type of file was uploaded and any other associated information. In particular, some types of files,, such as Encapsulated PostScript Files (EPSFs) and QuickTime movies,, can be completely destroyed by this process.
If you have a number of Macintosh clients, this is an issue you will need to consider when developing your solution. For example, the publishing or design industries will have a significant number of Macintosh clients.
First, you need to ensure that your solution supports MacBinary. If it does not, you will not be able to use files uploaded from Macintosh clients.. Also note that the MacBinary encoding that IE uses is nonstandard so unless you factor this into your solution, some uploads may fail.
Second, you need to determine what types of file you're being given. ABCUpload does this invisibly using the file-type information provided as part of the MacBinary encoding. Other solutions may use different methods or may not handle file types at all.
Third, you need to decide how to handle resource and data forks. Most MacBinary solutions just rip out the data fork and abandon the resource fork. This is often sufficient for simple processing. ABCUpload and SAUpload actually store the data and resource forks intact using the standard NT mechanism used by Services for Macintosh (SFM). If you look at such a file from Windows, it will look like a standard file (e.g., JPEG, DOC, etc.). However, if you serve this file to Macintosh users using Services for Macintosh (SFM), they will see the original file completely intact.
Dealing with the Deceptive Nature of File Names
Consider what kind of file names you want to use when saving uploaded files. Probably the simplest solution is to abandon the name of the file your visitor has provided and create a completely new one that you know is both valid and unique. However, sometimes you need to let people preserve the name of their file, and this is where you need to consider a number of issues.
First, a valid file name for one person is not necessarily a valid one for someone else. You will find that you need at least three types of file names -- Raw, Server Safe, and URL Safe. The Raw file name is the one used by the client on their system and may contain spaces, colons, slashes, and other illegal characters. The Server Safe name should be as similar to the original name as possible but exclude illegal characters so that it can be used on the server. URL Safe names are even more restrictive. They must exclude or encode any characters, such as spaces, that cannot be used in a URL.
For example, a Windows user may upload a file named "My Birthday.JPG." The Server Safe name might be "My Birthday.JPG" while the URL Safe name might be "mybirthday.jpg." As another example, a Macintosh client might upload a JPEG image named "My Birthday 2/2/2001." The Server Safe name might be "My Birthday 2-2-2001.JPG" and the URL safe name might be "mybirthday2-2-2001.jpg."
Different components handle this problem in different ways. ABCUpload simply uses three different properties, each with a different file name. To save a file using the URL Safe, Server Safe, or Raw file names, simply use the respective methods:
theField.Save theField.FileName ' URL Safe
theField.Save theField.SafeFileName ' Windows Safe
theField.Save theField.RawFileName ' Original
In addition, you may get Unicode uploads from clients in other countries.
Unicode is the format in which languages such as Japanese and Korean are encoded. In general, Internet Explorer browsers support Unicode uploads, while Netscape Navigator browsers do not.
Inadequate Progress Bars
Probably the biggest drawback of HTTP upload has been the pitiful progress bars shown on the browser. Problems start to arise when you want to upload large files or your users are on slow connections. When they submit their file, it may take seconds or minutes to send to the server. Because browsers don't give good feedback, your users may get confused or frustrated and give up before completing their upload. The obvious solution to this is to give the user a dedicated progress bar, but Java or ActiveX bring in all the problems of incompatibility that we were avoiding by using HTTP upload.
Recently a new class of progress bar has been innovated. This is a client-side HTML progress bar to chart upload progress. When the upload form is submitted, a progress window is spawned that auto-refreshes to keep track of progress while the upload is active. Only client-side JavaScript is required, not Java or ActiveX.
The key feature that enables this HTML progress bar is that a unique ID is assigned to both the upload and to the spawned progress window. The unique ID is used to update a server-side upload registry that can be accessed by the progress window.
If you require a progress bar, establish what kind of support is provided by your solution. ABCUpload uses a Pure HTML Progress Bar, while some other solutions may not have any progress support or rely on Java or ActiveX.
Uploading to a Database
Generally, it is a good idea to avoid putting images in databases. Databases often have problems holding the very large amounts of data involved, and it is preferable to save images to a file and then insert the unique file name into the database.
However, if you need to put images into a database, there are a variety of methods, some of which can be quite involved. This example shows a very simple method.
We installed SQLServer 7 on our CC2 server. We created a database called "mydbase" and inserted a table called "mytable" with an Image column called "myimage." Finally, we created a user called "myuser" with a password, namely"password," and read/write access to the database.
In the code below we first check to see that an image file has been uploaded. If it has, we connect to the database and then open a recordset. We add a new record and put the field data from the upload into the "myimage" column. Then we update the recordset and close the connection.
<% @Language="VBScript" %>
<%
Set theForm = Server.CreateObject("ABCUpload.XForm")
Set theField = theForm("filefield")(1)
If theField.FileExists and theField.ImageType <> 0 Then
Set cn = Server.CreateObject("ADODB.Connection")
theConn = "Provider=SQLOLEDB;Data Source=CC2;Initial Catalog=mydbase;User Id=myuser;Password=password"
cn.Open theConn
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "mytable", cn, 1, 3
rs.AddNew
rs("myimage").Value = theField.Data
rs.Update
rs.Close
cn.Close
End If
%>
<html>
<body>
File uploaded...
</body>
</html>
The Mysteries of the Metabase
A number of ASP settings become relevant when performing uploads. These can be changed using ASP scripts or by editing the IIS Metabase, the location where all the IIS preferences are stored. Edit the IIS Metabase using the Microsoft Metabase Editor (MetaEdit), which is supplied as part of the Windows Resource Kits.
Please note that you can fatally damage your IIS installation using MetaEdit so make sure to edit carefully. Where possible, it is generally easier and safer to alter settings using the simple scripting commands given here.
The script time-out refers to the number of seconds an Active Server Page is given before the script is assumed to have failed and the page terminated. If you are uploading a large file, the script that is receiving the transfer may time out before the file has been completely uploaded. To alter this setting you should insert the following code into your uploading page prior to creating any ABCUpload objects:
Server.ScriptTimeout = 360 ' six minutes
The session time-out is similar to the script time-out but refers to the number of minutes before the user session is aborted. Again, if a large file is being uploaded, it is desirable to maintain the session state. The session time-out should always be longer than the script time-out. Note that this value is only relevant if you have session state enabled. To alter this setting you should insert the following code into your uploading page prior to creating any ABCUpload objects:
Session.Timeout = 30 ' thirty minutes
The UploadReadAheadSize property determines the number of bytes the Web server will read into a buffer and pass to IIS. For large uploads, a greater value may increase the speed of uploads at the cost of increased memory use. This property can only be altered by editing the IIS Metabase.
About the Author
Jos Vernon is based in the United Kingdom but is hoping to move to Australia. He has been working in New Media for the last ten years and has been heavily involved in the development of a variety of software components at Complementary Colors. He also is a consultant in a range of media-related areas. He can be reached at jv@websupergoo.com.
AspUpload is an Active Server component which enables an ASP application to accept, save and manipulate files uploaded with a browser. The files are uploaded via an HTML POST form using RFC 1867. AspUpload can then manipulate the uploaded files in a number of ways which include ACL manipulation, attribute changes, saving to a database, and ActiveX DLL registration.
Uploading files is as simple as ABC with ABCUpload. Our Pure HTML Progress Bar allows your visitors to see the
progress of their upload in real time with absolutely no client side software. We also offer a number of other advanced technical features including Unicode Compliant, 120% MacBinary Compatible, BLOB Aware, support for foreign language uploads.
ABCUpload also supports COM+ and is also available in a .NET version.
With ActiveFile's advanced features, such as restart of interrupted downloads, download failure detection, and industry standard data compression, it's no wonder that companies like Associated Press and Xerox are Infomentum OEM partners. ActiveFile is the professional’s choice for leading edge capabilities that can’t be found in any other file component.
If you are looking for an intelligent way to exchange files between your ASP or ASP.NET application and web clients, the search is over. Compliant with RFC 1867, ActiveFile provides both file upload and download capabilities that work seamlessly with all of the leading web browsers. Using Active Server Pages or ASP.NET scripting, your application can manipulate files and directories using a robust set of objects and methods provided by the ActiveFile component.
An all-in-one shopping cart system that provides a universal hook to all shopping pages on your Web site, regardless what you sell. Runs for all IIS based Web servers under Windows 95, 98, NT 4.0, NT 2000. Works with all versions of FrontPage.
Microsoft Posting Acceptor allows Microsoft Internet Information Server (IIS) to accept Web content posts (files) from Microsoft Web Publishing Wizard or other clients using the RFC1867 multi-form/posting method through an http connection. Microsoft Posting Acceptor can also accept content posts from Internet Explorer 3.0 (with the ActiveX Upload control provided with Microsoft Posting Acceptor) and Netscape Navigator 2.02 or greater through forms.
FileUp is the standard in transactional file uploads and secure downloads.
Allows dynamic applications to accept, save, and manipulate files uploaded
via a browser. Files can be of any format such as Word documents, images, or
plain text. FileUp is the most comprehensive transactional file transfer
controls: supports foreign character sets; guarantees synchronization
between upload processing and database transactions; full COM+ integration;
simplified error handling; guaranteed integrity when uploading multiple
files; server-side progress indicator; performance monitor counters;
MacBinary decoding, recursive directory uploads and more! Besides the most
complete feature set, FileUp includes documentation, a large set of sample
ASP pages, and an extensive tutorial. .NET, ASP & VB
Allows working with safearray binary data. Enables binary file
upload to the ASP and download from ASP with on-fly compression or
generation binary data (Using Response.BinaryWrite and
Request.BinaryRead). Enables calling some of Kernel and Advapi functions
and work with processes and threads.
In this article, Marco Nanni examines an example of multiple binary file uploading for Web applications using XML, without the typical limitations of traditional file upload processing. [Read This Article][Top]
Build multipart MIME upload forms using the InputFile HTML Server Control and learn how to take advantage of the file-upload services built into the HTTP runtime for ASP.NET. Save the uploaded file to disk without granting anonymous users file-write access to folders on your Web server. Then wrap all this in a new ASP.NET user control, which will allow you to add file upload capabilities to almost any Web page quickly and easily. [Read This Article][Top]
Building an upload file mechanism on a Web server can often require using a
costly DLL. Tiago Halm's article shows you how to upload a file using only Active
Server Page (ASP) code and Internet Explorer. Sample code is provided. [Read This Article][Top]
This article by Sander Duivestein examines the upload components currently on the market and gives his opinion about how they work. Sander takes the reader through his requirements for uploading and the solutions that he used. [Read This Article][Top]
This article was written for VB5/VB6 or ASP programmers want to explore server-side ActiveX ASP components and may be looking for a “how to” code demonstration of uploading files from an Internet browser. [Read This Article][Top]
In this article by Peter Persits, of Persits Software, discusses how the browser uploads files to the server and how to deal with the data streams. He demonstrates Request.BinaryRead and the different data streams returned by browsers that follow RFC 1867. He also shows how to use AspUpload to handle files that are uploaded to the web server. [Read This Article][Top]
In this article David Wihl, of Software Artisans, discusses the options available for uploading files to a web server. He also compares SA-FileUp with the Posting Acceptor and provides example code for uploading files with SA-FileUp. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
