1.1 --- a/docs/paths.html Sat Sep 08 16:01:41 2007 +0000
1.2 +++ b/docs/paths.html Sat Sep 08 16:02:18 2007 +0000
1.3 @@ -1,7 +1,7 @@
1.4 +<?xml version="1.0" encoding="iso-8859-1"?>
1.5 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.6 <html xmlns="http://www.w3.org/1999/xhtml"><head>
1.7 -
1.8 - <title>URLs and Paths</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.9 + <title>URLs and Paths</title>
1.10 <link href="styles.css" rel="stylesheet" type="text/css" /></head>
1.11 <body>
1.12 <h1>URLs and Paths</h1>
1.13 @@ -31,7 +31,7 @@
1.14 <p>In an application the full URL, containing the address of the
1.15 machine on which it is running, is not always interesting. In the
1.16 WebStack API (and in other Web programming frameworks), we also talk
1.17 -about "paths" - a path is just the part of the
1.18 +about "paths" - a path is just the part of the
1.19 URL which refers to the resource or service, ignoring the actual
1.20 Internet
1.21 address, and so the above example would have a path which looks like
1.22 @@ -53,18 +53,18 @@
1.23 <dd>This gets the entire path of a resource including parameter
1.24 information (as described in <a href="parameters.html">"Request
1.25 Parameters and Uploads"</a>).<br />
1.26 -An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd>
1.27 +An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd>
1.28 <dt><code>get_path_without_query</code></dt>
1.29 <dd>This gets the entire path of a resource but without any parameter
1.30 information.<br />
1.31
1.32 -An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd><dt><code>get_path_without_info</code></dt><dd>This gets the entire path of a resource but without any parameter
1.33 +An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd><dt><code>get_path_without_info</code></dt><dd>This gets the entire path of a resource but without any parameter
1.34 information or any special "path info" (as described in <a href="path-info.html">"Paths To and Within Applications"</a>).
1.35 The result is more or less equivalent to the location where an
1.36 application has been "published" - ie. the location of an application
1.37 in a server environment.<br />
1.38
1.39 -An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd>
1.40 +An optional <code>encoding</code> parameter may be used to assist the process of converting the path to a Unicode object - see below.</dd>
1.41 </dl>
1.42 </div>
1.43 <p>To obtain the above path using the WebStack API, we can write the following code:</p>
1.44 @@ -95,21 +95,21 @@
1.45 Uploads"</a>.</p>
1.46 <div class="WebStack">
1.47 <h3>WebStack API - Getting Query Strings</h3>
1.48 -<p>WebStack provides a method to get only the query string from the URL:</p>
1.49 +<p>WebStack provides a method to get only the query string from the URL:</p>
1.50 <dl><dt><code>get_query_string</code></dt><dd>This method returns the part of the URL which contains parameter
1.51 information. Such information will be "URL encoded", meaning that
1.52 -certain characters will have the form <code>%xx</code> where <code>xx</code>
1.53 +certain characters will have the form <code>%xx</code> where <code>xx</code>
1.54 is a two digit hexadecimal number referring to the byte value of the
1.55 unencoded character - see below for discussion of this. </dd></dl>
1.56 </div>
1.57 -<p>Note that unlike the path access methods, <code>get_query_string</code>
1.58 +<p>Note that unlike the path access methods, <code>get_query_string</code>
1.59 does not accept an encoding as a parameter. Moreover, when retrieving a
1.60 path including a query string, the encoding is not used to interpret
1.61 "URL encoded" character values in the query string itself. Consider
1.62 this example URL:</p>
1.63 <pre>http://www.boddie.org.uk/application-%E6?var%F8=value%E5</pre>
1.64 <p>Upon requesting the path and the query string, certain differences should be noticeable:</p>
1.65 -<pre>trans.get_path("iso-8859-1") # returns /application-æ?var%F8=value%E5<br />trans.get_path_without_query("iso-8859-1") # returns /application-æ<br />trans.get_query_string() # returns var%F8=value%E5</pre>
1.66 +<pre>trans.get_path("iso-8859-1") # returns /application-æ?var%F8=value%E5<br />trans.get_path_without_query("iso-8859-1") # returns /application-æ<br />trans.get_query_string() # returns var%F8=value%E5</pre>
1.67 <p>One reason for this seemingly arbitrary distinction in treatment is
1.68 the way certain servers present path information to WebStack - often
1.69 the "URL encoded" information has been replaced by raw character values
1.70 @@ -121,7 +121,7 @@
1.71 <pre>http://www.boddie.org.uk/application?a=%26b</pre>
1.72 <p>If we were to just decode the query string and then extract the
1.73 parameters/fields, the result would be two empty parameters with the
1.74 -names <code>a</code> and <code>b</code>, as opposed to the correct interpretation of the query string as describing a single parameter <code>a</code> with the value <code>&b</code>.</p>
1.75 +names <code>a</code> and <code>b</code>, as opposed to the correct interpretation of the query string as describing a single parameter <code>a</code> with the value <code>&b</code>.</p>
1.76 <h3>Final Note</h3>
1.77 <p>Regardless of all this, all inspection of path parameters should be done using the appropriate methods (see <a href="parameters.html">"Request Parameters and
1.78 Uploads"</a>),
1.79 @@ -134,4 +134,4 @@
1.80 <li><a href="path-info-support.html">Path Info Support in Server
1.81 Environments</a></li>
1.82 </ul>
1.83 -</body></html>
1.84 \ No newline at end of file
1.85 +</body></html>