apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Marculescu <p...@p16.pub.ro>
Subject Re: [PATCH] apr_uri
Date Mon, 03 Jun 2002 07:51:51 GMT

Cliff Woolley wrote:
> On Mon, 3 Jun 2002, Paul Marculescu wrote:
> > I made a little patch for apr-util's apr_uri.c to handle win32 absolute
> > paths under file:// schema.
> I'll admit it strikes me as a bit odd to be supporting platform-specific
> forms of _uniform_ resource identifiers.  :-)  Is this a
> standards-recognized form or is it just one that Microsoft made up?  If
> it's valid under the standard, then I suppose it makes sense to support
> it.

I think you are right, but suppose you're on a Win32 platform and you
want to specify 
this path: D:/test in a file url. According to the standards, it will be

The apr_uri_parse() function generates the path /D:/test from this URI.
This is where I got a little confused, since rfc's said:

 A file URL takes the form:
 where <host> is the fully qualified domain name of the system on
 which the <path> is accessible, and <path> is a hierarchical 
 directory path of the form <directory>/<directory>/.../<name>. 

so why is the '/' after the host included in the path?
On Unix platforms, this is quite ok, as the fs there has a single root:
On Win32, there is no single root, so not all paths can be expressed as
relative path from any other path.
Getting back to my problem, I end up with this: /D:/test, which is not

If the URL was file:///test, the path will be /test, which on Win32
means: the "test" directory in the root of the current partition. What
if the current partition is not "D:" ?

That's why I thought of this patch.

> Then there is also the issue that things in APR-util are supposed to be
> platform-neutral... we'll have to figure out how to deal with that.  That
> doesn't mean that I think we should move this stuff to APR, of course.
> We need to find a middle ground.
> --Cliff
> PS: Please be sure to follow our styleguide when submitting patches...
> namely, no tabs.  :)

There were some tabs in the apr_uri.c as I "cvs co" it a few minutes ago
(again, to make sure).
000014E0:  20 28 70 2C 0D 0A 09 09

so I got a little confused. Anyway, I'll keep that in mind.


View raw message