Find Web Developers
Find Web Developers

How to Add File Upload Support to Your Web Site

Introduction

Providing the ability for visitors to your web site to upload files from their computer allows for the implementation of some very powerful features, such as for example letting your users share files with other visitors, or decorate their online presence on your site with an identifying portrait or avatar. In general, allowing for a file upload provides an easier way to share a large amount of data rather than extensive and tedious form-filling. However, while the file upload feature has long been supported by most Internet browsers, the precise details of how it is done can be quite tricky; the devil is indeed in the details. In order to correctly use this feature, you will need to perform some work both in the HTML and on the server side, and if you are writing client software to upload the file to an existing web site, you will need to know some details.

In the HTML and Browser

Adding a file upload button to a web page is relatively easy; it is just another type of INPUT field within an HTML FORM. Setting the type attribute of the INPUT field to “file” will provide an input field that allows file selection. Note that the actual upload of the file requires a little bit more work, including some server-side coding, which will follow shortly. The INPUT field may have other attributes set on it, such as size, which will allow control over the size of the display of the selected file, which should be very similar to a text field.

At this point, it is already worth noting that this HTML is likely to vary in appearance considerably from browser to browser. Typically, the form control thus created will consist of what looks like a text field, accompanied by a button that will launch the system file selector. Already, the appearance of the word “looks” should indicate there are possibly some accessibility issues with using this control. In both Internet Explorer and Firefox on Windows, the control appears as a text field with a button labeled “Browse…” next to it, with a few other visual differences. In Google Chrome, the button is labeled “Choose File”, and the text area where the name appears initially begins saying “No file chosen” and is just regular HTML text, not a text input field. There is a little control over the appearance of these visual elements via CSS, but some features, such as the actual text on the button, are chosen by the browser, not by the web developer. Furthermore, the button now means there are two button elements in the HTML FORM, not just a standard “Submit” button. This may cause some issues for browser users who are visually impaired or who use a different input method other than a mouse. In many ways, the appearance of the form may be unfamiliar to users, so your page should contain sufficient explanatory text, should be tested on many browsers, and perhaps should also provide an alternative method of supplying the file data.

Before leaving the HTML, there is one other change that needs to be made to a standard FORM – the enctype attribute of the form needs to be set to “multipart/form-data”. This is the most common omission when setting up a file upload form; if the enctype is left at its default value, “application/x-www-form-urlencoded”, your server will not receive the contents of the file at all, just the file name! This leads us on to the next observation; since the format of the data returned by the browser will be different, any standard form handling code you have will not work. You may need to make matching server changes as well.

On the server

As mentioned above, changing the encoding of the browser response to “multipart/form-data” is necessary so that actual file data is sent to the server; the standard form encoding does not handle arbitrary file sizes well. The encoding is based on the MIME standard for sending multipart messages, most recognizably used in email for file attachments. This makes sense since you are in effect attaching a file to a browser response, but note that the mechanism actually supports multiple files if necessary. Indeed, if there are other INPUT fields in your form, each of their results will also be returned as if they were a file attachment. This means the standard form handling code you have is unlikely to work.

Exactly what needs to be done on the server side depends highly on your server technology and the access rights you have on your site. You may need to contact your web hosting company, for example, to see if they already have a “canned” upload script that you could use. A blog widget or similar inclusion on a third-party site probably will not let you use this functionality. If you are the web developer, you should be able to search for “file upload” in your platform documentation; for example, Perl users will find file upload is supported in the CGI.pm module.

At this point, if what needs to be done appears too difficult, you should consider whether implementing file upload is really what you need, and be wary that there are many security and complexity issues that you may have to handle. What will you do with the files once they arrive? Where will you store them? What if, either accidentally or maliciously, a client tries to send you a huge file? What if the file never makes it to its destination? In cases like this, you may wish to consider an alternate provider to give you file upload capabilities. One use case was, for example, allowing your users to upload a picture or avatar of themselves. There are plenty of services to do that, such as Gravatar; your users might even prefer to see you integrate with Facebook or Twitter.

In client software

Nowadays, it is quite normal for programs other than web browsers to connect to web pages. If you are a developer for software that runs on smartphones, you may find yourself in a position where you need to upload a file to a web site without launching the browser. Again, the precise details vary depending on the platform you are using. Java developers may be familiar with the Apache HttpClient collection of utilities. Creating an HTTP POST using HttpClient is well-documented elsewhere, and a quick search for multipart posting highlights a MultipartPostMethod that is deprecated. The correct way in this case to post is to build a MultipartRequestEntity made up of one or more Part objects; a Part object can be configured to contain, among many other things, a file. A call to setRequestEntity() on the POST method will do exactly what is needed in this case.

What next?

Being able to upload a file to your web site opens the doors to some exceptionally powerful functionality, but the details seem to be a bit sparse online. You may go ahead and check RFC 1867, the original proposal dating back to 1995, and you may wish to try out this functionality in as many different browsers as you can find. You will most likely be surprised at the differences in look and feel. However, it is a good tool to have available in your web development arsenal, and the techniques illustrated here come in useful, even in modern web development environments.

Comments are closed.