1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/parameters-headers.html Sun Apr 10 21:11:25 2005 +0000
1.3 @@ -0,0 +1,67 @@
1.4 +<?xml version="1.0" encoding="iso-8859-1"?>
1.5 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
1.6 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.7 +<html xmlns="http://www.w3.org/1999/xhtml">
1.8 +<head>
1.9 + <title>Request Header Parameters</title>
1.10 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.11 + <link href="styles.css" rel="stylesheet" type="text/css" />
1.12 +</head>
1.13 +
1.14 +<body>
1.15 +<h2>Request Header Parameters</h2>
1.16 +
1.17 +<p>Header parameters are typically specified in the URL like this:</p>
1.18 +<pre>http://www.boddie.org.uk/application?param1=value1&param2=value2</pre>
1.19 +
1.20 +<p>Following the rules set out in <a href="paths.html">"URLs and Paths"</a>,
1.21 +we can say that the "query string" employed is this:</p>
1.22 +<pre>param1=value1&param2=value2</pre>
1.23 +
1.24 +<p>From this string, we may extract the parameters and state that they are
1.25 +the following:</p>
1.26 +<ul>
1.27 + <li><code>param1</code> with the value <code>value1</code></li>
1.28 + <li><code>param2</code> with the value <code>value2</code></li>
1.29 +</ul>
1.30 +
1.31 +<p>Parameters encoded in this way can be written into hyperlinks and may be
1.32 +used to remember things as users navigate their way around an application.
1.33 +Alternatively, a Web form (in HTML) written to use the <code>GET</code> <a
1.34 +href="methods.html">request method</a> may be used to achieve the same
1.35 +effect:</p>
1.36 +<pre><form method="GET" action="http://www.boddie.org.uk/application">
1.37 + <input name="param1" type="text" />
1.38 + <input name="param2" type="text" />
1.39 +</form></pre>
1.40 +
1.41 +<div class="WebStack">
1.42 +<h3>WebStack API - Accessing Header Parameters</h3>
1.43 +
1.44 +<p>Transaction objects provide the following methods to access parameters
1.45 +specified in request headers. The terminology used in the API describes such
1.46 +parameters as path fields, since such parameters are often provided by form
1.47 +fields.</p>
1.48 +<dl>
1.49 + <dt><code>get_fields_from_path</code></dt>
1.50 + <dd>This returns the request parameters (fields) from the request headers
1.51 + (as defined in the path or URL). The fields are provided in a
1.52 + dictionary mapping field names to lists of values</dd>
1.53 + <dt><code>get_query_string</code></dt>
1.54 + <dd>This returns the query string - ie. the part of the path or URL which
1.55 + contains the parameters. Typically, it is easier to use the above
1.56 + method instead.</dd>
1.57 +</dl>
1.58 +</div>
1.59 +
1.60 +<p>There are some limitations with header parameters:</p>
1.61 +<ul>
1.62 + <li>Since URLs are used to carry such parameters, any such parameter which
1.63 + should remain hidden will appear in the URL and probably be shown in
1.64 + browsers and other user interfaces.</li>
1.65 + <li>There isn't widespread agreement about how non-ASCII characters should
1.66 + be encoded in URLs. Therefore, care must be taken to encode and decode
1.67 + values transferred in request headers.</li>
1.68 +</ul>
1.69 +</body>
1.70 +</html>