W3C home > Mailing lists > Public > uri@w3.org > October 2006

Re: Feedback on draft-gregorio-uritemplate-00

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 6 Oct 2006 20:39:01 -0700
Message-Id: <4966C7A1-A0CB-4195-896E-EECEF44D0FAB@mnot.net>
Cc: uri@w3.org
To: Sam Ruby <rubys@intertwingly.net>


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:10 UTC