352 Chapter 8 • Wireless Enabling Your Big Bandwidth Site map { print "$_ : $ENV{$_}<br>" } keys %ENV; print "</DISPLAY></HDML>"; } elsif (&detect_accept eq "wml") { #print WML header and print out results print "Content-type:text/vnd.wap.wml\n\n"; print<<HEAD; <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> HEAD print "<wml><card id='first' title='printenv'><p>"; map { print "$_ : $ENV{$_}<br/>" } keys %ENV; print "</p></card></wml>"; } To install the program, save the above text as printenv.cgi, and put it in your cgi-bin. If you are using a UNIX system, you will need to make sure that the file is executable and that the first line of the file corresponds to the location of your Perl installation. You can request the file (http://your.site.com/cgi-bin/printenv.cgi) with most any browser and view the complete list of environmental variables.There is no flow control in this script, so bear in mind that when you send the content to an actual device you may find that the deck is too large for the device to handle. However, the emulators that are available for both the UP.Browser and the Nokia WAP Toolkit do not suffer from the limitations imposed by WAP gateways.They will deliver the deck contents even if they are too large for an actual device. Redirecting Your Users to Static Content Now that your Web server is up and running and you know where to look to find out what types of content your users can accept, you can use this knowledge to give your users what they want: content. In this section we will cover how to redirect your users to separate static pages based on their browser. If you imple- ment this on your site, it will allow you to send all of your users to the same URL (http://your.site.com), regardless of the device that they are using.When www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 352 Wireless Enabling Your Big Bandwidth Site • Chapter 8 353 the user queries your URL, they will execute the redirection script (index.cgi) and be directed to an appropriate index page coded in either HTML,WML, or HDML. We will provide examples in PHP and Perl in the following sections, and also provide code samples of pages to make sure that the redirection example is working correctly.The first code sample should look very familiar. It’s a small HTML page that informs you (the user) that your script is correctly installed.The last two code samples are written in WML and HDML, respectively, and will dis- play the same message as the first example. Redirecting Users in PHP PHP stands for “PHP Hypertext Preprocessor” . It is a server-side scripting lan- guage that allows you to embed control structures within your markup. It has recently grown in popularity due largely to its portability, flexibility, and ease of use. <? $accept = getenv("HTTP_ACCEPT"); if ( eregi("vnd\.wap\.wml",$accept) ) { header("Location:/wml/index.wml"); } elseif ( eregi("text/x-hdml",$accept) ) { header("Location:/hdml/index.hdml"); } else { header("Location:/html/index.html"); } ?> Redirecting Users in Perl Practical Extraction and Reporting Language (Perl) has long been a favorite lan- guage of many Webmasters due to its utility and interpretive syntax. Perl can be used from the UNIX shell or implemented as a Web-accessible CGI program. In this subsection, we will provide a Perl program that will redirect users to a page, depending on the browser that they use to request the page. #!/usr/bin/perl $accept = $ENV{HTTP_ACCEPT}; if ( $accept =~ m%text/vnd.wap.wml%i ) { www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 353 354 Chapter 8 • Wireless Enabling Your Big Bandwidth Site print "Location:index.wml\n\n"; } elsif ( $accept =~ m%text/x-hdml%i ) { print "Location:index.hdml\n\n"; } else { print "Location:index.html\n\n"; } exit; Code for index.html: <html> <head> <title>Congratulations!</title> </head> <body> <h1>Congratulations!</h1> <p>If you can see this, it means that the redirect script installed on this server is working correctly!</p> <p>Your language type is: HTML</p> </body> </html> The code of this page is fairly straightforward; you probably don’t even need to put it into a browser to know exactly how it will look (Figure 8.6)! www.syngress.com Figure 8.6 Output of index.html 159_wg_wi_08 10/22/01 5:21 PM Page 354 Wireless Enabling Your Big Bandwidth Site • Chapter 8 355 Code for index.wml (also refer to Figure 8.7): <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="congrats" title="Congratulations"> <p> Congratulations!<br/> Your redirect script is working! <br/></p> <p>Your language type is: WML</p> </card> </wml> As noted throughout this book, one very important thing to note about WML documents is that they must contain valid markup. Unlike in HTML, there can be no stray or misplaced tags in your document.You’ll find this out very quickly when you start to code your own WML on a regular basis! Code for index.hdml (also refer to Figure 8.8): <hdml version=3.0> <display> Congratulations!<br> Your redirect script is working!<br> <br> Your language type is: HDML www.syngress.com Figure 8.7 Output for index.wml 159_wg_wi_08 10/22/01 5:21 PM Page 355 356 Chapter 8 • Wireless Enabling Your Big Bandwidth Site /display> </hdml> The third markup language that we will use is Handheld Device Markup Language (HDML), which is used by many of the legacy phones available in the United States. It is entirely up to you to decide which languages to support, but we suggest that if you want to reliably deliver content to users in the United States, build at least minimal HDML support into your site. The first element of this document specifies that it is an HDML document and that it is written in HDML 3.0. All HDML documents require a version statement in the first line.The next element, <display>, is a type of card that can be rendered with HDML.The other two types of cards that can be used are <nodisplay>, which does not display anything to the user, and <choice> cards, which allow the user to pick from a list of options.The HDML that you deliver does not need to be validated against a DTD (like WML), but it is always recom- mended that you code cleanly. Support for HDML is waning as support for WML grows, but there are a great many phones still in use that are only capable of rendering HDML. Some WAP gateways do on-the-fly transcoding of HDML to WML and vice-versa, for phones that do not natively support either language. Some gateways will even code HTML to WML, which we will touch on in the next section. Optimizing Content Distribution Just as you take care to manage the file system of your existing Web site, you should put some thought into the organization of your wireless site.You may wish to maintain two Web sites running on the same machine, one with the name of www.yoursite.com, and one with the name of wap.yoursite.com.This offers some benefits, as long as your users know where they are supposed to go. www.syngress.com Figure 8.8 Output for index.hdml 159_wg_wi_08 10/22/01 5:21 PM Page 356 Wireless Enabling Your Big Bandwidth Site • Chapter 8 357 On the other hand, you could install the redirection script covered above to send your users to the correct location, wherever that may be. Regardless of the technical issues of how you manage your content, it makes sense to take a critical look at your current Web site, and to consider what you want to provide to your wireless users on your wireless Web site. In this sec- tion, we will ask the important questions that surround building a wireless Web site, and discuss the issues surrounding the conversion of existing sites to the wireless Internet. Choosing Mobile Content One of the first steps of building any site is choosing what content to display on the site.This concept is of particular importance when we consider taking our existing Web site to the wireless Internet.The primary questions that arise in adapting a large existing site to the wireless Internet are the following: 1. What content/services might our users want to access while they are mobile? 2. What limitations are there to the existing mobile interfaces that we must consider? Most likely, you will not be able (or will not want) to deliver all of your existing site to mobile users. Critically examine your content and applications to ensure that they are useful to the mobile user. For example, if you run a portal site, you may want to deliver wireless news, weather, and email to your mobile users, as this information is of most value to them. Content such as book reviews, in-depth coverage of intricate issues, and user message boards or forums are best left to the desktop browsers. Remember that mobile users often have a very small window on your site as well as a small-bandwidth connection, and that they will not benefit as greatly from the high-bandwidth components of your site (such as images) or have the ability to scroll through pages and pages of links.Try not to overwhelm the user. Provide a small list of useful actions they can perform on your site, and the wire- less portion of your site will be more successful. Convert or Redevelop? There are several approaches to adapting existing Web content to the wireless Internet, and the optimal approach depends largely on the nature of the existing www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 357 358 Chapter 8 • Wireless Enabling Your Big Bandwidth Site content.There are roughly three options for enabling your site for wireless consumption: 1. You could run a program that automatically traverses the HTML docu- ment area of your site and produces HTML that is valid.You could then use Extensible Style Language Transformations (XSLT) to transform the valid HTML into a WML version according to an XSL ruleset. 2. Alternately, you might write a ‘wrapper’ program that will take a request from a wireless browser and act as a proxy to the Internet.This program, upon receiving a request, would retrieve and format the resulting con- tent for a handheld device. 3. You could rebuild a new wireless version of your site, taking into con- sideration the needs of wireless users and the nature of your content. So how do you decide what to do? The first option is useful if you need to get your site on the wireless Internet as soon as possible, and if your site is made up primarily of text-based content with minimal formatting.The downside of this option is that you cannot assure that your XSL, which operates on a static rule set, will generate a user-friendly version of your site. If your site is already coded in XML, then you can eliminate the first step of this solution and go straight to XSLT. The second solution is a good idea if you are familiar with the existing con- tent and can reliably translate it on-the-fly. It certainly helps if the content is gen- erated by a machine rather than by a human being, and is best suited for low-bandwidth applications, such as entertainment calendars, traffic and weather information, and movie listings.Another upside is that you can extract only the elements that your users need, something that they will certainly appreciate.The downside of this solution is that the actual request will be much slower to the user because they are not only waiting for your server to return content, but they are also waiting for your server to retrieve, convert, and deliver content. Depending on the amount of formatting you must do, and the speed of the HTML-based application, this delay may render your application too slow for the mobile user. We favor the third option because it is most likely to generate a user-friendly wireless site. Many of the existing complaints about the wireless Internet could have been avoided if the early adopters took this strategy rather than the first two options.The problems associated with this option primarily have to do with development time and resources because it is not always economically feasible to www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 358 Wireless Enabling Your Big Bandwidth Site • Chapter 8 359 start from scratch. Nonetheless, it makes the most sense for you to consider the needs and desires of your users, and build your site around those needs. NOTE Google (www.google.com) has developed an intelligent on-the-fly con- verter that will allow WML browsers to view HTML sites. It works for small, basic, text-based sites, but ultimately fails on sites that contain large amounts of graphic-based navigation elements or form-based con- tent. Using this converter should be enough to convince you that any automated conversion system, no matter how intelligent, fails when compared to a wireless site designed with human usability in mind. It is certainly possible to convert HTML (even bad HTML) to WML, but is it desirable to do so? Most notably, existing translation mechanisms do not readily allow for the file-size limitations of mobile devices. Furthermore, not all elements of HTML are supported in WML, and any user interface will certainly be sub- optimal unless re-engineered and re-coded by a human being. It is our recom- mendation that you consider your application from the user’s perspective.Ask yourself: would I want to have my content available on a handheld device? Does it provide some utility to my users? Do the benefits outweigh the costs of devel- opment? If the answer to any or all of those questions is no, then you should skip to the next chapter! Delivering Wireless Data Making data available to mobile users is a key advantage that building a wireless Web site can provide. If we are providing information from a database to users on the WWW, we can make this same data available to users on wireless devices. If your Web site is database-driven and content is separated from presentation, you should be able to generate an effective wireless Web site fairly painlessly.You will certainly have an easier time building a site from a database of content than by building one from many static pages of HTML that have been hacked together over a long period of time by multiple people with varying skill-levels and coding styles. In this section, we will cover the coding of a module that will allow you to adapt your existing data application to the wireless Internet.The theories and www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 359 360 Chapter 8 • Wireless Enabling Your Big Bandwidth Site issues covered here will make sense for any existing Web site that separates con- tent from presentation. Making Your Applications Accessible The first step to delivering wireless data is determining what type of device is requesting the content.We have covered the means of detecting devices and redi- recting users previously in this chapter, but now we will apply this detection scheme as a means of selecting an interface to your application. We will cover the basics of building a library that can be accessed from many applications, and return a result that contains the language to be used, and the type of device in order to apply some logic to the presentation of the retrieved data.The routines, regardless of the programming language used, look something like this pseudocode example: IF device_supports_wml AND device_does_not_support_hdml $language = "wml" ELSE IF device_supports_hdml $language = "hdml" ELSE IF device_supports_html $language = "html" ELSE $language = "unknown" IF device_is_phone $devicetype = "phone" ELSE IF device_is_PDA $devicetype = "PDA" ELSE IF device_is_Web_browser $devicetype = "Web_browser" ELSE $devicetype = "unknown" Once we have authored this routine and provided a means for it to be called from our applications, we can use it to determine how and in what quantities to display our content. For example, if the request for data came from a mobile tele- phone, we can assume that our final deck of results should not contain more than 1397 bytes of data. If the same request came from a PDA, we might enable more www.syngress.com 159_wg_wi_08 10/22/01 5:21 PM Page 360 Wireless Enabling Your Big Bandwidth Site • Chapter 8 361 chunks of the data to be displayed on a given card in the deck (but still minimize the size of the deck because PDA users pay ‘per-byte’.) If the request came from a Web browser, we might be able to send back all of the results in one page, with extensive formatting. The example in Figure 8.9 is provided in Perl, but you should be able to adapt it to the server-side scripting language of your choice. Figure 8.9 Language and Device Detection in Perl #!/usr/bin/perl use strict; my $device = &detect_device; my $language = &detect_language; #detects language according to HTTP_ACCEPT sub detect_language { my $lang; my $accept = $ENV{HTTP_ACCEPT}; if ( $accept =~ m%text/vnd\.wap\.wml% ) { $lang = "wml"; } elsif ( $accept =~ m%text/x-hdml% ) { $lang = "hdml"; } elsif ( $accept =~ m%text/x-html% ) { $lang = "html"; } else { $lang = ""; } return $lang; } #detects device against known UA list (from device.cgi) sub detect_device { my $type; my $uagent = $ENV{HTTP_USER_AGENT}; open(DB,'<ualist.txt'); while(<DB>) { www.syngress.com Continued 159_wg_wi_08 10/22/01 5:21 PM Page 361 . of particular importance when we consider taking our existing Web site to the wireless Internet .The primary questions that arise in adapting a large existing site to the wireless Internet are the. likely to generate a user-friendly wireless site. Many of the existing complaints about the wireless Internet could have been avoided if the early adopters took this strategy rather than the first. variables.There is no flow control in this script, so bear in mind that when you send the content to an actual device you may find that the deck is too large for the device to handle. However, the emulators