[OASIS Issue Tracker] Updated: (ODATA-137) Normalize percent-encoded values in URIs before applying ABNF rules

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-137:
-----------------------------

    Environment: [Proposed]

> Normalize percent-encoded values in URIs before applying ABNF rules
> -------------------------------------------------------------------
>
>                 Key: ODATA-137
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-137
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ABNF Construction Rules v1.0
>    Affects Versions: WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: WD01
>
>
> In principle any character in a URI can be percent-encoded, and for unreserved characters the resulting URLs are equivalent. 
> Capturing this equivalence in the ABNF grammar (e.g. accepting "$f%69lt%65r" in addition to "$filter" would make it rather unreadable, so I propose that URLs must be percent-normalized before being run through the grammar, and call that out in a comment at the beginning of the ABNF rules.
> A trickier problem is that not all user agents fully follow the rules in RFC3986. The characters "[", "]", "{", "}", and DQUOTE (") are very important in JSON constructs and not percent-encoded by IE9, Chrome22 and Firefox15 when occurring in the query part, although RFC3986 requires it. Safari5 on the other hand correctly percent-encodes them.
> The conservative choice for a normalization rule here would be that these characters are percent-ENcoded before applying the grammar to produce "legal" URIs. A more readable approach (at least for those test cases passing JSON constructs as parameters) would be to require percent-DEcoding for these special characters in the query part, which is unproblematic as they have no special meaning there.
> If the latter, more readable approach is chosen, it could also be applied to SPACE and HTAB, resolving ODATA-127 on the side of readability.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira