httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PROPOSAL] apr-client
Date Wed, 26 Sep 2001 21:46:44 GMT
On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote:

There is supposed to be an http client library as a part of apr-util.
It's just that nobody has actually written it yet.  I would prefer to not
create another library for this, because this client lib was one of the
reasons that apr-util was created in the first place.


> Hi all,
> I wish to propose a new library: apr-client.
> It is basically a http client library.  I see
> a direct use for at least three projects:
>  - mod_proxy (which has most of the code in it),
>  - flood (to do more flexible testing, for example
>           with authentication, or even ssl client auth),
>  - subversion (which is currently using neon).
> The library is going to be based on apr
> and apr-util, and will have an optional dependency
> on openssl (through a --with-ssl[=path] switch).
> Features:
>  - sessions
>  - request building
>  - response parsing
>  - pipelining
>  - authentication support
>  - filters
>    - like ssl, gz, chunk
> Callbacks will be used to drive events (like responses,
> or the need for auth information).
> The library should make heavy use of buckets/brigades,
> I dare even say the request building is a thin wrapper
> around those.
> Requests supported should be all HTTP requests and
> the DAV extensions.
> The filters are a nice area for code reuse.  The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side.  This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl.  This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).
> You might ask yourself why the world would need yet
> another http client library.  Well, there seem to be
> only two good ones: curl and neon.  Curl is bloated
> (has ftp, gopher, etc support and is more a general
>  network client library).  Neon is good, but LGPL.  Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).
> Well, this mail isn't the extensive description I wanted
> to give*, but surely enough to get some feedback.
> Sander
> *) Am a bit distracted for some reason.


Ryan Bloom
Covalent Technologies

View raw message