bin/140835: libfetch: fetchParseURL(3) returns success with invalid URLs

[Jeremy Chadwick]

>Number:         140835
>Category:       bin
>Synopsis:       libfetch: fetchParseURL(3) returns success with invalid URLs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 24 19:20:02 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 8.0-PRERELEASE amd64
>Organization:
>Environment:
System: FreeBSD icarus.home.lan 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root at icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
>Description:
libfetch contains a function, fetchParseURL(3), whose man page
states the following:

     fetchParseURL() takes a URL in the form of a null-terminated string and
     splits it into its components function according to the Common Internet
     Scheme Syntax detailed in RFC1738.  A regular expression which produces
     this syntax is:

         <scheme>:(//(<user>(:<pwd>)?@)?<host>(:<port>)?)?/(<document>)?

     If the URL does not seem to begin with a scheme name, the following syn-
     tax is assumed:

         ((<user>(:<pwd>)?@)?<host>(:<port>)?)?/(<document>)?

     Note that some components of the URL are not necessarily relevant to all
     URL schemes.  For instance, the file scheme only needs the <scheme> and
     <document> components.

     .....

     fetchParseURL() returns a pointer to a struct url containing the individ-
     ual components of the URL.  If it is unable to allocate memory, or the
     URL is syntactically incorrect, fetchParseURL() returns a NULL pointer.

But when passed a URL such as the below (note the delimiter is
colon-slash, not colon-slash-slash)

	http:/www.somesite.com/

fetchParseURL(3) returns a pointer to a struct with the following
data:

	url->scheme = http
	url->user   = <null>
	url->pwd    = <null>
	url->host   = <null>
	url->port   = 0
	url->doc    = /www.somesite.com/

Given the documentation, fetchParseURL(3) should return NULL in this
scenario; it was able to work out the scheme by itself, which
implies that the RFC1738-compliancy paragraph of the documentation
should apply strictly.

This issue came to light on freebsd-stable:

http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052969.html
http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052971.html
http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052972.html
http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052973.html
>How-To-Repeat:
$ fetch http:/www.somesite.com/
fetch: http:/www.somesite.com/: No address record
$ fetch http:/localhost/
fetch: http:/localhost/: No address record
>Fix:
None known.

>Release-Note:
>Audit-Trail:
>Unformatted: