OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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


No problem from an OpenXRI Server point of view.

The OpenXRI Server uses a thing called "URIMapper" to extract a request (a "root namespace" and a "query") from a URI.

Right now there's a "FolderURIMapper" which expects requests like this:
http://www.myserver.com/resolve/ns/@mycompany/*myname
In this case the "root namespace" is @mycompany, and the query is *myname.

Then there's a "SingleNamespaceURIMapper" which expects requests like this:
http://www.myserver.com/resolve/*myname
In this case the "root namespace" is hard-coded in the configuration file (e.g. @mycompany), and the query is *myname.

So with the change there could also be a "QueryURIMapper" for requests like this:
http://www.myserver.com/resolve?namespace=@mycompany&query=*myname
Again, the "root namespace" would be @mycompany, and the query would be *myname.

Markus

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]
Sent: Sunday, February 24, 2008 1:04 PM
To: XRI TC
Cc: Gabe Wachob; Drummond Reed
Subject: [xri] 9.1.10 Construction of the Next Authority URI

 

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]