[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] 9.1.10 Construction of the Next Authority URI
Agreed that we need a backwards
compatability note along with the revision. I will add both to Committee Draft 02
Revision 02 this afternoon and post it by this evening. =Drummond From:
gwachob@gmail.com [mailto:gwachob@gmail.com] On
Behalf Of Gabe Wachob This rule came out of a
discussion we had with Dave McAlpin sometime in the distant past. They were
using ? params on their Authority URIs (to indicate namespace) and wanted to
have the next authority subsegment added to the path, not the query (having a double
query was deemed too odd -- not sure when the query string would be added to -
but in the past there may have been a reason). On Mon, Feb 25, 2008 at 8:33 AM, John Bradley <jbradley@mac.com> wrote: They are vague on what the security reason is, colon : and asterisk *
are both prohibited. I am going to gig into it more today as we need a fix for Kintera's
community authority server. The following is a description of the problem. I normally wouldn't recommend accommodating Microsoft's
broken code. However I don't see a downside in relaxing the rule on URI construction
and make it more in line with the normal append behavior. There may be other platforms that would prefer the root and next
element as parameters rather than the path for other reasons as well. From an authority server point of view it needs to turn them into
variables anyway unless its doing something very simplistic and
handing back XRDs from static files. Lacking any reason for the rule I don't see any reason not to relax it
now, so that its the authority servers option on how it wants its URI
constructed. This post describes the IIS issue: It is possible it is an asp.net
issue rather than an IIS one. Not being a windows person at all I am
starting from scratch sorting this out. =jbradley On 25-Feb-08, at 7:58 AM, Chasen, Les wrote:
Out of curiosity, does IIS specify the
security reasons? If so what say thee. From: John Bradley [mailto:jbradley@mac.com] Markus, Yes you could make the change to accept
the query as parameters rather than in the path, if you want. The purpose however is to allow authority
servers on platforms that have a restriction on * in the path. The only required change to openXRI would
be in the next authority URI construction. OpenXRI would append to the end of the URI
rather than the end of the path. =jbradley On 25-Feb-08, at 5:09 AM, Markus Sabadello
wrote: No problem from an OpenXRI Server point of
view. On Mon, Feb 25, 2008 at 1:32 AM, Drummond
Reed <drummond.reed@cordance.net>
wrote: John, I spent some time today looking at this issue. My
recollection was that appending directly to the path was originally specified
(in XRI resolution 1.0) because the XRI Resolution 1.0 editors conceptualized
XRI resolution as a series of HTTP(S) URI substitutions – which it still is. However I can't see any reason why the Next Authority String
(section 9.1.10) can't just be appended to the fully constructed Next Authority
Resolution Service Endpoint URI. That would increase the flexibility of XRI
authorities to control their incoming resolution requests, and to use a query
parameter if that makes life easier (as it sounds like it will with this IIS
bug). Gabe, can you see any reason not to do this? Les, Wil, Steve?
Or anyone else? We need to resolve this quickly as we need to put CD03 to a
vote this week in order to make our planned May vote. =Drummond From: John Bradley [mailto:jbradley@mac.com] Steve and I have discovered an issue with using IIS as
an XRI authority server. It turns out that Microsoft will not let you have a * in the path
for "security reasons". There is a hotfix that disables URL validation, but is
not recommended. In our wisdom we thought that we could construct URI like: http://76.14.26.160/xdiservice-webservice/Default.aspx?localName= to get around the problem.
This did not work because we are not following the normal append rules for URI construction.
The problem is of corse that in 9.1.10 we are specific about only appending to the path, so we get.
http://76.14.26.160/xdiservice-webservice/Default.aspx/*aaa.3/?localName= Drummond and I discussed this and decided that a change to line 1460 may be appropriate. Change:
The final step is to append the Next Authority String to the path component of the Next Authority
To:
The final step is to append the Next Authority String to the end of the Next Authority
This would allow authority servers to accept the next subsegment as a path or parameter as they like.
We believe that this is fully backwards compatible with the current authority servers.
I understand that the time to consider this is limited, and apologize for discovering this at the last minute.
I don't see a good reason for the spec to restrict people to only use the path.
Regards =jbradley
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]