http transaction session

http://developer.bada.com/help_2.0/index.jsp?topic=/com.osp.cppappprogramming.help/html/dev_guide/net/http_transaction.htm

http://www.jwall.org/articles/re_proxy.jsp

 

HTTP Transaction

An HTTP client can have multiple concurrent sessions, and each session can have multiple transactions.

A transaction represents an interaction between an HTTP client and an HTTP origin server. An HTTP transaction is a two-way communication between the client and the server: a client request and a server response. In a basic HTTP transaction, the client sends a request to the server, and the server processes the request and sends a response back to the client.

The following figure describes the general HTTP client structure for sessions and transactions.

Figure: HTTP sessions and transactions

An HTTP transaction is implemented using the Osp::Net::Http::HttpTransaction class. The request and response portions of a transaction are composed of a header and an optional body. The header is a collection of header fields defined by and accessed through the Osp::Net::Http::HttpHeader class. Header fields can be created, read, modified, and removed through this class, and each field can have multiple values.

The request portion of the transaction specifies an HTTP method that describes the type of operation that the client wishes to invoke on the origin server. It also states the URI, which specifies the resources held on the server where the HTTP method is to be invoked. The response portion of a transaction contains an HTTP status code and a message, which indicates the success of the method or the state of the resources following the method.

The transaction can be submitted using one of the following modes:

• Non-chunked mode (default)

  To send an HTTP request in non-chunked mode, add a header field Content-Length: body-length to a request header.

• Chunked mode

  To send an HTTP request in chunked mode:

  1. Add a header field Transfer-encoding: chunked to a request header.

  2. Use the HttpTransaction::EnableTransactionReadyToWrite() method.

  3. Implement the OnTransactionReadyToWrite() event handler to send the chunks. An empty chunk is considered as the last chunk.

The request-response procedure is executed asynchronously. The client is notified when events are available for each transaction. The HTTP transaction procedure is also an event-driven procedure, and for each transaction, an event listener which implements the Osp::Net::Http::IHttpTransactionEventListener interface must be registered and maintained.

Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server. HTTP 1.1 solves this problem by allowing multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requesting client waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests this way can result in a dramatic improvement in page loading times, especially over high-latency connections.

 

 

HTTP Session

HTTP client access is based on HTTP sessions. An Osp::Net::Http::HTTPSession class encapsulates the client's HTTP activity over the duration of the client's execution. It consists of a set of transactions using the same connection settings (such as using a proxy). The client may use several sessions concurrently, if desired. It has an associated set of properties, defining the HTTP protocol and encoding, which are applied to transactions carried out during the life of that session.

There are 2 HTTP session modes:

• Normal mode
• Pipelining mode

In the normal mode, all the transactions within a session share the same connection. One session has one connection, and only one transaction is processed at a time.

Figure: Normal mode

Pipelining mode is similar to the normal mode in that it shares the connection, but multiple requests can be submitted concurrently without having to wait for each response. This results in a major improvement in page loading times compared to normal mode. Non-independent methods, such as POST, must not be pipelined. Sequences of GET and HEAD requests can be always pipelined.

Figure: Pipelining mode