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

Reply via email to