Browse Prior Art Database

Dynamic Test Methodology for Programs Involving Request and Response Modifications Disclosure Number: IPCOM000014032D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 3 page(s) / 46K

Publishing Venue



Main Idea

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 52% of the total text.

Page 1 of 3

  Dynamic Test Methodology for Programs Involving Request and Response Modifications

Main Idea

A problem was encountered in testing IBM's Everyplace Wireless Gateway, see diagram below. The Wireless Gateway acts as protocol transforming proxy server. It executes protocol transformations at the network and application layers. This invention is focused at the application layer. To use the Wireless Gateway, in this context, a user 1agent formulates a Wireless Session Protocol(WSP) method and delivers it to the Gateway over the Wireless Datagram Prorocol(WDP) , both are components of the Wireless Applications Protocol(WAP) suite. The WAP gateway decodes the WSP 2method delivered to it via WDP, maps the method to HTTP, and forwards the 3transformed request to the content server via HTTP. Once the response returns, its 4header is stripped of fields not supported by WAP, it is encoded, and forwarded to the WAP user agent over the bearer network. This is an oversimplification of the feature set contained in the IBM EveryPlace Wireless Gateway, but it is suitable for the purposes of describing the invention.

The problem presents itself when one considers how to effectively and efficiently test both the request and response pathways through a WAP gateway. The central ideas of the solution and invention are threefold.

First, is to control the HTTP response header and body from the user agent making the request. The response header attributes are extracted from the request body and the response header is formulated. The response body is formulated to indicate request and response header attributes and other data relevant to the scenario.

Second, is the dynamic preparation of an expected response by the requestor. Since the requestor knows how the URI will respond to the request presented by the gateway, and since the requestor has an expectation of the HTTP response's mapping to WSP, then, the requestor can prepare an expected response for comparison to the actual one received at the time it issues the WSP method. This expectation could be stored on the requesting machine or in a more novel approach it can be digitally signed and attached to the request. The value of the digital signature is that it will allow the comparison operation to detect if the WAP Gateway manipulated the expected response in either of the request or response pathways. The advantage in attaching the expected response to the request is decreased processing and storage by the requesting machine. The comparison of the actual response to the expected one could then be done by another workstation.

And third, is tight control of the timing of the release of responses from the content server. Here, gateway timers and performance can be tested by extracting a latency, for the content server to withhold release of the response, from the request body.


Page 2 of 3

Some advantages of u...