You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Mark Weaver <ma...@npsl.co.uk> on 2003/02/03 07:13:33 UTC
XalanC: bug in relative URI resolving or my brain?
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
RE: XalanC: bug in relative URI resolving or my brain?
Posted by Mark Weaver <ma...@npsl.co.uk>.
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:david_n_bertoni@us.ibm.com]
> Sent: 03 February 2003 21:11
> To: xalan-dev@xml.apache.org
> 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"
>
> <mark@npsl.co.uk To:
> <xa...@xml.apache.org>
>
> > 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:david_n_bertoni@us.ibm.com]
> > Sent: 03 February 2003 16:52
> > To: xalan-dev@xml.apache.org
> > 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"
> >
> > <mark@npsl.co.uk To:
> > "Xalan-Dev" <xa...@xml.apache.org>
> >
> > > 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
> >
> >
> >
> >
>
>
>
>
RE: XalanC: bug in relative URI resolving or my brain?
Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.
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"
<mark@npsl.co.uk To: <xa...@xml.apache.org>
> 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:david_n_bertoni@us.ibm.com]
> Sent: 03 February 2003 16:52
> To: xalan-dev@xml.apache.org
> 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"
>
> <mark@npsl.co.uk To:
> "Xalan-Dev" <xa...@xml.apache.org>
>
> > 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
>
>
>
>
RE: XalanC: bug in relative URI resolving or my brain?
Posted by Mark Weaver <ma...@npsl.co.uk>.
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:david_n_bertoni@us.ibm.com]
> Sent: 03 February 2003 16:52
> To: xalan-dev@xml.apache.org
> 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"
>
> <mark@npsl.co.uk To:
> "Xalan-Dev" <xa...@xml.apache.org>
>
> > 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
>
>
>
>
Re: XalanC: bug in relative URI resolving or my brain?
Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.
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"
<mark@npsl.co.uk To: "Xalan-Dev" <xa...@xml.apache.org>
> 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