All tasks can change variables in the browser's context using the <setvar> element, as described in Chapter 2, WML Variables and Contexts. The new variable bindings don't affect the task itself but rather take effect when the task completes. For example, suppose the variable page contains the value login. The task:

<go href="$(page).wml">
<setvar name="page" value="bad"/>
</go>

goes to login.wml, not bad.wml, because the browser substitutes the original value of the page variable into the href attribute before it assigns the new value to the variable.

The <go> Task

As the name suggests, the <go> task represents the action of going to a new card. (It is also used for a special purpose with WMLScript, but you must wait until later in the book to find out about that.)

The <go> task takes several different attributes to customize exactly how to find the new card. Usually, only href and sometimes method attributes are used.

Attributes of the <go> task

href (required variable url)

Gives the URL of the new card. Relative URLs are resolved relative to the current card (the one containing this <go>).

method (optional string; default get)

Specifies the method that should be used to fetch the deck. This must be one of the values get or post, corresponding to the GET and POST methods of HTTP.

sendreferer (optional boolean; default false)

If set to true, the browser sends the URL of the current deck along with the request. This URL is sent as a relative URL if possible. The purpose of this is to allow servers to perform simple access control on decks, based on which decks are linking to them. For example, using HTTP, this attribute is sent in the HTTP Referer header.

accept-charset (optional string; default unknown)

Specifies a comma- or space-separated list of character sets that can encode data sent to the server in a POST request. The browser selects one to use when sending the data. If this is set to the value unknown (the default), the browser uses the same character set that sent this document to the browser. (Note that this attribute is an advanced feature and is rarely used.)

The method attribute: GET and POST

One of the more interesting options available on the <go> task is the method attribute. This specifies whether the request should be sent as a GET or as a POST. This option is used only when sending information for processing on the server: it's not used when simply fetching static pages of WML.

If you know HTML, you may recognize similarities with the METHOD="GET" and METHOD="POST" attributes that can be put on an HTML <FORM> element. WML puts this attribute on the <go> task instead, but it has essentially the same effect.

GET is the normal method used in HTTP. All the information sent to the server is encoded in the URL, and the server uses this URL to find some resource and return it to the browser.

The main advantage of GET is that it's simple. Any information is simply added to the query part of the URL (more on the parts of URLs in Appendix A, Absolute and Relative URLs). You can even put the query information directly into the URL using variables.

The main disadvantage of GET is that it can be used only for a limited amount of data. Web servers and other programs that process URLs impose certain limits on the length of a URL they are prepared to handle. This limits the size of the request that can be sent using GET.

A subtler problem with GET relates to the fact that all the information you send becomes part of the URL. Many browsers display the URL of the current deck somewhere on the screen (even if only briefly), and most web servers store the entire URL in their log files, complete with the extra data from the GET. If this information is of a sensitive nature (a password, for example), it's displayed on the screen and then saved for posterity in the web server's logs!

The POST method avoids these two problems, by sending the data separately from the URL in the request. As a result, the URL stays small, and the browser display and web server logs don't contain any of the data.

The <postfield> element

In modern versions of WML, information to be posted with the POST method is specified in <postfield> elements within the <go> element. This information takes the form of a list of name/value pairs. Each <postfield> element specifies a single pair. The element is very simple, having only two attributes:

name (required variable string)

The name of this field

value (required variable string)

The value of this field

WML allows <postfield> elements to be used even with the GET method. In this case, the fields are added to the end of the query part of the URL. For example, consider the task:

Shorthand forms of <go> tasks

One form of task is more common than any other: a <go> task that has no attributes other than href and doesn't contain any <postfield> or <setvar> elements. Because this form is so common, WML provides a shorthand form you can use in many situations.

Instead of including the task as a complete <go> element, the value that would be put into the href attribute of the <go> element is simply included as an attribute on a different element. For example, it is possible to bind a task to an option in a selection list, so that the task is performed when the option is selected. The normal way of doing this looks like this:

This is allowed for the onenterforward, onenterbackward, and ontimer attributes of the <card> element; the onpick attribute of the <option> element; and the href attribute of the <a> element. These elements are all described later in this book: don't worry about them for now.