This a document is a guide for the OrangeML platform (or CAdap platform).

As such, after a brief overview of the CAdap platform, it details its various features. The last section lists all the available OrangeML platforms.

The CAdap (Content Adaptation) platform is a reverse proxy that stays between the end-user and your server.

This means that the end-users always access your server through the CADAP.

The figure above gives an overview of how it works:

1. The device send a request to the CADAP reverse proxy, asking for a piece of content from your server
2. The CADAP reverse-proxy “forwards” this request to your server in order to get this piece of content
3. Your server return the piece of content
4. If the piece of content is an OrangeML page (i.e. content-type=text/orangeml), the CADAP identifies the device and its browser, in order to select the right transformation rules
5. If the piece of content is an OrangeML page (i.e. content-type=text/orangeml), the CADAP applies these rules to transform the content
6. If the piece of content is an OrangeML page (i.e. content-type=text/orangeml), the CADAP returns the result of this transformation to the end-user, otherwise it returns your content as it is.

Important note : the CAdap platform acts as a transparent reverse-proxy. As such it automatically rewrites the links of your OrangeML pages so that these links point on the CAdap itself (instead of pointing on your server). As a consequence, you always have to develop your pages as if the reverse-proxy wouldn't exist..

Sometimes, it might be usefull for you to check if the request received by your server comes from CADAP or comes directly from the client.

For example, let's consider that if your service has a single URL for several versions, one OrangeML version for mobiles and one HTML version for PC. You would have to route request from CADAP to the OrangeML version and to route other requests to the HTML version.

The best way to do that is to check the value of the accept HTTP header of the incoming request (cf. http_headers for more information about HTTP headers and CADAP). If this header contains text/orangeml, the request comes from a CADAP platform, otherwise it comes from somewhere else.

This section describes the main features of the CAdap platform :

• The URL syntax (i.e. how to specify the requested page when you send a request to the CAdap)

• The URL rewriting

• MCO and language management

• OrangeML validation

• HTTP headers

• HTTPS support

• Image adaptation

When the end-user sends a request to the CAdap platform, it has to identify the actual requested piece of content with the appropriate URL syntax.

Two syntaxes are available with CAdap

• The “external” syntax, which is available on all CAdap platforms, except the corporate instances (cf. available CADAP platforms last section)

• The “internal” syntax, which is used by MDSP instances of CAdap platforms

Let's consider that this piece of content is hosted at

http://www.myserver.com/dir1/dir2/page?par1=value1&par2=value2 

Then the end-user has to request the following URL

http://www.cadap.com/httppvc_clnsswww.myserver.com/dir1/dir2/page?par1=value1&par2=value2 

Where

• http://www.cadap.com/ is the URL of the CAdap platform (cf. Available CADAP platforms for the actual URL)

• httppvc_clnss stands for “http” “column” (cln) “slash” (s) “slash” (s), i.e. http://

If your server is listening on another port, i.e. if your URL is something like

http://www.myserver.com:8080/dir1/dir2/page?par1=value1&par2=value2 

Then you can access your content through the CAdap with the following URL:

http://www.cadap.com/httppvc_clnsswww.myserver.compvc_cln8080/dir1/dir2/page?par1=value1&par2=value2 

Where

• http://www.cadap.com/ is the URL of the CAdap platform (cf. last section)

• httppvc_clnss stands for “http” “column” (cln) “slash” (s) “slash” (s), i.e. http://

• pvc_cln stands for “column”

On corporate platforms (aka MDSP or Next platforms), the external syntax is not supported. In these case, you have to use “internal” syntax for your URLs.

Let's consider that your piece of content is hosted at

http://www.myserver.com/dir1/dir2/page?par1=value1&par2=value2 

Then the end-user has to request the following URL

http://serveralias.cadap.com/dir1/dir2/page?par1=value1&par2=value2 

Where

• http://myalias.cadap.com/ is a hostname of the CAdap platform

To use this syntax, you'll have to ask Orange Corporate to create a mapping for your server on the Orange Corporate platform. The mapping will associate the prefix http://myalias.cadap.com/ to your server http://www.myserver.com, meaning that each new internal service will require a new DNS name to access the CAdap platform.

Note: this syntax is only required for the Orange Corporate production environment. During the development of your service, you should use the “external” syntax (cf. last section)

The CAdap platform acts as a transparent reverse-proxy. This means that it automatically rewrites the links of your OrangeML pages so that these links point on the CAdap itself (instead of pointing on your server). This feature is obviously enabled only for the external mode.

