--- a/Symbian3/SDK/Source/GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,96 +1,96 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66" xml:lang="en"><title>HTTP Client
-overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<section id="GUID-D44E394A-3FB9-4884-A8AB-6E8E252ACBFC"><title>Purpose</title> <p>The
-HTTP (Hypertext Transfer Protocol) Client API provides a client interface
-for Internet applications to use the HTTP protocol for communication with
-HTTP servers on the Internet. Using the API correctly enables the application
-to be a conditionally HTTP 1.1 compliant client, as defined in RFC 2616. </p> <p>The
-HTTP protocol is a request and response protocol. A client sends a request
-to the server. This request consists of a request method, URI, and protocol
-version, including a Multipurpose Internet Mail Extensions (MIME)-like message
-containing request modifiers, client information, and body content over a
-server connection. The server responds with a status, which includes the message's
-protocol version and a success or error code, and a MIME-like message containing
-server information, meta information, and body content. The following image
-illustrates a simple HTTP session between a client and a server. </p> <fig id="GUID-784DD05A-B86B-57F0-A2E0-A34E373ABA34">
-<title> Simple HTTP Interaction </title>
-<image href="GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e212244_href.png" placement="inline"/>
-</fig> <p>See <xref href="http://www.ietf.org/rfc/rfc2616.txt" scope="external">Hypertext
-Transfer Protocol -- HTTP/1.1, RFC 2616</xref> for more details. </p> </section>
-<section id="GUID-80DD2A3D-1C59-4AD5-8838-8DC9E1752729"><title>Architectural
-relationships</title> <p>The HTTP Client architecture provides a generalised
-mechanism for HTTP-like protocols that operate over various transports. Using
-a single API, a client can choose an HTTP protocol, encoding, and transport,
-and need not implement these in its own code. The default operation provides
-plain-text HTTP (as defined in RFC 2616) operating over a TCP/IP connection.
-This transport pipelines requests by default. </p> </section>
-<section id="GUID-4F83C7A0-C17F-4C58-840E-3E51EA52F098"><title>Description</title> <p>There
-are five key concepts used in the API: sessions, transactions, headers, data
-suppliers, and filters. </p><p><b>Sessions </b> </p> <p>A session encapsulates
-the client's HTTP activity over the duration of the client's execution. Typicallly,
-one HTTP session runs in one active scheduler. </p> <p> <b>Note:</b> An active
-scheduler must be installed when a session is opened. </p> <p>Usually, one
-session is used at a time. However, the client may use several concurrently,
-if required. Each session has an associated set of properties, which define
-the HTTP protocol, encoding, and transport used. Those properties apply to
-all HTTP transactions within the life of that session. The session also has
-an associated set of filters that provide additional automatic behaviours
-on the client's behalf. </p> <p>The session class is provided by <xref href="GUID-651801A5-5473-3856-9647-46823598C5C1.dita"><apiname>RHTTPSession</apiname></xref>. </p> <p><b>Transactions </b> </p> <p>A
-transaction represents an interaction between a HTTP client and an HTTP origin
-server. Normally a transaction consists of a single exchange of messages between
-client and server: a client request and a server response. However, the transaction
-may be extended or altered by filters that operate on it. See <xref href="GUID-AA2A730E-A7C9-5647-AD42-11C3BAF4C38D.dita">Filters</xref> for
-more details. </p> <p>Transactions execute asychronously within the client's
-process. The client is notified when events are available for each outstanding
-transaction. </p> <p>Both the request and response portion of a transaction
-consist of a header and an optional body. The request portion of the transaction
-also specifies an HTTP Method that describes the type of operation that the
-client wants to invoke at the origin server, together with a URI that specifies
-the resource held at the server on which the method is to be invoked. The
-response portion of a transaction contains an HTTP status code and message,
-which indicate the success of the method or the state of the resource following
-the method. The use of request and response bodies is determined by the HTTP
-method in use. For example, in error conditions, some servers may just return
-a status code and message, providing no entity body. </p> <p>The transaction
-class is provided by <xref href="GUID-2E673024-239B-3965-8880-C47B7CC24EF6.dita"><apiname>RHTTPTransaction</apiname></xref>. </p> <p><b>Headers </b> </p> <p>The
-header portion of requests and responses may have zero or more fields, which
-are used to convey information between the HTTP client and server. The information
-might relate to the data conveyed in body of the message, to the actual connection
-between the client and server, or might be used to convey data describing
-the client or server themselves. Typically, headers can contain content encoding
-and transfer encoding information. Since the HTTP API gives clients implementation
-independence from these choices, a generic form is used to represent header
-data in the API. </p> <p>The headers class is provided by <xref href="GUID-54F9A87B-FE2F-3429-9793-0A24B83466B9.dita"><apiname>RHTTPHeaders</apiname></xref>. </p> <p><b>Data
-suppliers </b> </p> <p>The body portion of requests and responses is represented
-in the API as a mix-in interface, allowing the real implementation of the
-classes that generate body data to be fully hidden. The API enables signalling
-between the client and the transport in use, to ensure that body data is only
-used or released at a rate the client can support. This means that clients
-can assemble the body of their requests piece-by-piece, have each piece transmitted
-only when it is ready, and be signalled when transmission is complete so the
-next piece may be prepared and the old one released. </p> <p>Data supplier
-classes must implement <xref href="GUID-1B03F068-9552-37BA-A284-8E54FAC2AAC5.dita"><apiname>MHTTPDataSupplier</apiname></xref>. </p> <p><b>Filters </b> </p> <p>Filters
-are add-on modules that provide additional behaviours to a session beyond
-the simple request-response transaction described earlier. Behaviours may
-be triggered by the presence of particular headers in a request or a response,
-by status codes in a response, or by particular events that occur on a transaction.
-RFC 2616 describes a number of standard behaviours that occur over a series
-of request-response exchanges: client authentication, redirection, and caching.
-Client authentication and redirection are implemented as individual filters. </p> <p>Filter
-classes must implement <xref href="GUID-2E1C08E2-9024-3269-A1BD-C6B901E78841.dita"><apiname>MHTTPFilter</apiname></xref>. </p> <p>Refer to <xref href="GUID-AA2A730E-A7C9-5647-AD42-11C3BAF4C38D.dita">Filters</xref> for more information. </p> </section>
-<section id="GUID-75720715-786A-4537-BC1B-949815E5E8AD"><title>Example code</title> <p>Example
-code used throughout this guide is taken from <filepath>HTTPEXAMPLECLIENT</filepath>,
-a simple console application that provides a menu-driven interface to the
-HTTP API. </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66" xml:lang="en"><title>HTTP Client
+overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-D44E394A-3FB9-4884-A8AB-6E8E252ACBFC"><title>Purpose</title> <p>The
+HTTP (Hypertext Transfer Protocol) Client API provides a client interface
+for Internet applications to use the HTTP protocol for communication with
+HTTP servers on the Internet. Using the API correctly enables the application
+to be a conditionally HTTP 1.1 compliant client, as defined in RFC 2616. </p> <p>The
+HTTP protocol is a request and response protocol. A client sends a request
+to the server. This request consists of a request method, URI, and protocol
+version, including a Multipurpose Internet Mail Extensions (MIME)-like message
+containing request modifiers, client information, and body content over a
+server connection. The server responds with a status, which includes the message's
+protocol version and a success or error code, and a MIME-like message containing
+server information, meta information, and body content. The following image
+illustrates a simple HTTP session between a client and a server. </p> <fig id="GUID-784DD05A-B86B-57F0-A2E0-A34E373ABA34">
+<title> Simple HTTP Interaction </title>
+<image href="GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e207449_href.png" placement="inline"/>
+</fig> <p>See <xref href="http://www.ietf.org/rfc/rfc2616.txt" scope="external">Hypertext
+Transfer Protocol -- HTTP/1.1, RFC 2616</xref> for more details. </p> </section>
+<section id="GUID-80DD2A3D-1C59-4AD5-8838-8DC9E1752729"><title>Architectural
+relationships</title> <p>The HTTP Client architecture provides a generalised
+mechanism for HTTP-like protocols that operate over various transports. Using
+a single API, a client can choose an HTTP protocol, encoding, and transport,
+and need not implement these in its own code. The default operation provides
+plain-text HTTP (as defined in RFC 2616) operating over a TCP/IP connection.
+This transport pipelines requests by default. </p> </section>
+<section id="GUID-4F83C7A0-C17F-4C58-840E-3E51EA52F098"><title>Description</title> <p>There
+are five key concepts used in the API: sessions, transactions, headers, data
+suppliers, and filters. </p><p><b>Sessions </b> </p> <p>A session encapsulates
+the client's HTTP activity over the duration of the client's execution. Typicallly,
+one HTTP session runs in one active scheduler. </p> <p> <b>Note:</b> An active
+scheduler must be installed when a session is opened. </p> <p>Usually, one
+session is used at a time. However, the client may use several concurrently,
+if required. Each session has an associated set of properties, which define
+the HTTP protocol, encoding, and transport used. Those properties apply to
+all HTTP transactions within the life of that session. The session also has
+an associated set of filters that provide additional automatic behaviours
+on the client's behalf. </p> <p>The session class is provided by <xref href="GUID-651801A5-5473-3856-9647-46823598C5C1.dita"><apiname>RHTTPSession</apiname></xref>. </p> <p><b>Transactions </b> </p> <p>A
+transaction represents an interaction between a HTTP client and an HTTP origin
+server. Normally a transaction consists of a single exchange of messages between
+client and server: a client request and a server response. However, the transaction
+may be extended or altered by filters that operate on it. See <xref href="GUID-AA2A730E-A7C9-5647-AD42-11C3BAF4C38D.dita">Filters</xref> for
+more details. </p> <p>Transactions execute asychronously within the client's
+process. The client is notified when events are available for each outstanding
+transaction. </p> <p>Both the request and response portion of a transaction
+consist of a header and an optional body. The request portion of the transaction
+also specifies an HTTP Method that describes the type of operation that the
+client wants to invoke at the origin server, together with a URI that specifies
+the resource held at the server on which the method is to be invoked. The
+response portion of a transaction contains an HTTP status code and message,
+which indicate the success of the method or the state of the resource following
+the method. The use of request and response bodies is determined by the HTTP
+method in use. For example, in error conditions, some servers may just return
+a status code and message, providing no entity body. </p> <p>The transaction
+class is provided by <xref href="GUID-2E673024-239B-3965-8880-C47B7CC24EF6.dita"><apiname>RHTTPTransaction</apiname></xref>. </p> <p><b>Headers </b> </p> <p>The
+header portion of requests and responses may have zero or more fields, which
+are used to convey information between the HTTP client and server. The information
+might relate to the data conveyed in body of the message, to the actual connection
+between the client and server, or might be used to convey data describing
+the client or server themselves. Typically, headers can contain content encoding
+and transfer encoding information. Since the HTTP API gives clients implementation
+independence from these choices, a generic form is used to represent header
+data in the API. </p> <p>The headers class is provided by <xref href="GUID-54F9A87B-FE2F-3429-9793-0A24B83466B9.dita"><apiname>RHTTPHeaders</apiname></xref>. </p> <p><b>Data
+suppliers </b> </p> <p>The body portion of requests and responses is represented
+in the API as a mix-in interface, allowing the real implementation of the
+classes that generate body data to be fully hidden. The API enables signalling
+between the client and the transport in use, to ensure that body data is only
+used or released at a rate the client can support. This means that clients
+can assemble the body of their requests piece-by-piece, have each piece transmitted
+only when it is ready, and be signalled when transmission is complete so the
+next piece may be prepared and the old one released. </p> <p>Data supplier
+classes must implement <xref href="GUID-1B03F068-9552-37BA-A284-8E54FAC2AAC5.dita"><apiname>MHTTPDataSupplier</apiname></xref>. </p> <p><b>Filters </b> </p> <p>Filters
+are add-on modules that provide additional behaviours to a session beyond
+the simple request-response transaction described earlier. Behaviours may
+be triggered by the presence of particular headers in a request or a response,
+by status codes in a response, or by particular events that occur on a transaction.
+RFC 2616 describes a number of standard behaviours that occur over a series
+of request-response exchanges: client authentication, redirection, and caching.
+Client authentication and redirection are implemented as individual filters. </p> <p>Filter
+classes must implement <xref href="GUID-2E1C08E2-9024-3269-A1BD-C6B901E78841.dita"><apiname>MHTTPFilter</apiname></xref>. </p> <p>Refer to <xref href="GUID-AA2A730E-A7C9-5647-AD42-11C3BAF4C38D.dita">Filters</xref> for more information. </p> </section>
+<section id="GUID-75720715-786A-4537-BC1B-949815E5E8AD"><title>Example code</title> <p>Example
+code used throughout this guide is taken from <filepath>HTTPEXAMPLECLIENT</filepath>,
+a simple console application that provides a menu-driven interface to the
+HTTP API. </p> </section>
</conbody></concept>
\ No newline at end of file