Mobile Web

Page 1 of 2 | Next »

WAP Development Considerations

Although SSL tunneling closes the WAP gap and improves user security, it effectively takes the WAP gateway out of the service delivery loop for the duration of secure data exchanges between you, the developer and the user.

While SSL connections are active, the WAP gateway only transfers SSL-encrypted data between you and the user. During this time, the WAP gateway has no visibility into the HTTP-based services accessed by the user or the content delivered by you. The WAP gateway is also prevented from adding, modifying, or viewing any data in the HTTP layer, including the service URL, HTTP headers, and HTTP response codes.

Implications for Developers

The WAP gateway cannot provide the user identity to you when using https. "User identity" is the SUB ID.
The WAP gateway cannot add any HTTP cookies to user requests or store any cookies from your responses.
The WAP gateway cannot indicate its content translation capabilities to you, or ensure compatibility of returned content for the user's device.

Recommended Design Approaches

The design alternatives discussed below are recommended in the following order based on the user experience effects of the different solutions.

Device-based cookies
URL-based session ID
URL-based parameters

The cookie-based solution (#1) should result in the least impact to the user experience. In the majority of cases, cookie-based user identification can be provided with no impact to service delay or cost.

The URL-based solutions (#2 and #3) would result in more redirects for user identification discovered by the developer, adding to service delay and cost. The additional redirects could also put service reliability at risk, since some devices support at most five HTTP redirects in sequence. The use cases most at risk would be those in which one developer redirects the user to a secure URL at another developer.

That being said, here are the general guidelines to simplify your wireless application development, ensure backward compatibility, and reduce maintenance of your WAP 2.0 applications.

Get the User Identity for Secure Services. If your wireless applications depend upon the reception of the AT&T SUB ID, and also use secure HTTP connections, you will need to use one of the methods described in WAP 2.0 User Identification for Secure Services.

Manage Cookies. The WAP 2.0 gateway cannot act as a cookie proxy for secure Web sites. Typically, cookies are managed on WAP 2.0 devices. If your application is dependent upon cookies, be aware that you will be competing for limited cookie space on WAP devices.

Be Aware of Gateway Limitations. The WAP 2.0 gateway cannot compress or translate content from secure web sites. If you are providing a service over a secure connection, be aware of device page limits and content compatibility as indicated by HTTP headers or the User Agent Profile (UAProf).

Avoid Coding Capability Assumptions. When developing WAP applications, avoid coding capability assumptions through Accept and UAProf headers for all WAP 1.2.1 and WAP 2.0 clients.

Utilize Device-Indicated Capabilities. Dynamically use Accept Headers and UAProf if possible. With WAP 2.0, content servers can retrieve, process and cache UAProf information.
Use Device Capability Libraries. If your application isn't able to use Accept and UAProf headers dynamically, as an alternative you can build device capability libraries using UAProf during application development. Libraries can be updated and maintained without making changes to your application.

Use Wireless Cascading Style Sheets (wCSS). The xHTML Mobile Profile supports style sheets through the style language WAP CSS (WCSS). WCSS is a subset of CSS2 and includes WAP 2.0-specific extensions to provide enhanced support for mobile phones. Ensuring compatibility should be easier with WAP 2.0 given the use of some new design methods.

Use the User Agent Profile (UAProf). The UAProf is an XML document containing numerous details of device capabilities. The Uniform Resource Identifier (URI) reference to the UAProf is delivered to origin servers with every request from the UAProf-supporting device. UAProf documents are typically hosted on a Web server operated by the device vendor. Depending upon the type of request, developers can look for the UAProf reference in the following headers:
- The UAProf "vocabulary" is defined by the Open Mobile Alliance (OMA). For non-secure requests through the WAP 2.0 gateway, the UAProf URI will be included in the "13-Profile" header. Example: OPT: "http://www.w3.org/1999/06/24-CCPPexchange ; ns=13" 13-Profile: "http://nds.nokia.com/uaprof/n5100r200.xml" The Opt header indicates that an HTTP extension header is included, and includes a reference to the related HTTP namespace. In the AT&T WAP 2.0 gateway, this is assigned a value 13. Thus, the "13-Profile" header includes the UAProf URI.
- For secure requests through the WAP 2.0 gateway, the UAProf URI will be included in the "x-wap-profile" header. Example: x-wap-profile: http://nds.nokia.com/uaprof/n5100r200.xml The "x-wap-profile" header is used in this case since the request is received over an SSL tunnel direct from the device, and this is the standard header defined by the OMA.
- For all requests via the WAP 1.2.1 gateway, the UAProf URI will be included in the "Profile" header. Example: Profile: http://mobileinternet.panasonicbox.com/UAprof/GU87/R1.xml

Download WAP 2.0 User Identification for Secure Services for complete developer approaches and guidelines.