Re: Webdav and url-encoding



On Fri, 2004-02-13 at 10:19, Walter Landry wrote:
> Alexander Larsson <alexl redhat com> wrote:
> > On Sat, 2004-02-07 at 00:15, Walter Landry wrote:
[...]
> > > 
> > > If I just use that as the url, it fails, giving me errors like
> > > 
> > >   PROPFIND:2: parser warning : xmlns:D: 'DAV:' is not a valid URI
> > >   <D:multistatus xmlns:D="DAV:">
> > >                                ^
> > >   PROPFIND:3: parser warning : xmlns:lp0: 'DAV:' is not a valid URI
> > >   <D:response xmlns:lp0="DAV:" xmlns:lp1="http://apache.org/dav/props/"; xmlns:i0="
> > >   ...
> > > 
> > > That is odd, but if I url-encode the brackets "{" and "}" by looking at
> > > 
> > >   http://superbeast.ucsd.edu/~landry/ArX/%7barchive%7d
> > 
> > Yeah. All uris you feed into gnome-vfs need to be escaped.
> 
> Do you have any idea why it gives me warnings?  Would that be a
> server-side issue, or a gnome-vfs issue?  Also, is there a way to turn
> off the warnings?

This is a messy situation involving conflicting specs; here is my
interpretation:

The WebDAV specification defines the namespace for all of its elements
to be "DAV:". Unfortunately, this clashes with the XML-namespace
recommendation, which says that the value of the XML namespace
declaration attribute (the xmlns:D attribute) should be a URI reference.
A URI reference is defined in RFC 2396 as having a scheme part and then
either a hier_part or an opaque_part after the colon. The key point is
that the part of the colon cannot be empty, according to the RFC. So,
under the XML-namespace + RFC 2396 interpretation, "DAV:" is not a valid
namespace.

Part of the reason for the messiness is that the WebDAV spec was being
defined around the same time as the XML namespace spec and although
there were a number of back-and-forth messages between the two groups
over various things, this one seems to have either fallen through the
cracks or been intentionally not solved. In either case, it seems to be
ingrained into WebDAV lore (and specification).

Now, I have not looked at the gnome-vfs code yet to see where the right
spot to fix this is, but the solution to avoid spitting out the warnings
(which serve no purpose here, since they cannot be fixed by client
systems), is to call xmlPedanticParserDefault(0) before processing these
fragments. The danger here, of course, is that then a number of other
errors may slip through. But this may be something to look at for GNOME
2.8.

Cheers,
Malcolm




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]