neon man page on aLinux

Man page or keyword search:  
man Server   7435 pages
apropos Keyword Search (all sections)
Output format
aLinux logo
[printable version]

NEON(3)			      neon API reference		       NEON(3)

NAME
       neon - HTTP and WebDAV client library

DESCRIPTION
       neon  is	 an  HTTP  and	WebDAV	client library. The major abstractions
       exposed are the HTTP session, created by ne_session_create(3); and  the
       HTTP  request,  created by ne_request_create(3). HTTP authentication is
       handled	 transparently	 for   server	and   proxy    servers,	   see
       ne_set_server_auth(3);  complete	 SSL/TLS support is also included, see
       ne_ssl_set_verify(3).

CONVENTIONS
       Some conventions are used throughout the neon API, to provide a consis‐
       tent and simple interface; these are documented below.

   Thread-safeness and global initialization
       neon  itself  is	 implemented  to  be  thread-safe (avoiding any use of
       global  state),	but  relies  on	 the  operating	 system	 providing   a
       thread-safe  resolver  interface.  Modern  operating  systems offer the
       thread-safe getaddrinfo interface, which	 neon  supports;  some	others
       implement gethostbyname using thread-local storage.

       To  allow  thread-safe use of the OpenSSL library, the application must
       register some locking callbacks in accordance with the OpenSSL documen‐
       tation: http://www.openssl.org/docs/crypto/threads.html.

       Some platforms and libraries used by neon require global initialization
       before use; notably:

       ·  OpenSSL requires global initialization to load shared lookup tables.

       ·  The SOCKS library requires initialization before use.

       ·  The Win32 socket library requires initialization before use.

	The ne_sock_init(3) function should be called before any other use  of
       neon  to perform any necessary initialization needed for the particular
       platform.

   Namespaces
       To avoid possible collisions between names used for  symbols  and  pre‐
       processor  macros  by  an  application and the libraries it uses, it is
       good practice for each library to reserve a particular  namespace  pre‐
       fix.  An application which ensures it uses no names with these prefixes
       is then guaranteed to avoid such collisions.

       The neon library reserves the use of the	 namespace  prefixes  ne_  and
       NE_.  The  libraries  used by neon may also reserve certain namespaces;
       collisions between these libraries and a	 neon-based  application  will
       not  be	detected  at compile time, since the underlying library inter‐
       faces are not exposed through the neon header  files.  Such  collisions
       can  only be detected at link time, when the linker attempts to resolve
       symbols. The following list documents some of the namespaces claimed by
       libraries used by neon; this list may be incomplete.

       SSL, ssl, TLS, tls, ERR_, BIO_, d2i_, i2d_, ASN1_
	      Some  of	the  many prefixes used by the OpenSSL library; little
	      attempt has been made to keep exported symbols within  any  par‐
	      ticular prefixes for this library.

       XML_, Xml[A-Z]
	      Namespaces used by the expat library.

       xml[A-Z], html[A-Z], docb[A-Z]
	      Namespaces  used by the libxml2 library; a relatively small num‐
	      ber of symbols are used without these prefixes.

   Argument validation
       neon does not attempt to validate that the parameters passed  to	 func‐
       tions conform to the API (for instance, checking that pointer arguments
       are not NULL). Any use of the neon API which is not documented to  pro‐
       duce  a	certain	 behaviour results is said to produce undefined behav‐
       iour; it is likely that neon will segfault under these conditions.

   URI paths, WebDAV metadata
       The path strings passed to any function	must  be  URI-encoded  by  the
       application;  neon  never  performs any URI encoding or decoding inter‐
       nally. WebDAV property names and values must  be	 valid	UTF-8  encoded
       Unicode strings.

   User interaction
       As  a  pure library interface, neon will never produce output on stdout
       or stderr; all user interaction is the responsibilty  of	 the  applica‐
       tion.

   Memory handling
       neon  does  not attempt to cope gracefully with an out-of-memory situa‐
       tion; instead, by default, the abort function is called to  immediately
       terminate  the  process.	 An application may register a custom function
       which will be called before abort in such a situation; see ne_oom_call‐
       back(3).

   Callbacks and userdata
       Whenever	 a  callback is registered, a userdata pointer is also used to
       allow the application to associate a context  with  the	callback.  The
       userdata is of type void *, allowing any pointer to be used.

SEE ALSO
       ne_session_create(3), ne_oom_callback(3)

AUTHOR
       Joe Orton <neon@webdav.org>.

neon 0.25.5			20 January 2006			       NEON(3)
[top]

List of man pages available for aLinux

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net