Date: Tue, 24 Nov 2009 11:05:39 -0800 (PST) From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/140835: libfetch: fetchParseURL(3) returns success with invalid URLs Message-ID: <20091124190539.3A0A81E3035@icarus.home.lan> Resent-Message-ID: <200911241920.nAOJK2Pi014034@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091124190539.3A0A81E3035>