-
-<p>Applications are communicating with their private binder(afb-daemon) using
-a network connection or potentially any other connection channel. While current version
-does not yet implement unix domain this feature might be added in a near future.
-Developers need to be warn that HTTP protocol is a none connected protocol. This prevents
-from using HTTP socket connection to authenticate clients.</p>
-
-<p>For this reason, the binder should authenticate the application
-by using a shared secret. The secret is named “token” and the identification
-of client is named “session”.</p>
-
-<p>The examples <strong>token-websock.qml</strong> and <strong>afb-client</strong> are demonstrating
-how authentication and sessions are managed.</p>
-
-<a name="Handling.sessions"></a>
-<h3>Handling sessions</h3>
-
-<p>Plugins and other binder feature need to keep track of client
-instances. This is especially important for plugins running as services
-as they may typically have to keep each client’s data separated.</p>
-
-<p>For HTML5 applications, the web runtime handles the cookie of session
-that the binder afb-daemon automatically sets.</p>
-
-<p>Session identifier can be set using the parameter
-<strong>uuid</strong> or <strong>x-afb-uuid</strong> in URI requests. Within current version of the
-framework session UUID is supported by both HTTP requests and websocket negotiation.</p>
-
-<a name="Exchanging.tokens"></a>
-<h3>Exchanging tokens</h3>
-
-<p>At application start, AGL framework communicates a shared secret to both binder
-and client application. This initial secret is called the “initial token”.</p>
-
-<p>For each of its client application, the binder manages a current active
-token for session management. This authentication token can be use to restrict
-access to some plugin’s methods.</p>
-
-<p>The token must be included in URI request on HTTP or during websockets
-connection using parameter <strong>token</strong> or <strong>x-afb-token</strong>.</p>
-
+<p>Applications are communicating with their private binder(afb-daemon) using a network connection or potentially any other connection channel. While current version does not yet implement unix domain this feature might be added in a near future. Developers need to be warn that HTTP protocol is a none connected protocol. This prevents from using HTTP socket connection to authenticate clients.</p>
+<p>For this reason, the binder should authenticate the application by using a shared secret. The secret is named "token" and the identification of client is named "session".</p>
+<p>The examples <strong>token-websock.qml</strong> and <strong>afb-client</strong> are demonstrating how authentication and sessions are managed.</p>
+<h3 id="handling-sessions">Handling sessions</h3>
+<p>Plugins and other binder feature need to keep track of client instances. This is especially important for plugins running as services as they may typically have to keep each client's data separated.</p>
+<p>For HTML5 applications, the web runtime handles the cookie of session that the binder afb-daemon automatically sets.</p>
+<p>Session identifier can be set using the parameter <strong>uuid</strong> or <strong>x-afb-uuid</strong> in URI requests. Within current version of the framework session UUID is supported by both HTTP requests and websocket negotiation.</p>
+<h3 id="exchanging-tokens">Exchanging tokens</h3>
+<p>At application start, AGL framework communicates a shared secret to both binder and client application. This initial secret is called the "initial token".</p>
+<p>For each of its client application, the binder manages a current active token for session management. This authentication token can be use to restrict access to some plugin's methods.</p>
+<p>The token must be included in URI request on HTTP or during websockets connection using parameter <strong>token</strong> or <strong>x-afb-token</strong>.</p>