I'll post it in bugzilla and dig into it. I've written exactly this code recently for an HTTP request object, so it might not take me too long.
Mark > -----Original Message----- > From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]] > Sent: 03 February 2003 21:11 > To: [EMAIL PROTECTED] > Subject: RE: XalanC: bug in relative URI resolving or my brain? > > > > > > > Hi Mark, > > OK, I was confusing absolute path with absolute URI. This is a bug then, > but I suspect writing all of the appropriate code to do URI parsing will > not be trivial, so I have no idea how long it will take to fix it. > > Dave > > > > > > "Mark Weaver" > > <[EMAIL PROTECTED] To: > <[EMAIL PROTECTED]> > > > cc: (bcc: > David N Bertoni/Cambridge/IBM) > Subject: RE: > XalanC: bug in relative URI resolving or my brain? > 02/03/2003 11:30 > > AM > > Please respond > > to xalan-dev > > > > > > > OK, I'm not entirely sure what you mean here; as I understand it > I am using > a URI, albeit a relative one. The XSLT spec (remember I'm > getting the same > result with xsl:include since the resolution code is the same) specifies > that relative URIs should be resolved as described in RFC2396. Here are > some sample cases for clarity: > > 1) in stylesheet "http://localhost/test/test.xsl" I have <xsl:include > href="test2.xsl"/> > > Here this is resolved to http://localhost/test2.xsl, which is as expected > (essentially, you strip off up to the previous '/' using the URI of the > currently processed stylesheet to provide context). > > 2) in stylesheet "http://localhost/test/test.xsl" I have <xsl:include > href="http://localhost/includes/include.xsl"/> > > Here this is resolved to http://localhost/includes/include.xsl. > This again > is as expected; since the URI reference starts with a full protocol spec, > we > assume it is absolute and disregard context. > > 3) in stylesheet "http://localhost/test/test.xsl" I have <xsl:include > href="/includes/include.xsl"/> > > This is resolved to http://localhost/test//includes/blah.xsl. > This is not > as expected; this should be resolved as a relative URI that starts with a > /; > which means in simple terms I expect http://localhost/includes/blah.xsl. > > 4) in stylesheet "http://localhost/test/test.xsl" I have <xsl:include > href="../includes/include.xsl"/>. > > This is resolved to http://localhost/test/../includes/blah3.xsl. This is > not as expected, it should be resolved to > http://localhost/includes/blah3.xsl. (./ and ../ should be processed out > of > relative URI fragments). (In this case, the server may help you > out, or it > may not - e.g. if using IIS you can disable parent path support). > > The latter two cases are not according to the URI spec as I read it. > > Thanks, > > Mark > > > -----Original Message----- > > From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]] > > Sent: 03 February 2003 16:52 > > To: [EMAIL PROTECTED] > > Subject: Re: XalanC: bug in relative URI resolving or my brain? > > > > > > > > > > > > > > Hi Mark, > > > > Have you tried using a URI? > > > > file:///somewhere/somethingorother.foo > > > > I'm not sure how the code reacts if parameters are not URIs. > > > > Dave > > > > > > > > > > > > "Mark Weaver" > > > > <[EMAIL PROTECTED] To: > > "Xalan-Dev" <[EMAIL PROTECTED]> > > > > > cc: (bcc: > > David N Bertoni/Cambridge/IBM) > > Subject: XalanC: > > bug in relative URI resolving or my brain? > > 02/02/2003 10:13 > > > > PM > > > > Please respond > > > > to xalan-dev > > > > > > > > > > > > > > Xalan-C 1.4 on w2k. > > > > At some point, I'm calling > > XPathExecutionContext::parseXML("/somewhere/somethingorother.foo", > > "http://localhost/blah/blah/blah.foo"). The URI is then resolved to > > http://localhost/blah/blah/somewhere/somethingorother.foo. This seems > > wrong > > to me - RFC2396 has "5) If the path component begins with a slash > > character > > ("/"), then the reference is an absolute-path and we skip to step 7." in > > "5.2. Resolving Relative References to Absolute Form". The same happens > > for > > other such includes (e.g. in stylesheets). > > > > Sorry if this has come up before. I've had a quick dig through > bugzilla, > > and can't find anything. Either way, let me know and i'll fix/tell my > > users > > to go away as appropriate... > > > > Thanks, > > > > Mark > > > > > > > > > > > >
