In-depth study of "uploading Files with ASP" (i)

The idea of a "thin client" is now a myth, but it will change with the boom in TV or palm-style browsers. Today, the vast majority of Web customers still use powerful PCs, attached to a large number of client storage and client-side content. There are some options for passing files to a central server under Internet Protocol, but web-based file uploads are more advanced than other methods. Let's check this out.
One, HTTP and FTP way comparison


Why do you want to upload?

　　
File uploads play an important role in any network application. Here are some examples of how some of our customers have uploaded files and their Web applications together:

1, web-based e-mail form, file upload to the message information to add accessories
2. External Internet applications upload files between partners, such as protocol certificates, software updates, or files
3, the technical support site with file upload from the user to receive error records and problematic files
4, the Enterprise internal Internet literature publication uses the friendly network interface to share the file among the user
5, graphics library file Upload control submission, produce a sketch
6, the ISP host store with file upload Send product image

Comparison of HTTP and FTP methods

In the early days of TCP/IP, FTP was the standard mechanism for transferring files to the server. It is reliable, acceptable in text and binary format and can be executed anywhere, but it is far less adaptable than HTTP. Here's a comparison:

Reliability: Upload with FTP, either manage a large number of user accounts, or allow anonymous access. With a Web application upload, an application can determine who is allowed to upload, eliminating a huge administrative burden.

Security: An available SSL encoding is uploaded over HTTP so that information can be encrypted during the transfer process. Can not be done with FTP.

Easy to configure: FTP uploads require an administrator to accurately adjust NTFS permissions. With HTTP based uploads and applications, both administrators and applications can decide, if necessary.

Adaptability: Do you want to store doc files in one place and store graphics in another? Using FTP, users must know these storage paths. In a Web application, you can control it, and you can modify it without disturbing the user.

Ability: With Web applications, each invocation can dynamically control the size of the uploaded file, even depending on the information in the same form. You can also flush out uploaded files that meet a certain standard, such as the wrong MIME type or file type.

Simplicity of the interface: A favorite Web page can provide guidance, advice, and online Help, and FTP based on batch processing is impossible. More importantly, when an error occurs, the Web can immediately provide feedback to the user and make corrections.

Firewall support: For security and intellectual property considerations, many organizations do not allow external FTP. With a simple configuration, most firewalls support HTTP.

Supplemental information: An HTTP upload (with RFC1867) also provides other available information, such as the user's original filename, which is particularly useful in an internal internet environment.

Upload to a database: Allows uploading to the OLE DB database using server-side components such as sa-fileup. But with FTP, but absolutely can not do this!

Performance: FTP and HTTP end up with the TCP protocol, which is the determining factor for transmission performance.

Reliability and re-uploading: FTP and HTTP 1.1 allow for a reboot of the transport. Unfortunately, many servers, including IIS, cannot now support the ability to upload any of the protocols. The FTP upload feature will be implemented in the IIS5 version.

In short, as with the web itself, the programmability of the server makes HTTP uploads a great advantage over FTP.

HTTP upload format

There are three file mechanisms for uploading over HTTP, they are RFC1867, put, and WebDAV.

HTTP Upload Method 1:rfc1867