For example, let's consider the following OrangeML snippet:

...
<block>
 <a href="http://www.myserver.com/nextpage">Link to next page</a>
</block>
...

This code will be automatically rewritten by the CADAP platform into :

...
<block>
 <a href="http://www.cadap.com/httppvc_clnsswww.myserver.com/nextpage">Link to next page</a>
</block>
...

The rewriting rules depend on the type of URL (absolute, relative to the current directory or relative to the root directory). It also depends on the URL syntax used to access the CAdap (i.e. internal or external).

But whatever the type of the URL and the CAdap URL syntax, all the links are rewritten to point on the CAdap platform

This rewriting also affects cookie domain and redirect location. At the end of the day, you have to develop your page as if the CAdap wouldn't exist and never mention explicitely the CAdap URL in your code.

Note: For very special cases, you can disable the URL rewriting for a link by using the nphttp:// (i.e. non-proxy HTTP) URL schema instead of http://

For example, if we consider the following OrangeML snippet:

...
<block>
 <a href="nphttp://www.myserver.com/nextpage">Link to next page</a>
</block>
...

This code will be automatically rewritten by the CADAP into :

...
<block>
 <a href="http://www.myserver.com/nextpage">Link to next page</a>
</block>
...

Some CAdap platforms produce different renderings depending on the MCO (Member Company of Orange) and the language (locale).

You can specify the MCO and the language by adding some parameters in the URL as follows:

http://www.myserver.com/dir1/dir2/page?par1=value1&par2=value2&MCO=OBE&LANG=fr

Where OBE stands for Orange Belgium (Mobistar) and fr stands for french.

Notes:

• The LANG parameter is only considered for multi-locale MCOs (i.e. Belgium, Romania and Switzerland)

• If the MCO is not specified, OFR is considered as a default

• The MCO and LANG parameters are automatically propagated by the URL rewriting. This means that you don't have to mention these parameters explicitely in your code.

Some platforms provide an online validation of your OrangeML pages. If your page doesn't conform the OrangeML schema, the platform will render an error page that describes the OrangeML syntax error(s). If needed, you can bypass this validation by adding bypass-validation=true as a parameter of your URL. The validation is obviously NOT active on production platforms.

The OrangeML platforms provide a facility to access to your OrangeML page without any transcoding. This feature can be usefull to debug your service.

To do that, you just have to set the User-Agent of your browser to OMLTEST. To change the user agent of your browser, you can use User-Agent switcher on Firefox.

The CAdap platform only consider the following HTTP headers

• location : the URL to reach when your server returns a redirect (cf. URL rewriting)

• set-cookies: the cookies set by your server (cf. URL rewriting)

• content-type: the content-type of your page. The CAdap applies the OrangeML transformation only if the contet-type is text/orangeml

Other HTTP headers are transmitted as this to the client.

The CAdap platform transmits all the header sent by the end-user except

• referer

• if-modified-since

• if-none-match

• host

It transforms the following headers

• accept-encoding: remove gzip,deflate

• accept: add text/orangeml (you can use this header to check if the request comes from a CAdap or not)

It adds the following headers

• via: the name of the CAdap instance

• X-Cadap-Version: the version of the CAdap instance

• screenCapability: the screen capability of the device (intermediate for XHTML devices, low for WML devices). This header is added only by MDSP CAdap.

The CAdap platform supports secured HTTP (HTTPS).

This is not an end-to-end support as the request is decripted in the CAdap and re-encrypted when it goes out of CAdap.

Some CAdap instances support HTTPS only between the CAdap platform and your server (HTTPS out). Other also support HTTPS between the end-user and the CAdap (HTTPS out). Most of the CAdap platforms perform a control on your certificate. See Available platforms for more details.

Some platforms provide facilities to automatically adapt the size of images according to the device capabilities and the mode of the image. To use this facility, set the adapt attribute of your <img> tag to 'proxy'.

When an error occurs, most platform return a user friendly error pages (e.g. Service unavailable). It's user friendly, but it doesn't provide any information regarding the error itself. To get a full error message, simply add tellmeall=true in your URL.

This section gives the list of available CAdap platforms.

Each platform is caracterized by

• its server name

• its URL syntax

• its output markups for OrangeML

• its supported MCOs

• its validation support

• wether it supports image adaptation or not

• its access restriction

• its HTTPS support

Most of these platforms are used only in production or integration environment. For the development of your pages, you must use the development platform (ocp1.ccett.fr)