W3C home > Mailing lists > Public > uri@w3.org > September 2011

URI templates: commas

From: James Manger <James@Manger.com.au>
Date: Thu, 8 Sep 2011 01:13:14 +1000
Message-Id: <17AF3477-02AE-439A-B8A4-8C44C5CEFA90@Manger.com.au>
To: uri@w3.org
Commas don't have a particularly special role in URIs. They are just 1 of 11 characters in the <reserved> set that are not used as delimiters of the generic URI components.

URI templates (draft-gregorio-uritemplate-06), however, gives commas special meaning. They are the only <reserved> character that can appear when expanding {var}.

I'm not aware of any reason why URI templates should single out commas for this special treatment.
It simultaneously encourages servers to use commas as separators, while also causing problems for some servers that have (quite reasonably) chosen to use commas as separators.

Consider a bank server that accepts payment transactions such as:
  https://example.com/pay/{amount},{to},{from},{comment}

The template processor might be a trusted front-end inserting the "from" variable value based on the authenticated user, but accepting "amount" and "to" values from the user.
This should be able to be safe. But it isn't with the current draft spec.
If the user provides a "to" value that is actually a list [ "me", "victim" ] then the expansion puts the second "to" value where the bank was expecting the "from" account -- and a fraudulent transaction occurs.

Perhaps the bank could switch to using a different delimiter -- but that rather defeats one of the purposes of URI templates of being able to match the server's choice of URI structure.

If the server can provide extra information *outside of the template* about which variables are mandatory, which can or cannot be lists, and which can or cannot be composite values, then it may be able to avoid these problems. But templates should be usable without those limitations.

Almost any URI structure using commas as delimiters can face problems with even the most basic level 1 templates since the server cannot distinguish a comma from expanding a user-provided value from a comma that was a literal expression delimiter in the template.


I suggest that commas not be given special treatment by URI templates.
Expanding {var} should only be able to produce <unreserved> and <pct-encoded> characters -- regardless of the variable values a user provides.

--
James Manger
Received on Wednesday, 7 September 2011 15:13:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 September 2011 15:13:46 GMT