- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 6 Oct 2006 20:39:01 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: uri@w3.org
On 2006/10/06, at 7:52 PM, Sam Ruby wrote:
>
> First, I will note that this argument is based solely on the
> difference in the templates -- your example does different things
> with the SAME inputs. What you seem to be arguing instead is that
> each part of a URL, e.g. the path info, the query, etc., has a
> different set of reserved characters that must be quoted.
Yes. According to RFC3986, given a = "foo/bar", the correct encoding is:
http://www.example.com/{a} --> http://www.example.com/foo%2f/bar
http://www.example.com/foo?path={a} --> http://www.example.com/
foo?path=foo/bar
The allowed characters are different in different path components.
Added to this, applications on top of URIs (e.g., HTML's form
encoding) may have further restrictions (e.g., you might want to
escape an ampersand).
> Second, if the specification follows the recommendation that you
> give in this example, you actually surprise many. I would suspect
> that most would see that template and assume that they can pass in
> a path, and find out that if the results are served statically by a
> server such as Apache HTTPD, paths won't quite work as expected.
As discussed, values will either need to be escaped, or not, and
there are use cases for both. We need to be clear about what's
happening in any case.
Actually, by putting what's effectively an encoding type in the input
data structure, we *can* have both;
{
'a': ('foo/bar', PATH_SEGMENT),
'b': ('foo/bar', NULL),
'c': ('foo/bar', QUERY_STRING),
}
http://example.com/{a}/{b}?{c} --> http://example.com/foo%2f/foo/
bar?foo/bar
--
Mark Nottingham http://www.mnot.net/
Received on Saturday, 7 October 2006 03:39:09 UTC