Resource retrieval over a source network determined by checking a header of the requested resource for access restrictions

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS FIG.
1 is a schematic presentation of the architecture of an embodiment of the present invention.
A User or client 1 is the end user using a World Wide Web Browser which supports identification items which a WWW Server can give to the browser and which the browser stores and gives back only to the server it originally received them from.
These information items, e.
g.
cookies, enable the connection of several connectionless requests into a client session.
Proxy 2 is a software and/or hardware component that monitors the data traffic and takes care of the access control and billing using the Internet Service Broker (ISB) functionality.
WWW Server 3 is a standard httpd program which delivers an HTML page, and possible images, sound and other digital data linked into the page, upon a client's request.
The WWW Server 3 supports client defined headers by, for example, .
htaccess access control mechanism, custom headers or cgi-bin programs.
Most current WWW servers, for example APACHE.
TM.
or those provided by NETSCAPE.
TM.
or MICROSOFT.
TM.
, have this functionality.
WWW Data Store 4 is a file system, database or the like, where the client accessible data is stored, whilst ISB 5 is the Internet Service Broker which defines unified interfaces for client identification and authentication, and for billing.
Proxy Data Store 6 provides a cache in which the proxy 2 stores frequently requested documents.
Before describing the operation of a data retrieving system used by the network of FIG.
1, it is useful to describe the nature and role of the so-called "Header" which is associated with request reply messages sent over the Internet.
The Header is a part of the message packet which contains control data related to the packet.
For the purpose of the present example, these headers are part of the HTTP protocol (or HTTPS which is similar to HTTP but includes means for some security functionality).
Thus, these headers have the following form: Header-field-name: value of the field in which the "Header-field-name" specifies the name of the header field and the "value of the field" is a character string, starting after the field separator and ending with the next line feed