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


The resolver constructs the query for the authority server.

We are talking about allowing the resolver to construct queries in ether path or parameter form. based on the URI element in the authority service.

This only fixes the IIS problem as far as running an authority server not a full proxy resolver.

There are reasons why you want an XDI server to also be an authority server for a community.

Agreed doing this on IIS is bad unfortunately we must accommodate the platform choices of customers.

I am off to SF tomorrow and will pursue other workarounds for Kintera.

=jbradley


On 25-Feb-08, at 3:31 PM, Chasen, Les wrote:

I thought we were talking about a resolver.  When does a server construct a uri?

Forgive me I am on the crackberry so I can't look at the spec.


--------------------------
http://xri.net/=les.chasen


----- Original Message -----
From: Drummond Reed <drummond.reed@cordance.net>
To: 'Gabe Wachob' <gwachob@wachob.com>
Cc: Tan, William; 'John Bradley' <jbradley@mac.com>; Chasen, Les; 'Markus Sabadello' <markus.sabadello@xdi.org>; 'XRI TC' <xri@lists.oasis-open.org>
Sent: Mon Feb 25 17:42:25 2008
Subject: RE: [xri] 9.1.10 Construction of the Next Authority URI

No, the change still makes sense as it enables IIS servers to operate as authority servers (thatís the immediate pain point). Wilís point was about them operating as proxy resolvers.



=Drummond



________________________________

From: gwachob@gmail.com [mailto:gwachob@gmail.com] On Behalf Of Gabe Wachob
Sent: Monday, February 25, 2008 2:39 PM
To: Drummond Reed
Cc: Tan, William; John Bradley; Chasen, Les; Markus Sabadello; XRI TC
Subject: Re: [xri] 9.1.10 Construction of the Next Authority URI



But wait, that's the whole point of this change - if its not going to address all the MS problems anyway, why make the change?

     -Gabe

On Mon, Feb 25, 2008 at 2:25 PM, Drummond Reed <drummond.reed@cordance.net> wrote:

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
> >






--
Gabe Wachob / gwachob@wachob.com \ http://blog.wachob.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]