Single Quote in URI Templates is disallowed but reserved in URLs. about uritemplate-test HOT 15 CLOSED

My guess is that the right thing to do is an errata on URI Templates that adds single quote back into the allowed literal characters and warns about such use being not so interoperable when used within document content.

from uritemplate-test.

I searched through the archives and found

http://www.w3.org/mid/[email protected]

which indicates this bug was reported and ack'd, but instead of fixing it properly I ended up removing the example instead. Very strange brain fart.

from uritemplate-test.

No more work. The AD will approve the errata and it will be linked from the RFC page as errata available. Someone might revise the RFC in the future, if there is a need, and they will be asked to incorporate any valid errata.

from uritemplate-test.

Errata 6937 verified.

from uritemplate-test.

@royfielding do you remember if there was a reason for this?

from uritemplate-test.

I don't remember why it was originally allowed for a reserved purpose. But it means a single quote is not supposed to be present in a URI outside of its reserved purpose, and no such purpose was defined for any scheme that I recall. Hence, it is supposed to be pct-encoded all the time, so it must be pct-encoded to appear as a literal within a template.

Using single quotes in a URI is not interoperable these days because the parsing algorithms changed in HTML to allow mismatched quoting of anchors. I think we concluded that we were more likely to eventually update RFC3986 (to exclude the single quote) than to find an implementation that could effectively use single quote in a URI.

from uritemplate-test.

Hm. 2.2 says

[C]haracters in the reserved
set are protected from normalization and are therefore safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI.

Note 'producer-specific algorithms' -- i.e., reserved characters are available for use not only to the URI scheme, but also the URL's producer for their own use.

This is reinforced a bit further down:

URI producing applications should percent-encode data octets that
correspond to characters in the reserved set unless these characters
are specifically allowed by the URI scheme to represent data in that
component. If a reserved character is found in a URI component and
no delimiting role is known for that character, then it must be
interpreted as representing the data octet corresponding to that
character's encoding in US-ASCII.

While in isolation the first sentence could be read to isolate these powers to the URI scheme, the second sentence has the effect of allowing the application to use reserved characters as well.

That's reinforced by the nature of the other sub-delims -- e.g., + occurs in many URIs, is not percent-encoded, and serves as a delimiter that isn't specified by the URI scheme. Same for & and =.

If that's the case, ' is being singled out here -- none of the other characters in reserved is prohibited in literals.

I don't think we can say that ' isn't used in any URLs today. HTML is just one specification that uses URLs; there are others.

from uritemplate-test.

Thanks for discussion here!
Just chiming for the examples of usage of ' in URLs, OData functions use them for example for string input parameters.
This example on Microsoft Graph might help to clarify my point:

GET https://graph.microsoft.com/v1.0/reports/getTeamsUserActivityCounts(period='{period_value}')

Where period_value is a string representing an ISO duration (e.g. 30D)

I hope this helps the discussion :) (I'm new to any RFC discussion)

from uritemplate-test.

@mnot @royfielding gentle reminder on this one so we can either patch the Go library or encode the single quote. (we really want to be doing the right thing in this case)

from uritemplate-test.

I've just submitted one ! (this is my first time doing this sort of work, I hope I didn't mess it up) https://www.rfc-editor.org/errata/eid6934

I'll also go ahead and submit a PR to include that case in the unit test. Thanks everyone for the help!

from uritemplate-test.

I made an error in the It should say section 🤦‍♂️

This is what I meant.

   literals      =  %x21 / %x23-24 / %x26-3B / %x3D / %x3F-5B
                   /  %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate
                   /  pct-encoded
                        ; any Unicode character except: CTL, SP,
                        ;  DQUOTE, "%" (aside from pct-encoded),
                        ;  "<", ">", "\", "^", "`", "{", "|", "}"

From what I've been reading online, I can't withdraw an errata or edit it after having submitted it.
But you as the spec authors can edit my errata before approving it.
If you'd rather decline this one and have me submit a new one instead, just let me know, I'll be happy to do it.

from uritemplate-test.

also submitted #53 for the updated test cases

from uritemplate-test.

Update, after exchanging with the authors, I was instructed to create another errata, the first one will be deleted.
https://www.rfc-editor.org/errata/eid6937

from uritemplate-test.

Thanks for taking the time to search for this.
Besides the errata I submitted, is there more work to be done?
For the errata, since it was approved on the email thread, what are the next steps so it "goes live"?

from uritemplate-test.

Thanks for the update! @royfielding do you think we can merge the pull requests for the additional unit tests now?

from uritemplate-test.