Request / Response

Libwww is based on a request/response paradigm. A Request class defines
"an operation to be performed on a URL". The request object is the
main entry point for an application to issue a request to the Library - all
operations on a URL must use a Request object. The request object
is application independent in that both servers and clients use the same
Request class. Examples of requests passed to the Library are a client
application issuing a GET request on a HTTP URL, or a server issuing
a load on a local file URL. The only difference is that the client gets the
input from a user whereas the server gets the input via the network.

A request object is created with a default set of parameters which are
applicable for many URL requests, but the class defines a huge set of methods
that can be used to customize a request for a particular purpose. Example of
things that you can define is natural language, media types, what RFC 822
headers to use, whether the request should be refreshed from cache etc. Scroll
down and see the set of parameters you can tune.

A request object is registered in the library by issuing an operation on
a URL - for example PUT, POST, or DELETE. You can find
many higher level "request issuing functions" in the
Access module - the methods defined
by the Request class itself are very low level but can of course be used
directly if needed.

Whereas the lifetime of the URL (in form of an anchor) often is very long
(for example as long as the application is running), the lifetime of a request
is limited to the time it takes to service the request. The core does not
automatically delete any request object created by the application - it is
for the application to do. In many cases a request object can be deleted
when any of the termination callback
functions are called but the application may keep request objects around
longer than that.

Libwww can accept an unlimited number of simultaneous requests passed by
the application. One of the main functions of the Library core is to handle
any number of ongoing requests in an intelligent manner by limiting the number
of active request to the fit the available resources as defined by the
application. This is described in more detail by the
Net Class.