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.
Ryan
> 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 [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
