# Request / Response

Libwww is based on a request/response paradigm and the 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 an 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.