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 <> 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:]
> 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:* [mailto:] *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 <
> > <mailto:>> 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:]
> > *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
> > < <mailto:>> 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: <mailto:>]
> > *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 / <mailto:> \
> > http://blog.wachob.com
> >
--
Gabe Wachob / \ http://blog.wachob.com
