[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Encoding plus (+) sign
So, Wil, are you thinking that we should
only specify percent-encoding of the plus sign? While that’s simple, it
seems a little bit of an odd rule. Since this only applies to XRI proxy servers,
wouldn’t it be easier for proxy server implementers to just make sure
their code leaves the plus sign alone? That way we wouldn’t need any
special encoding of the resolution parameters at all. Thoughts? =Drummond From: Tan, William
[mailto:William.Tan@neustar.biz] No, slashes are fine. I don’t know of any other strange
character other than the plus sign. From: I was offline at the Internet Identity
Workshop last week so I just got to this. This seems like it is hugely important
from an interoperability standpoint. Either we need to require all proxy HXRI
parameters to use percent-encoding for all XRI reserved characters (which is a
big deal) or we need some other solution. How do others feel? Wil, would this also extend to forward
slash characters? =Drummond From: Hi XRItes, The resolution specification does not say that we have to
URL-escape the query parameters before merging it into the proxy URI. However,
our most important MIME type “application/xrds+xml” contains a plus
sign which has special legacy meaning which gets decoded as a space character
on the server side. The parameter values could get corrupted if we don’t
escape it, especially when merging with existing QXRI query string. So, my
argument is to require that the query parameter values be URL-encoded (by that
I mean percent encoding any symbol in the “iquery” production). =wil (http://xri.net/=wil) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]