[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] ED07 Issue #1: Encoding of + in query parameters
The HXRI below should be: http://xri.example.com/=example/path?_xrd_t=http://example.com/test%20type/?a=1%26b=2%26x=a+b Thanks to John for the correction! =wil Tan, William wrote: > We should be able to split the parameters in an HXRI into pieces, > extract the resolution input parameters for processing, and leave the > rest in tact. Since the W3C recommends ';' as a delimiter in addition > to '&', we have to escape it. I think that's fine. > > Other than the requirement to be able to split the query parameters, > the resolver MUST NOT interpret non-resolution query parameters, i.e. > they should be left as-is. > > For resolution parameters, I think we can say that other than '&' and > ';', everything else should not be unescaped in any way while > interpreting the HXRI. An important consequence of this is that any % > encoding will stay. > > For example, in order to place > http://example.com/test%20type/?a=1&b=2&x=a+b > into the _xrd_t parameter of the following HXRI: > http://xri.example.com/=example/path > > It becomes: > http://xri.example.com/=example/path?_xrd_t=http://example.com/test%20type/?a=1%3Bb=1%3Bx=a+b > > > Implementations should be able to reverse this to the original value; > i.e. %20 should not become a space character (which makes the URI > illegal), nor should it be misinterpreted as '+'. And, of course %3B > gets turned into '+'. > This usually means re-implementing the URL parser because in many CGI > environments/implementation, the parameters are escaped in a > "standard" manner, which conflicts with the way we have specified. > > So, that's a long-winded form of saying that '+' should not be escaped > when it appears in the resolution input parameters. > > Thoughts? > > =wil > > > Drummond Reed wrote: >> >> In his feedback on ED06, Gabe suggested we add an example of HXRI >> query parameter encoding rules. To do so I broke the encoding rules >> into a separate subsection in ED07. That entire subsection is >> included below for reference. >> >> The issue that came up doing this, however, is that in rule #3 below, >> while we give unambiguous instructions that the character + and the >> percent-encoded sequence %2B MUST be interpreted as the same >> character, we don’t currently say anything about whether the + >> character SHOULD or SHOULD NOT be encoded as %2B. >> >> And thus it is not clear what to do with the + characters that appear >> in the example. >> >> So the open issue is: what additional instructions about + character >> encoding, if any, should we put in rule #3 below? >> >> =Drummond >> >> >> */HXRI Query Parameter Encoding Rules/* >> >> To conform with the requirements of HTTP(S) URI processors, the >> following rules MUST be applied to encode HXRI query parameters prior >> to input and decode them prior to output. Decoding MUST be performed >> prior any comparison operation defined in this specification. >> >> 1. Any occurrences of the character & within an input parameter >> (specifically the Service Type value) MUST be percent encoded using >> the sequence %26. >> >> 2. If an HXRI query parameter includes one of the media type >> parameters defined in Table 6, it MUST be delimited from the HXRI >> query parameter with a semicolon, and this semicolon MUST be >> percent-encoded using the sequence %3B. This prevents >> misinterpretation of the semicolon character by a proxy resolver. >> >> 3. In an HXRI query parameter, the character + and the >> percent-encoded sequence %2B MUST be interpreted as the same >> character, therefore spaces in an HXRI query parameter MUST NOT be >> encoded as + signs. >> >> 4. Any XRIs or IRIs used as values of HXRI query parameters MUST be >> in URI-normal form as defined in *[XRISyntax]*. >> >> Following is an example HXRI before application of these encoding >> rules, with the characters requiring encoding highlighted in *red*. >> >> https://xri.example.com/=example*name/path?query&_xrd_r=application/ >> xrds+xml*;*https=true*;*sep=true*;*refs=true&_xrd_t=http://example.org/ >> test?a=1*&*b=2*&*string=hello%20plan*è*te&_xrd_m=application/atom+xml >> >> Here is the HXRI after application of the encoding rules, with the >> encoding highlighted in *red*. >> >> https://xri.example.com/=example*name/path?query&_xrd_r=application/ >> xrds+xml*%3B*https=true*%3B*sep=true*%3B*refs=true&_xrd_t=http://example.org/test?a=1*%26*b=2*%26*string=hello%20plan*%E9*te&_xrd_m=application/atom+xml >> >> >> ------------------------------------------------------------------------ > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]