| paulb@335 | 1 | <?xml version="1.0" encoding="iso-8859-1"?> |
| paulb@335 | 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
| paulb@335 | 3 | "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| paulb@335 | 4 | <html xmlns="http://www.w3.org/1999/xhtml"> |
| paulb@335 | 5 | <head> |
| paulb@335 | 6 | <title>Request Header Parameters</title> |
| paulb@335 | 7 | <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
| paulb@335 | 8 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
| paulb@335 | 9 | </head> |
| paulb@335 | 10 | |
| paulb@335 | 11 | <body> |
| paulb@335 | 12 | <h2>Request Header Parameters</h2> |
| paulb@335 | 13 | |
| paulb@335 | 14 | <p>Header parameters are typically specified in the URL like this:</p> |
| paulb@335 | 15 | <pre>http://www.boddie.org.uk/application?param1=value1&param2=value2</pre> |
| paulb@335 | 16 | |
| paulb@335 | 17 | <p>Following the rules set out in <a href="paths.html">"URLs and Paths"</a>, |
| paulb@335 | 18 | we can say that the "query string" employed is this:</p> |
| paulb@335 | 19 | <pre>param1=value1&param2=value2</pre> |
| paulb@335 | 20 | |
| paulb@335 | 21 | <p>From this string, we may extract the parameters and state that they are |
| paulb@335 | 22 | the following:</p> |
| paulb@335 | 23 | <ul> |
| paulb@335 | 24 | <li><code>param1</code> with the value <code>value1</code></li> |
| paulb@335 | 25 | <li><code>param2</code> with the value <code>value2</code></li> |
| paulb@335 | 26 | </ul> |
| paulb@335 | 27 | |
| paulb@335 | 28 | <p>Parameters encoded in this way can be written into hyperlinks and may be |
| paulb@335 | 29 | used to remember things as users navigate their way around an application. |
| paulb@335 | 30 | Alternatively, a Web form (in HTML) written to use the <code>GET</code> <a |
| paulb@335 | 31 | href="methods.html">request method</a> may be used to achieve the same |
| paulb@335 | 32 | effect:</p> |
| paulb@335 | 33 | <pre><form method="GET" action="http://www.boddie.org.uk/application"> |
| paulb@335 | 34 | <input name="param1" type="text" /> |
| paulb@335 | 35 | <input name="param2" type="text" /> |
| paulb@335 | 36 | </form></pre> |
| paulb@335 | 37 | |
| paulb@335 | 38 | <div class="WebStack"> |
| paulb@335 | 39 | <h3>WebStack API - Accessing Header Parameters</h3> |
| paulb@335 | 40 | |
| paulb@335 | 41 | <p>Transaction objects provide the following methods to access parameters |
| paulb@335 | 42 | specified in request headers. The terminology used in the API describes such |
| paulb@335 | 43 | parameters as path fields, since such parameters are often provided by form |
| paulb@335 | 44 | fields.</p> |
| paulb@335 | 45 | <dl> |
| paulb@335 | 46 | <dt><code>get_fields_from_path</code></dt> |
| paulb@335 | 47 | <dd>This returns the request parameters (fields) from the request headers |
| paulb@335 | 48 | (as defined in the path or URL). The fields are provided in a |
| paulb@335 | 49 | dictionary mapping field names to lists of values</dd> |
| paulb@335 | 50 | <dt><code>get_query_string</code></dt> |
| paulb@335 | 51 | <dd>This returns the query string - ie. the part of the path or URL which |
| paulb@335 | 52 | contains the parameters. Typically, it is easier to use the above |
| paulb@335 | 53 | method instead.</dd> |
| paulb@335 | 54 | </dl> |
| paulb@335 | 55 | </div> |
| paulb@335 | 56 | |
| paulb@335 | 57 | <p>There are some limitations with header parameters:</p> |
| paulb@335 | 58 | <ul> |
| paulb@335 | 59 | <li>Since URLs are used to carry such parameters, any such parameter which |
| paulb@335 | 60 | should remain hidden will appear in the URL and probably be shown in |
| paulb@335 | 61 | browsers and other user interfaces.</li> |
| paulb@335 | 62 | <li>There isn't widespread agreement about how non-ASCII characters should |
| paulb@335 | 63 | be encoded in URLs. Therefore, care must be taken to encode and decode |
| paulb@335 | 64 | values transferred in request headers.</li> |
| paulb@335 | 65 | </ul> |
| paulb@335 | 66 | </body> |
| paulb@335 | 67 | </html> |