RFC1867 (Http://info.internet.isi.edu/in-notes/rfc/files/rfc1867.txt) is the IETF's recommended standard for a period prior to the final launch of HTML 3.2. First, Netscape runs in Navigator 2.0, followed by Microsoft as an add-on to IE 3.02 (32-bit) and as a self-contained content of IE 3.03 (16-bit). It's a very simple but powerful concept: defining a new type of format field

< INPUT type= "FILE" >
Then add a different encoding scheme to the form:
< FORM action= "formproc.asp" method= "POST" enctype= "Multipart/form-data" >
Instead of using a typical:
< FORM action= "formproc.asp" method= "POST" >

This encoding scheme is more efficient than the default "application/x-url-encoded" format encoding scheme when transferring large amounts of data. As you may know, the character sets available for URLs are very limited. Any character set that goes out of range is replaced with '%nn ', where nn is the corresponding two-bit hexadecimal number. Even the most commonly used whitespace characters are replaced with '%20 '. If the browser has to encode the entire file with such a low efficiency encoding, the upload file may be 2 to 3 times times larger than the original file. RFC1867, however, uses multipart MIME encoding, as is often seen in e-mail messages, to transmit large amounts of data without encoding, but with only a few simple, useful headers around the data.

The result looks like a regular HTML post form, implemented on a 4 KB form, representing data that can be gigabytes. RFC1867 also proposes some suggestions to be adopted by the browser provider, that is, some properties of the type= "FILE" statement. These include:

ACCEPT (accepted): Allows a Web site to limit the types of files that will be uploaded before receiving a file.
Size: Sets the sizes of individual file name text boxes or allows multiple files to use a single < INPUT > statement.
MAXLENGTH (maximum length): The maximum size of uploaded files set on the client.
Wildcard and upload paths: Although RFC has this recommendation, both IE and navigator do not support wildcard and path uploads.
Fortunately, both browsers support the "Browse ..." button, and the user can easily select the file to be uploaded with the "Open File ..." dialog box.

The use of the value clause is interesting. For the convenience of the user, you can have the Web preset the values for the form fields. But in this case, it makes some bad Web sites can preset upload file names, plus a client-submitted form, you can steal files from their PCs without user permission. In the summer of 1997, a security warning was issued by cert and a bell lab employee, and Netscape and Microsoft soon released patches to prevent the preset upload files.

The original RFC1867 clearly stated: "It is important that the agent cannot transmit any files to the user without a specific requirement." "So the browser could simply send out a warning dialog box, for example," Do you want to send files x, y, Z to the server? Instead of completely banning the preset file names. However, there is a security hole in the IE4.01, so that the site can be spared ie existing security mechanisms. (See http://www.microsoft.com/windows/ie/security/paste.htm)

HTTP Upload Method 2:http put

HTTP 1.1 introduces a new HTTP verb: put. When a network server receives an HTTP put and the object name ("/myweb/image/x.gif"), it identifies the user, takes the contents of the HTTP stream, and stores it directly to the network server. This method can cause great damage to the network, so it is not used frequently. And it gives the biggest advantage of HTTP---server programmability. In the case of put, the Web server itself handles the request, and there is no room for CGI or ASP applications to intervene. The only way an application captures put is to operate at a low, ISAPI level. Most network developers are not interested in this for a variety of reasons.

HTTP Upload Method 3:webdav

WebDAV (http://www.ietf.org/html.charters/webdav-charter.html) allows distributed authorization and publishing of network content. It introduces several verbs that can upload, lock/unlock, enter/exit HTTP content. We can think of it as a unique configuration management (such as source security) plus network File transfer. Microsoft has publicly announced that IIS5, Office 2000, and future IE versions will support it. ISPs are willing to replace the low-level, trouble-prone FrontPage server attached to the mechanism. Note that it is not a replacement for the FrontPage Server add-on, it simply provides low-level standard services to support the more complex functionality being performed by the server add-on. At the PDC in October 98, you can see that Office 2000 completes the "Save to the Network" ("Saved to Web") task through WebDAV.

Sounds great, doesn't it? If you want to upload content, WebDAV is good and it can solve a lot of problems. But if you want to upload files within a Web application, WebDAV is powerless. Like the HTTP put, WebDAV is interpreted by the server rather than by the application, and the WebDAV action needs to be used at the level of the ISAPI filter and the content is interpreted in the application.

HTTP Upload mechanism: summary

RFC1867 is still the most flexible way to upload a file to a Web application. The use of put is limited, and WebDAV is good for content authors, such as FrontPage users, but it does little for web developers who want to add file uploads to Web applications.