Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
FETCH(3)		 BSD Library Functions Manual		      FETCH(3)

     fetchMakeURL, fetchParseURL, fetchFreeURL,	fetchXGetURL, fetchGetURL,
     fetchPutURL, fetchStatURL,	fetchListURL, fetchXGet, fetchGet, fetchPut,
     fetchStat,	fetchList, fetchXGetFile, fetchGetFile,	fetchPutFile,
     fetchStatFile, fetchListFile, fetchXGetHTTP, fetchGetHTTP,	fetchPutHTTP,
     fetchStatHTTP, fetchListHTTP, fetchXGetFTP, fetchGetFTP, fetchPutFTP,
     fetchStatFTP, fetchListFTP	-- file	transfer functions

     File Transfer Library for URLs (libfetch, -lfetch)

     #include <sys/param.h>
     #include <stdio.h>
     #include <fetch.h>

     struct url	*
     fetchMakeURL(const	char *scheme, const char *host,	int port,
	 const char *doc, const	char *user, const char *pwd);

     struct url	*
     fetchParseURL(const char *URL);

     fetchFreeURL(struct url *u);

     FILE *
     fetchXGetURL(const	char *URL, struct url_stat *us,	const char *flags);

     FILE *
     fetchGetURL(const char *URL, const	char *flags);

     FILE *
     fetchPutURL(const char *URL, const	char *flags);

     fetchStatURL(const	char *URL, struct url_stat *us,	const char *flags);

     struct url_ent *
     fetchListURL(const	char *URL, const char *flags);

     FILE *
     fetchXGet(struct url *u, struct url_stat *us, const char *flags);

     FILE *
     fetchGet(struct url *u, const char	*flags);

     FILE *
     fetchPut(struct url *u, const char	*flags);

     fetchStat(struct url *u, struct url_stat *us, const char *flags);

     struct url_ent *
     fetchList(struct url *u, const char *flags);

     FILE *
     fetchXGetFile(struct url *u, struct url_stat *us, const char *flags);

     FILE *
     fetchGetFile(struct url *u, const char *flags);

     FILE *
     fetchPutFile(struct url *u, const char *flags);

     fetchStatFile(struct url *u, struct url_stat *us, const char *flags);

     struct url_ent *
     fetchListFile(struct url *u, const	char *flags);

     FILE *
     fetchXGetHTTP(struct url *u, struct url_stat *us, const char *flags);

     FILE *
     fetchGetHTTP(struct url *u, const char *flags);

     FILE *
     fetchPutHTTP(struct url *u, const char *flags);

     fetchStatHTTP(struct url *u, struct url_stat *us, const char *flags);

     struct url_ent *
     fetchListHTTP(struct url *u, const	char *flags);

     FILE *
     fetchXGetFTP(struct url *u, struct	url_stat *us, const char *flags);

     FILE *
     fetchGetFTP(struct	url *u,	const char *flags);

     FILE *
     fetchPutFTP(struct	url *u,	const char *flags);

     fetchStatFTP(struct url *u, struct	url_stat *us, const char *flags);

     struct url_ent *
     fetchListFTP(struct url *u, const char *flags);

     These functions implement a high-level library for	retrieving and upload-
     ing files using Uniform Resource Locators (URLs).

     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:


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


     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.

     fetchMakeURL() and	fetchParseURL()	return a pointer to a url structure,
     which is defined as follows in <fetch.h>:

     #define URL_SCHEMELEN 16
     #define URL_USERLEN 256
     #define URL_PWDLEN	256

     struct url	{
	 char	      scheme[URL_SCHEMELEN+1];
	 char	      user[URL_USERLEN+1];
	 char	      pwd[URL_PWDLEN+1];
	 char	      host[MAXHOSTNAMELEN+1];
	 int	      port;
	 char	     *doc;
	 off_t	      offset;
	 size_t	      length;

     The pointer returned by fetchMakeURL() or fetchParseURL() should be freed
     using fetchFreeURL().

     fetchXGetURL(), fetchGetURL(), and	fetchPutURL() constitute the recom-
     mended interface to the fetch library.  They examine the URL passed to
     them to determine the transfer method, and	call the appropriate lower-
     level functions to	perform	the actual transfer.  fetchXGetURL() also re-
     turns the remote document's metadata in the url_stat structure pointed to
     by	the us argument.

     The flags argument	is a string of characters which	specify	transfer op-
     tions.  The meaning of the	individual flags is scheme-dependent, and is
     detailed in the appropriate section below.

     fetchStatURL() attempts to	obtain the requested document's	metadata and
     fill in the structure pointed to by its second argument.  The url_stat
     structure is defined as follows in	<fetch.h>:

     struct url_stat {
	 off_t	      size;
	 time_t	      atime;
	 time_t	      mtime;

     If	the size could not be obtained from the	server,	the size field is set
     to	-1.  If	the modification time could not	be obtained from the server,
     the mtime field is	set to the epoch.  If the access time could not	be ob-
     tained from the server, the atime field is	set to the modification	time.

     fetchListURL() attempts to	list the contents of the directory pointed to
     by	the URL	provided.  If successful, it returns a malloced	array of
     url_ent structures.  The url_ent structure	is defined as follows in

     struct url_ent {
	 char	      name[MAXPATHLEN];
	 struct	url_stat stat;

     The list is terminated by an entry	with an	empty name.

     The pointer returned by fetchListURL() should be freed using free().

     fetchXGet(), fetchGet(), fetchPut() and fetchStat() are similar to
     fetchXGetURL(), fetchGetURL(), fetchPutURL() and fetchStatURL(), except
     that they expect a	pre-parsed URL in the form of a	pointer	to a struct
     url rather	than a string.

     All of the	fetchXGetXXX(),	fetchGetXXX() and fetchPutXXX()	functions re-
     turn a pointer to a stream	which can be used to read or write data	from
     or	to the requested document, respectively.  Note that although the im-
     plementation details of the individual access methods vary, it can	gener-
     ally be assumed that a stream returned by one of the fetchXGetXXX() or
     fetchGetXXX() functions is	read-only, and that a stream returned by one
     of	the fetchPutXXX() functions is write-only.

     fetchXGetFile(), fetchGetFile() and fetchPutFile()	provide	access to doc-
     uments which are files in a locally mounted file system.  Only the	<docu-
     ment> component of	the URL	is used.

     fetchXGetFile() and fetchGetFile()	do not accept any flags.

     fetchPutFile() accepts the	`a' (append to file) flag.  If that flag is
     specified,	the data written to the	stream returned	by fetchPutFile() will
     be	appended to the	previous contents of the file, instead of replacing

     fetchXGetFTP(), fetchGetFTP() and fetchPutFTP() implement the FTP proto-
     col as described in RFC959.

     If	the `p'	(passive) flag is specified, a passive (rather than active)
     connection	will be	attempted.

     If	the `l'	(low) flag is specified, data sockets will be allocated	in the
     low (or default) port range instead of the	high port range	(see ip(4)).

     If	the `d'	(direct) flag is specified, fetchXGetFTP(), fetchGetFTP() and
     fetchPutFTP() will	use a direct connection	even if	a proxy	server is de-

     If	no user	name or	password is given, the fetch library will attempt an
     anonymous login, with user	name "anonymous" and password "anony-

     The fetchXGetHTTP(), fetchGetHTTP() and fetchPutHTTP() functions imple-
     ment the HTTP/1.1 protocol.  With a little	luck, there's even a chance
     that they comply with RFC2616 and RFC2617.

     If	the `d'	(direct) flag is specified, fetchXGetHTTP(), fetchGetHTTP()
     and fetchPutHTTP()	will use a direct connection even if a proxy server is

     Since there seems to be no	good way of implementing the HTTP PUT method
     in	a manner consistent with the rest of the fetch library,	fetchPutHTTP()
     is	currently unimplemented.

     Apart from	setting	the appropriate	environment variables and specifying
     the user name and password	in the URL or the struct url, the calling pro-
     gram has the option of defining an	authentication function	with the fol-
     lowing prototype:

     int myAuthMethod(struct url *u)

     The callback function should fill in the user and pwd fields in the pro-
     vided struct url and return 0 on success, or any other value to indicate

     To	register the authentication callback, simply set fetchAuthMethod to
     point at it.  The callback	will be	used whenever a	site requires authen-
     tication and the appropriate environment variables	aren't set.

     This interface is experimental and	may be subject to change.

     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.

     The fetchStat() functions return 0	on success and -1 on failure.

     All other functions return	a stream pointer which may be used to access
     the requested document, or	NULL if	an error occurred.

     The following error codes are defined in <fetch.h>:

     [FETCH_ABORT]	 Operation aborted

     [FETCH_AUTH]	 Authentication	failed

     [FETCH_DOWN]	 Service unavailable

     [FETCH_EXISTS]	 File exists

     [FETCH_FULL]	 File system full

     [FETCH_INFO]	 Informational response

     [FETCH_MEMORY]	 Insufficient memory

     [FETCH_MOVED]	 File has moved

     [FETCH_NETWORK]	 Network error

     [FETCH_OK]		 No error

     [FETCH_PROTO]	 Protocol error

     [FETCH_RESOLV]	 Resolver error

     [FETCH_SERVER]	 Server	error

     [FETCH_TEMP]	 Temporary error

     [FETCH_TIMEOUT]	 Operation timed out

     [FETCH_UNAVAIL]	 File is not available

     [FETCH_UNKNOWN]	 Unknown error

     [FETCH_URL]	 Invalid URL

     The accompanying error message includes a protocol-specific error code
     and message, e.g. "File is	not available (404 Not Found)"

     FETCH_BIND_ADDRESS	 Specifies a hostname or IP address to which sockets
			 used for outgoing connections will be bound.

     FTP_LOGIN		 Default FTP login if none was provided	in the URL.

     FTP_PASSIVE_MODE	 If set	to anything but	`no', forces the FTP code to
			 use passive mode.

     FTP_PASSWORD	 Default FTP password if the remote server requests
			 one and none was provided in the URL.

     FTP_PROXY		 URL of	the proxy to use for FTP requests.  The	docu-
			 ment part is ignored.	FTP and	HTTP proxies are sup-
			 ported; if no scheme is specified, FTP	is assumed.
			 If the	proxy is an FTP	proxy, libfetch	will send
			 `user@host' as	user name to the proxy,	where `user'
			 is the	real user name,	and `host' is the name of the
			 FTP server.

			 If this variable is set to an empty string, no	proxy
			 will be used for FTP requests,	even if	the HTTP_PROXY
			 variable is set.

     ftp_proxy		 Same as FTP_PROXY, for	compatibility.

     HTTP_AUTH		 Specifies HTTP	authorization parameters as a colon-
			 separated list	of items.  The first and second	item
			 are the authorization scheme and realm	respectively;
			 further items are scheme-dependent.  Currently, only
			 basic authorization is	supported.

			 Basic authorization requires two parameters: the user
			 name and password, in that order.

			 This variable is only used if the server requires au-
			 thorization and no user name or password was speci-
			 fied in the URL.

     HTTP_PROXY		 URL of	the proxy to use for HTTP requests.  The docu-
			 ment part is ignored.	Only HTTP proxies are sup-
			 ported	for HTTP requests.  If no port number is spec-
			 ified,	the default is 3128.

			 Note that this	proxy will also	be used	for FTP	docu-
			 ments,	unless the FTP_PROXY variable is set.

     http_proxy		 Same as HTTP_PROXY, for compatibility.

     HTTP_PROXY_AUTH	 Specifies authorization parameters for	the HTTP proxy
			 in the	same format as the HTTP_AUTH variable.

			 This variable is used if and only if connected	to an
			 HTTP proxy, and is ignored if a user and/or a pass-
			 word were specified in	the proxy URL.

     HTTP_REFERER	 Specifies the referrer	URL to use for HTTP requests.
			 If set	to "auto", the document	URL will be used as
			 referrer URL.

     HTTP_USER_AGENT	 Specifies the User-Agent string to use	for HTTP re-
			 quests.  This can be useful when working with HTTP
			 origin	or proxy servers that differentiate between
			 user agents.

     NETRC		 Specifies a file to use instead of ~/.netrc to	look
			 up login names	and passwords for FTP sites.  See
			 ftp(1)	for a description of the file format.  This
			 feature is experimental.

     To	access a proxy server on port	8080, set the
     HTTP_PROXY	environment variable in	a manner similar to this:


     If	the proxy server requires authentication, there	are two	options	avail-
     able for passing the authentication data.	The first method is by using
     the proxy URL:


     The second	method is by using the HTTP_PROXY_AUTH environment variable:


     fetch(1), ftpio(3), ip(4)

     J.	Postel and J. K. Reynolds, File	Transfer Protocol, October 1985,

     P.	Deutsch, A. Emtage, and	A. Marine., How	to Use Anonymous FTP, May
     1994, RFC1635.

     T.	Berners-Lee, L.	Masinter, and M. McCahill, Uniform Resource Locators
     (URL), December 1994, RFC1738.

     R.	Fielding, J. Gettys, J.	Mogul, H. Frystyk, L. Masinter,	P. Leach, and
     T.	Berners-Lee, Hypertext Transfer	Protocol -- HTTP/1.1, January 1999,

     J.	Franks,	P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
     Luotonen, and L. Stewart, HTTP Authentication: Basic and Digest Access
     Authentication, June 1999,	RFC2617.

     The fetch library first appeared in FreeBSD 3.0.

     The fetch library was mostly written by Dag-Erling	Smorgrav
     <> with numerous suggestions from Jordan K.	Hubbard
     <>,	Eugene Skepner <> and	other FreeBSD develop-
     ers.  It replaces the older ftpio library written by Poul-Henning Kamp
     <> and Jordan K. Hubbard <>.

     This manual page was written by Dag-Erling	Smorgrav <>.

     Some parts	of the library are not yet implemented.	 The most notable ex-
     amples of this are	fetchPutHTTP(),	fetchListHTTP(), fetchListFTP()	and
     FTP proxy support.

     There's no	way to select a	proxy at run-time other	than setting the
     HTTP_PROXY	or FTP_PROXY environment variables as appropriate.

     libfetch does not understand or obey 305 (Use Proxy) replies.

     Error numbers are unique only within a certain context; the error codes
     used for FTP and HTTP overlap, as do those	used for resolver and system
     errors.  For instance, error code 202 means "Command not implemented, su-
     perfluous at this site" in	an FTP context and "Accepted" in an HTTP con-

     fetchStatFTP() does not check that	the result of an MDTM command is a
     valid date.

     The man page is incomplete, poorly	written	and produces badly formatted

     The error reporting mechanism is unsatisfactory.

     Some parts	of the code are	not fully reentrant.

BSD				 July 1, 1998				   BSD


Want to link to this manual page? Use this URL:

home | help