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

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
FETCH(3)	       FreeBSD Library Functions Manual		      FETCH(3)

NAME
     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

LIBRARY
     File Transfer Library (libfetch, -lfetch)

SYNOPSIS
     #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);

     void
     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);

     int
     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);

     int
     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);

     int
     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);

     int
     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);

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

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

DESCRIPTION
     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:

	 <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.

     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;
	 time_t	      ims_time;
     };

     The ims_time field	stores the time	value for If-Modified-Since HTTP
     requests.

     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
     returns 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
     options.  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
     obtained 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
     <fetch.h>:

     struct url_ent {
	 char	      name[PATH_MAX];
	 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
     return 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
     implementation details of the individual access methods vary, it can gen-
     erally 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.

FILE SCHEME
     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
     them.

FTP SCHEME
     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
     defined.

     If	no user	name or	password is given, the fetch library will attempt an
     anonymous login, with user	name "anonymous" and password "anony-
     mous@<hostname>".

HTTP SCHEME
     The fetchXGetHTTP(), fetchGetHTTP() and fetchPutHTTP() functions imple-
     ment the HTTP/1.1 protocol.  With a little	luck, there is 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
     defined.

     If	the `i'	(if-modified-since) flag is specified, and the ims_time	field
     is	set in struct url, then	fetchXGetHTTP()	and fetchGetHTTP() will	send a
     conditional If-Modified-Since HTTP	header to only fetch the content if it
     is	newer than ims_time.

     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.

AUTHENTICATION
     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
     failure.

     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	are not	set.

     This interface is experimental and	may be subject to change.

RETURN VALUES
     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)"

ENVIRONMENT
     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
			 authorization 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
			 requests.  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.

     NO_PROXY		 Either	a single asterisk, which disables the use of
			 proxies altogether, or	a comma- or whitespace-sepa-
			 rated list of hosts for which proxies should not be
			 used.

     no_proxy		 Same as NO_PROXY, for compatibility.

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

	   HTTP_PROXY=http://proxy.example.com:8080

     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:

	   HTTP_PROXY=http://<user>:<pwd>@proxy.example.com:8080

     The second	method is by using the HTTP_PROXY_AUTH environment variable:

	   HTTP_PROXY=http://proxy.example.com:8080
	   HTTP_PROXY_AUTH=basic:*:<user>:<pwd>

     To	disable	the use	of a proxy for an HTTP server running on the local
     host, define NO_PROXY as follows:

	   NO_PROXY=localhost,127.0.0.1

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

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

     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,
     RFC2616.

     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.

HISTORY
     The fetch library first appeared in FreeBSD 3.0.

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

     This manual page was written by Dag-Erling	Smorgrav <des@FreeBSD.org>.

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

     There is 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,
     superfluous at this site" in an FTP context and "Accepted"	in an HTTP
     context.

     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
     text.

     The error reporting mechanism is unsatisfactory.

     Some parts	of the code are	not fully reentrant.

FreeBSD	10.1		       December	14, 2008		  FreeBSD 10.1

NAME | LIBRARY | SYNOPSIS | DESCRIPTION | FILE SCHEME | FTP SCHEME | HTTP SCHEME | AUTHENTICATION | RETURN VALUES | ENVIRONMENT | EXAMPLES | SEE ALSO | HISTORY | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=fetch&sektion=3&manpath=FreeBSD+7.2-RELEASE>

home | help