Browse Prior Art Database

Web Services based incremental file upload

IP.com Disclosure Number: IPCOM000015775D
Original Publication Date: 2002-May-17
Included in the Prior Art Database: 2003-Jun-21
Document File: 7 page(s) / 438K

Publishing Venue

IBM

Abstract

1 Introduction As of today, human beings browsing Hypertext Markup Language (HTML) pages and filling out online forms are the most common kind of users of Web applications (a Web application comprises static content and server side application logic and is hosted by some Hypertext Transfer Protocol server and, optionally, an application server). In business-to-business (B2B) scenarios, however, client side IT systems also have to communicate with such Web applications. Often such system clients of Web applications want to upload files to the Web application, because they prefer a batch rather than dialog oriented communication style. For example, a parts supplier might want to update its catalog database on an e-Marketplace. Such files can be large (from one megabyte to several 100 megabytes), it is therefore desirable to transmit them incrementally and reassemble them on the server side. If such an incremental transfer mode is available, the client can resume the upload process with the first lost increment in case of transmission failures; it does not have to retransmit the entire file. Supporting resumption of broken file transfer operations is especially useful in the Internet environment, where reliability, response times, and stability on Hypertext Transfer Protocol (HTTP) level cannot be guaranteed. There is often no alternative to this protocol, because the target Web application is typically located behind a firewall that does not allow non-HTTP communication, because only one port, the HTTP port 80, is accessible. Standard HTTP security 1 features, however, such as Secure Socket Layer (SSL) and basic HTTP authentication should be available. The software prerequisites for the client should be minimal (thin client principle). If many clients from different companies use the services provided by a Web application, it is not realistic to assume that all of them share the same software configuration (such as a certain file transfer client). Hence, using protocols such as FTP for file upload is not always an option.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 25% of the total text.

Page 1 of 7

Web Services based incremental file upload

1 Introduction

As of today, human beings browsing Hypertext Markup Language (HTML) pages and filling out online forms are the most common kind of users of Web applications (a Web application comprises static content and server side application logic and is hosted by some Hypertext Transfer Protocol server and, optionally, an application server). In business-to-business (B2B) scenarios, however, client side IT systems also have to communicate with such Web applications.

Often such system clients of Web applications want to upload files to the Web application, because they prefer a batch rather than dialog oriented communication style. For example, a parts supplier might want to update its catalog database on an e-Marketplace. Such files can be large (from one megabyte to several 100 megabytes), it is therefore desirable to transmit them incrementally and reassemble them on the server side. If such an incremental transfer mode is available, the client can resume the upload process with the first lost increment in case of transmission failures; it does not have to retransmit the entire file. Supporting resumption of broken file transfer operations is especially useful in the Internet environment, where reliability, response times, and stability on Hypertext Transfer Protocol (HTTP) level cannot be guaranteed. There is often no alternative to this protocol, because the target Web application is typically located behind a firewall that does not allow non-HTTP communication, because only one port, the HTTP port 80, is accessible. Standard HTTP security 1 features, however, such as Secure Socket Layer (SSL) and basic HTTP authentication should be available.

The software prerequisites for the client should be minimal (thin client principle). If many clients from different companies use the services provided by a Web application, it is not realistic to assume that all of them share the same software configuration (such as a certain file transfer client). Hence, using protocols such as FTP for file upload is not always an option.

For HTTP, Request for Comment (RFC) 1867 (see [1]) specifies how a file upload can be handled using an additional Multipurpose Internet Mail Extensions (MIME) type (MIME is defined in RFC 1521, see [2]). Browsers such as Netscape 4.7.x and Microsoft Internet Explorer 5.x support RFC 1867. It is possible to implement a client API also implementing this RFC; such a solution would violate the thin client requirement, however, and could not support incremental file transfer.

Client and server implementation of such an incremental file transfer should be as independent of each other as possible (loose coupling principle). In a heterogeneous environment such as the Internet, they might not have been implemented in the same programming language.

This paper provides an interface specification, server side logic, and a client API

1

Page 2 of 7

supporting an incremental file upload...