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
>
