Browse Prior Art Database

A method for handling communications failure in a Web browser scripting environment

IP.com Disclosure Number: IPCOM000114548D
Original Publication Date: 2005-Mar-29
Included in the Prior Art Database: 2005-Mar-29
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

In recent years there has been increasing exploitation of the Web browser as a vehicle for increasingly complex application logic. This has become a key component in the "zero footprint" application model and has given rise to all-Javascript (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both) productivity tools in software products. However this poses many challenges, particularly when the application is communications intensive since the APIs available to a developer are extremely rudimentary. A key aspect of this is determining when a communication exchange (i.e. over HTTP as there are no sockets available in Javascript) has failed for some reason.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

A method for handling communications failure in a Web browser scripting environment

In recent years there has been increasing exploitation of the Web browser as a vehicle for increasingly complex application logic. This has become a key component in the "zero footprint" application model and has given rise to all-Javascript productivity tools in software products. However this poses many challenges, particularly when the application is communications intensive since the APIs available to a developer are extremely rudimentary. A key aspect of this is determining when a communication exchange (i.e. over HTTP as there are no sockets available in Javascript) has failed for some reason.

  In the scenario outlined here, in order to satisfy reliable qualities of service a client must a) detect the failure and b) take action to resolve it. In this scenario, the well known technique of using very small IFRAME tags to handle communication with the server is adopted. When a POST request is made, these virtually invisible frames handle fielding multiple documents in the context of a single outer document without disturbing the user experience. Each request made results in a new document populating one of these IFRAMEs. Between the client and server, this HTTP traffic drives an HTTP Tunnelling protocol underlies the messaging protocol. HTTP Tunnelling provides TCP style packet-oriented communications using the HTTP protocol as transport. This protocol is responsible for synchronising packets sent by the client to the server, weeding out duplicates as necessary.

  As background, in order to submit anything via HTTP POST from a browser one must use an HTML form. An "HTTPRequest" Javascript object is provided in more recent browsers and is designed to provide an approach for executing HTTP POST without using a form.

  Javascript offers the "readyState" property on the document object which is supposed to yield "error" if a problem occurred loading the document. However this is unreliable and results in a security exception if one tries to introspect the "readyState" of a system error page (e.g. a "page not found" error...