From nobody@FreeBSD.org  Sun Sep  2 01:12:55 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E538E16A478
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  2 Sep 2007 01:12:55 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id CF8AD13C45B
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  2 Sep 2007 01:12:55 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l821CtJu079594
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 2 Sep 2007 01:12:55 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.1/8.14.1/Submit) id l821CtU5079593;
	Sun, 2 Sep 2007 01:12:55 GMT
	(envelope-from nobody)
Message-Id: <200709020112.l821CtU5079593@www.freebsd.org>
Date: Sun, 2 Sep 2007 01:12:55 GMT
From: Howard Chu <hyc@openldap.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: libfetch accepts invalid URLs
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         116005
>Category:       kern
>Synopsis:       [libfetch] libfetch accepts invalid URLs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    des
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 02 01:20:03 GMT 2007
>Closed-Date:    
>Last-Modified:  Tue Dec 25 15:15:07 UTC 2007
>Originator:     Howard Chu
>Release:        6.2
>Organization:
OpenLDAP Project
>Environment:
FreeBSD hurdy.localdomain 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
The URL parser in libfetch does not enforce the RFC1738 syntax, and it
seems to have no clue about RFC1808. Most likely the code needs to be
refreshed in terms of RFC2396.

The URL syntax specifies that URLs with the form "scheme://authority"
may only be followed by an absolute path, if anything. Thus

  file:///tmp/junk

is valid (references "/tmp/junk")

libfetch also allows references like

  file://./foo/bar

(which references "./foo/bar")

But the URI syntax does not allow relative paths to follow an authority spec.

The old BNF allows "file:./foo/bar" for relative references, although
RFC2396 says this form is deprecated. libfetch doesn't allow this form.
RFC2396 also allows "./foo/bar" for relative references, and libfetch
fails there as well.

I guess in typical use, retrieving remote resources, it doesn't make
sense for libfetch to handle relative URIs, unless you add an API for
setting the base URI.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Howard Chu <hyc@openldap.org>
To: bug-followup@FreeBSD.org, hyc@openldap.org
Cc:  
Subject: Re: kern/116005: [libfetch] libfetch accepts invalid URLs
Date: Sat, 01 Sep 2007 20:38:47 -0700

 Of course that should be RFC3986, not 2396.
 -- 
    -- Howard Chu
    Chief Architect, Symas Corp.  http://www.symas.com
    Director, Highland Sun        http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP     http://www.openldap.org/project/

From: Giorgos Keramidas <keramida@FreeBSD.org>
To: Howard Chu <hyc@openldap.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/116005: libfetch accepts invalid URLs
Date: Sun, 16 Sep 2007 15:10:53 +0300

 On 2007-09-02 01:12, Howard Chu <hyc@openldap.org> wrote:
 > >Number:         116005
 > >Category:       bin
 > >Synopsis:       libfetch accepts invalid URLs
 
 > The URL parser in libfetch does not enforce the RFC1738 syntax, and it
 > seems to have no clue about RFC1808. Most likely the code needs to be
 > refreshed in terms of RFC2396.
 >
 > The URL syntax specifies that URLs with the form "scheme://authority"
 > may only be followed by an absolute path, if anything. Thus
 >
 >   file:///tmp/junk
 >
 > is valid (references "/tmp/junk")
 >
 > libfetch also allows references like
 >   file://./foo/bar
 > (which references "./foo/bar")
 
 In one of the SCM projects I am closely tracking (Mercurial), the URL
 parser supports URIs of the form:
 
     ssh://hostname/relative/path
     ssh://hostname//relative/path
 
 and the argument of the developers for making the first one a relative
 path was that with this sort of URI syntax it is easy to specify both an
 absolute *and* a relative path [with ssh-tunneled repository clones,
 this is really _very_ useful at times :-)].
 
 > But the URI syntax does not allow relative paths to follow an
 > authority spec.
 
 That's interesting.  I am offline right now, but it would be nice to
 have a definitive reference to the relevant RFCs.  I'll look up at least
 the following:
 
     RFC1738
     RFC1808
     RFC2396
 
 Any other related RFCs we should look at?
 
Responsible-Changed-From-To: freebsd-bugs->des 
Responsible-Changed-By: kris 
Responsible-Changed-When: Tue Dec 25 15:14:57 UTC 2007 
Responsible-Changed-Why:  
Assign to maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116005 
>Unformatted:
