[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, Wil, that IIS is still going to have serious challenges with XRI if they don't allow stars or colons in the path. But I guess that's a conversation we can start to have with Microsoft after the XRI 2.0 vote. In any case it won't be something we can solve overnight. =Drummond > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Monday, February 25, 2008 2:17 PM > To: Drummond Reed > Cc: 'Gabe Wachob'; 'John Bradley'; 'Chasen, Les'; 'Markus Sabadello'; 'XRI > TC' > Subject: Re: [xri] 9.1.10 Construction of the Next Authority URI > > Doesn't it mean that IIS still won't be able to handle HXRI? > God forbids if we ever run IIS for the proxy, this would not work: > > http://xri.net/@foo*bar > > > John, can you also confirm that IIS will be able to take a valid XRI > authority in URI-normal form in the query without any escaping? > > =wil > > Drummond Reed wrote: > > > > 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 > > *Sent:* Monday, February 25, 2008 1:32 PM > > *To:* John Bradley > > *Cc:* Chasen, Les; Markus Sabadello; XRI TC > > *Subject:* Re: [xri] 9.1.10 Construction of the Next Authority URI > > > > 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). > > > > In any case, +1 to this proposal. We need to post a "backwards > > compatibility" note because some implementations (e.g. some old code I > > wrote) are explicitly extracting the path and query parts of an > > authority URL and adding the authority subsegment to the path and > > reconstructing the URL.... that would not be the algorithm now.. > > > > -Gabe > > > > On Mon, Feb 25, 2008 at 8:33 AM, John Bradley <jbradley@mac.com > > <mailto: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: > > > > http://www.computersmarts.us/net-framework/561-kb932552-fix-error- > message-when-you-visit-asp-net-2-0-based-web-page-httpexception- > 0x80004005-handlertest-webform1-aspx-b-not-valid-virtual-path.html > > > > It is possible it is an asp.net <http://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. > > > > contact: =les <http://xri.net/=les> > > > > voice: =les/(+phone) <http://xri.net/=les/%28+phone%29> > > > > chat: =les/skype/chat <http://xri.net/=les/skype/chat> > > > > pibb me =les/+pibb <http://xri.net/=les/+pibb> > > > > ------------------------------------------------------------------------ > > > > *From:* John Bradley [mailto:jbradley@mac.com] > > *Sent:* Monday, February 25, 2008 10:33 AM > > *To:* Markus Sabadello > > *Cc:* XRI TC > > *Subject:* Re: [xri] 9.1.10 Construction of the Next Authority URI > > > > 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. > > > > 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 > > <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 <mailto: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 <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 > > > > > > > > > > -- > > Gabe Wachob / gwachob@wachob.com <mailto:gwachob@wachob.com> \ > > http://blog.wachob.com > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]