Annotation of libwww/Library/src/HTHost.html, revision 2.30
2.1 frystyk 1: <HTML>
2: <HEAD>
2.14 frystyk 3: <TITLE>W3C Sample Code Library libwww Host Class</TITLE>
2.1 frystyk 4: </HEAD>
5: <BODY>
2.3 frystyk 6: <H1>
7: The Host Class
8: </H1>
2.1 frystyk 9: <PRE>
10: /*
11: ** (c) COPYRIGHT MIT 1995.
12: ** Please first read the full copyright statement in the file COPYRIGH.
13: */
14: </PRE>
2.3 frystyk 15: <P>
16: The Host class manages what we know about a remote host. This can for example
17: be what type of host it is, and what version it is using. Notice that a host
18: object can be used to describe both a server or a client - all information
19: in the Host object can be shared regardless of whether it is to be used in
20: a server application or a client application.
21: <P>
22: This module is implemented by <A HREF="HTHost.c">HTHost.c</A>, and it is
2.21 frystyk 23: a part of the <A HREF="http://www.w3.org/Library/"> W3C Sample Code
2.3 frystyk 24: Library</A>.
2.1 frystyk 25: <PRE>
26: #ifndef HTHOST_H
27: #define HTHOST_H
28:
2.30 ! vbancrof 29: #ifdef __cplusplus
! 30: extern "C" {
! 31: #endif
! 32:
2.1 frystyk 33: typedef struct _HTHost HTHost;
2.26 frystyk 34: #define HOST_HASH_SIZE HT_M_HASH_SIZE
2.1 frystyk 35:
36: #include "HTChannl.h"
37: #include "HTReq.h"
2.2 frystyk 38: #include "HTEvent.h"
2.8 frystyk 39: #include "HTProt.h"
2.15 frystyk 40: #include "HTTimer.h"
2.1 frystyk 41: </PRE>
2.3 frystyk 42: <P>
43: The Host class contains information about the remote host, for example the
44: type (HTTP/1.0, HTTP/1.1, FTP etc.) along with information on how the connections
45: can be used (if it supports persistent connections, interleaved access etc.)
46: <H2>
2.24 frystyk 47: <A NAME="Creation">Creation and Deletion Methods</A>
2.3 frystyk 48: </H2>
49: <P>
50: We keep a cache of information that we know about a remote host. This allows
2.5 frystyk 51: us to be much more detailed in generating requests. Search the host info
52: cache for a host object or create a new one and add it. Examples of host
53: names are
2.1 frystyk 54: <UL>
2.3 frystyk 55: <LI>
56: www.w3.org
57: <LI>
58: www.foo.com:8000
2.1 frystyk 59: </UL>
2.3 frystyk 60: <H3>
61: Add a Host Object
62: </H3>
2.1 frystyk 63: <PRE>
2.10 eric 64: extern HTHost * HTHost_new (char * host, u_short u_port);
65: extern HTHost * HTHost_newWParse(HTRequest * request, char * url, u_short u_port);
2.8 frystyk 66: extern int HTHost_hash (HTHost * host);
2.1 frystyk 67: </PRE>
2.3 frystyk 68: <H3>
69: Delete a Host Object
70: </H3>
71: <P>
72: The Host Class contains an automatic garbage collection of Host objects so
73: that we don't keep information around that is stale.
2.6 frystyk 74: <H3>
75: Find a Host Object
76: </H3>
77: <P>
78: Searches the cache of known hosts to see if we already have information about
79: this host. If not then we return NULL.
2.24 frystyk 80: <PRE>
81: extern HTHost * HTHost_find (char * host);
82: </PRE>
83: <H3>
2.28 frystyk 84: Delete the Host table
85: </H3>
86: <P>
87: Cleanup and delete the host table.
88: <PRE>
89: extern void HTHost_deleteAll (void);
90: </PRE>
91: <H3>
2.24 frystyk 92: Is Host Idle?
93: </H3>
94: <P>
95: You can use this function to see whether a host object is idle or in use.
96: We have several modes describing how and when a host is idle. This is a function
97: of the <A HREF="HTTrans.html">Transport Object</A>
98: <PRE>
99: extern BOOL HTHost_isIdle (HTHost * host);
2.6 frystyk 100: </PRE>
2.3 frystyk 101: <H2>
2.24 frystyk 102: <A NAME="Remote">Remote Host Information</A>
2.3 frystyk 103: </H2>
104: <P>
2.12 frystyk 105: We keep track of the capabilities of the host in the other end so thatwe
106: may adjust our queries to fit it better
2.3 frystyk 107: <H3>
2.5 frystyk 108: Remote Host Name
109: </H3>
110: <P>
111: Get the name of the remote host. This is set automatically when a new Host
112: object and can be asked for at any point in time. You can not change the
113: host name but must create a new Host object instead.
114: <PRE>
115: extern char * HTHost_name (HTHost * host);
116: </PRE>
117: <H3>
118: Remote Host Protocol Class and Version
2.3 frystyk 119: </H3>
120: <P>
121: Define the <EM>host class</EM> of the host at the other end. A class is a
122: generic description of the protocol which is exactly like the access method
123: in a URL, for example "http" etc. The <EM>host version</EM> is a finer
124: distinction (sub-class) between various versions of the host class, for example
125: HTTP/0.9, HTTP/1.1 etc. The host version is a bit flag that the protocol
126: module can define on its own. That way we don't have to change this module
127: when registering a new protocol module. The <EM>host type</EM> is a description
128: of whether we can keep the connection persistent or not.
2.1 frystyk 129: <PRE>
130: extern char * HTHost_class (HTHost * host);
131: extern void HTHost_setClass (HTHost * host, char * s_class);
132:
133: extern int HTHost_version (HTHost * host);
134: extern void HTHost_setVersion (HTHost * host, int version);
135: </PRE>
2.3 frystyk 136: <H3>
2.12 frystyk 137: Public Methods accessible on This Host
2.4 frystyk 138: </H3>
139: <P>
140: A server can inform a client about the supported methods using the
141: <CODE>Public</CODE> header.
142: <PRE>extern HTMethod HTHost_publicMethods (HTHost * me);
143: extern void HTHost_setPublicMethods (HTHost * me, HTMethod methodset);
144: extern void HTHost_appendPublicMethods (HTHost * me, HTMethod methodset);
145: </PRE>
2.12 frystyk 146: <H3>
2.4 frystyk 147: Server Name of Remote Host
2.12 frystyk 148: </H3>
2.4 frystyk 149: <P>
150: A server can send its server application name and version in a HTTP response.
151: We pick up this information and add it to the Host object
152: <PRE>extern char * HTHost_server (HTHost * host);
153: extern BOOL HTHost_setServer (HTHost * host, const char * server);
154: </PRE>
2.12 frystyk 155: <H3>
2.4 frystyk 156: User Agent Name of Remote Host
2.12 frystyk 157: </H3>
2.4 frystyk 158: <P>
159: A client can send the name of the client application in a HTTP request. We
2.5 frystyk 160: pick up this information and add it to the Host Object
2.4 frystyk 161: <PRE>extern char * HTHost_userAgent (HTHost * host);
162: extern BOOL HTHost_setUserAgent (HTHost * host, const char * userAgent);
163: </PRE>
2.12 frystyk 164: <H3>
2.7 frystyk 165: Range Units Accepted by this Host
2.12 frystyk 166: </H3>
2.7 frystyk 167: <P>
168: Since all HTTP entities are represented in HTTP messages as sequences of
169: bytes, the concept of a byte range is meaningful for any HTTP entity. (However,
170: not all clients and servers need to support byte-range operations.) Byte
171: range specifications in HTTP apply to the sequence of bytes in the entity-body
172: (not necessarily the same as the message-body). A byte range operation may
173: specify a single range of bytes, or a set of ranges within a single entity.
174: <P>
175: You can also check whether a specific range unit is OK. We always say
176: <CODE>YES</CODE> except if we have a specific statement from the server that
177: it doesn't understand byte ranges - that is - it has sent "none" in a
178: "Accept-Range" response header
179: <PRE>
180: extern char * HTHost_rangeUnits (HTHost * host);
181: extern BOOL HTHost_setRangeUnits (HTHost * host, const char * units);
182: extern BOOL HTHost_isRangeUnitAcceptable (HTHost * host, const char * unit);
183: </PRE>
2.18 frystyk 184: <H3>
2.23 frystyk 185: User Defined Contexts
2.18 frystyk 186: </H3>
2.23 frystyk 187: <P>
188: This can be used for anything that the application would like to keep tabs
189: on.
2.18 frystyk 190: <PRE>
191: extern void HTHost_setContext (HTHost * me, void * context);
192: extern void * HTHost_context (HTHost * me);
193: </PRE>
2.12 frystyk 194: <H2>
2.24 frystyk 195: Register a Request on a Host Object
2.12 frystyk 196: </H2>
2.3 frystyk 197: <P>
2.24 frystyk 198: Requests are queued in the Host object until we have
199: <A HREF="#Pending">resources to start them</A>. The request is in the form
200: of a <A HREF="HTNet.html">Net object</A> as we may have multiple socket requests
201: per <A HREF="HTReq.html">Request object</A>. This is for example the case
202: with <A HREF="WWWFTp.html">FTP</A> which uses two connections.
2.1 frystyk 203: <PRE>
2.24 frystyk 204: extern int HTHost_addNet (HTHost * host, HTNet * net);
205: extern BOOL HTHost_deleteNet (HTHost * host, HTNet * net, int status);
2.1 frystyk 206:
2.24 frystyk 207: extern HTList * HTHost_net (HTHost * host);
208: </PRE>
209: <H2>
210: Channels
211: </H2>
212: <P>
213: A <A HREF="HTChannl.html">Channel object</A> is an abstraction for a transport,
214: like a TCP connection, for example. Each host object can have at most one
215: channel object associated with it.
216: <H3>
217: Create a Channel to a Host
218: </H3>
219: <P>
220: As a <A HREF="HTNet.html">Net Object</A> doesn't necessarily know whether
221: there is a channel up and running and whether that channel can be reused,
222: it must do an explicit connect the the host.
223: <PRE>
2.29 frystyk 224: extern int HTHost_connect (HTHost * host, HTNet * net, char * url);
2.25 frystyk 225:
2.29 frystyk 226: extern int HTHost_accept (HTHost * host, HTNet * net, char * url);
227:
228: extern int HTHost_listen (HTHost * host, HTNet * net, char * url);
2.1 frystyk 229: </PRE>
2.3 frystyk 230: <H3>
2.24 frystyk 231: Is Channel About to Close?
2.3 frystyk 232: </H3>
233: <P>
2.24 frystyk 234: As soon as we know that a channel is about to close (for example because
235: the server sends us a <TT>Connection: close</TT> header field) then we register
236: this informtation in the Host object:
2.1 frystyk 237: <PRE>
2.15 frystyk 238: extern BOOL HTHost_setCloseNotification (HTHost * host, BOOL mode);
239: extern BOOL HTHost_closeNotification (HTHost * host);
2.1 frystyk 240: </PRE>
2.3 frystyk 241: <H3>
2.24 frystyk 242: Find Channel Associated with a Host Object
2.3 frystyk 243: </H3>
244: <P>
2.24 frystyk 245: Here you can find an already associated channel with a host object or you
246: can explicitly associate a channel with a host object.
2.1 frystyk 247: <PRE>
2.24 frystyk 248: extern BOOL HTHost_setChannel (HTHost * host, HTChannel * channel);
249: extern HTChannel * HTHost_channel (HTHost * host);
2.1 frystyk 250: </PRE>
2.24 frystyk 251: <H3>
252: Delete a Channel
253: </H3>
2.3 frystyk 254: <P>
2.24 frystyk 255: When a channel is deleted, it must be unregistered from the host object which
256: is done by this operation:
2.1 frystyk 257: <PRE>
2.24 frystyk 258: extern BOOL HTHost_clearChannel (HTHost * host, int status);
2.1 frystyk 259: </PRE>
2.5 frystyk 260: <H2>
2.24 frystyk 261: <A NAME="Transport">Transport Mode</A>
2.12 frystyk 262: </H2>
263: <P>
2.24 frystyk 264: The way a channel can be used depends on the
265: <A HREF="HTTrans.html">transport</A> and what mode the channel is in. The
266: mode (whether we can use persistent connections, pipeline, etc.) may change
267: mode in the middle of a connection If the new mode is lower than the old
268: mode then adjust the pipeline accordingly. That is, if we are going into
269: single mode then move all entries in the pipeline and move the rest to the
270: pending queue. They will get launched at a later point in time.
271: <PRE>
272: extern HTTransportMode HTHost_mode (HTHost * host, BOOL * active);
2.12 frystyk 273: extern BOOL HTHost_setMode (HTHost * host, HTTransportMode mode);
274: </PRE>
275: <H2>
2.24 frystyk 276: <A NAME="Pending">Handling Pending Requests</A>
2.5 frystyk 277: </H2>
278: <P>
2.24 frystyk 279: There are two ways we can end up with pending requests:
2.5 frystyk 280: <OL>
281: <LI>
282: If we are out of sockets then register new host objects as pending.
283: <LI>
284: If we are pending on a connection then register new net objects as pending
285: </OL>
286: <P>
287: This set of functions handles pending host objects and can start new requests
288: as resources get available. The first function checks the host object for
289: any pending <A HREF="HTNet.html">Net objects</A> and return the first of
290: these Net objects.
2.3 frystyk 291: <PRE>
2.5 frystyk 292: extern HTNet * HTHost_nextPendingNet (HTHost * host);
293: </PRE>
294: <P>
295: The second checks the list of pending host objects waiting for a socket and
296: returns the first of these Host objects.
297: <PRE>
298: extern HTHost * HTHost_nextPendingHost (void);
299: </PRE>
2.24 frystyk 300: <H3>
301: Start the Next Pending reqeust
302: </H3>
2.5 frystyk 303: <P>
304: Start the next pending request if any. First we look for pending requests
305: for the same host and then we check for any other pending hosts. If nothing
2.24 frystyk 306: pending then register a close event handler to have something catching the
307: socket if the remote server closes the connection, for example due to timeout.
2.8 frystyk 308: <PRE>
309: extern BOOL HTHost_launchPending (HTHost * host);
310: </PRE>
2.22 frystyk 311: <H3>
2.24 frystyk 312: Stop Launch of Pending Requests
2.22 frystyk 313: </H3>
2.23 frystyk 314: <P>
2.24 frystyk 315: Controls whether pending requests should be automatically activated. The
316: default is on, but if turned off then no pending requests are launched.
2.22 frystyk 317: <PRE>
2.24 frystyk 318: extern void HTHost_enable_PendingReqLaunch (void);
319: extern void HTHost_disable_PendingReqLaunch (void);
2.22 frystyk 320: </PRE>
2.12 frystyk 321: <H2>
2.24 frystyk 322: <A NAME="Persistent">Persistent Connections</A>
2.12 frystyk 323: </H2>
2.24 frystyk 324: <P>
325: We don't want more than (Max open sockets) - 2 connections to be persistent
326: in order to avoid deadlock. You can set the max number of simultaneous open
327: connection in the <A HREF="HTNet.html"#Resources>HTNet manager</A>.
328: <H3>
329: Is this host Persistent?
330: </H3>
2.8 frystyk 331: <PRE>
2.24 frystyk 332: extern BOOL HTHost_setPersistent (HTHost * host, BOOL persistent,
333: HTTransportMode mode);
334: extern BOOL HTHost_isPersistent (HTHost * host);
2.8 frystyk 335: </PRE>
336: <H3>
2.24 frystyk 337: Persistent Connection Timeouts
2.8 frystyk 338: </H3>
2.12 frystyk 339: <P>
2.24 frystyk 340: If the server doesn't close the connection on us then we close it after a
341: while so that we don't unnecessarily take up resources (see also how the
342: <A HREF="#RequestTimeout">timeouts of individual requests </A>can be set).
343: Libwww provides two mechanisms: an active timeout and a passive timeout.
344: The former uses <A HREF="HTTimer.html">libwww timers</A> and is the preferred
345: mechanism, the latter passively looks at the Host object when a new request
346: is issued in order to determine whether the existing channel can be reused.
347: This is primariliy for non-preemptive requests which in general is deprecated.
348: <P>
349: By default we have an active timeout of 60 secs and a passive timeout of
350: 120 secs (the latter is longer as this is less reliable). Active timeout
351: s can be accessed using these functions:
2.8 frystyk 352: <PRE>
2.24 frystyk 353: extern BOOL HTHost_setActiveTimeout (ms_t timeout);
354: extern ms_t HTHost_activeTimeout (void);
2.8 frystyk 355: </PRE>
2.12 frystyk 356: <P>
2.24 frystyk 357: and passive timeouts can be accessed using these functions
2.8 frystyk 358: <PRE>
2.24 frystyk 359: extern time_t HTHost_persistTimeout (void);
360: extern BOOL HTHost_setPersistTimeout (time_t timeout);
2.8 frystyk 361: </PRE>
2.12 frystyk 362: <P>
2.24 frystyk 363: The following two functions are deprecated:
364: <PRE>
365: extern void HTHost_setPersistExpires (HTHost * host, time_t expires);
366: extern time_t HTHost_persistExpires (HTHost * host);
2.12 frystyk 367: </PRE>
2.8 frystyk 368: <H3>
2.24 frystyk 369: Keeping Track of Number of Reqeusts
2.8 frystyk 370: </H3>
2.12 frystyk 371: <P>
2.24 frystyk 372: Another way to detect when a connection is about to close is to count the
373: number of requests made. For example, the (current) default bevaior by most
374: Apache servers is to close a TCP connection after 100 requests. I don't quite
375: think it makes sense to control the close of a connection like this but anyway,
376: there we go.
2.8 frystyk 377: <PRE>
2.24 frystyk 378: extern void HTHost_setReqsPerConnection (HTHost * host, int reqs);
379: extern int HTHost_reqsPerConnection (HTHost * host);
380: extern void HTHost_setReqsMade (HTHost * host, int reqs);
381: extern int HTHost_reqsMade (HTHost * host);
2.8 frystyk 382: </PRE>
2.24 frystyk 383: <H2>
384: <A NAME="R&W">Read and Write Management</A>
385: </H2>
386: <P>
387: Which <A HREF="HTNet.html">Net object</A> can read and/or write? When doing
388: pipelining, we essentially serialize requests and therefore we must keep
389: track of who can read and who can write.
2.8 frystyk 390: <H3>
2.12 frystyk 391: Get the Next Net object for Reading and Writing
2.8 frystyk 392: </H3>
393: <PRE>
394: extern HTNet * HTHost_firstNet (HTHost * host);
395: extern HTNet * HTHost_getReadNet (HTHost * host);
396: extern HTNet * HTHost_getWriteNet (HTHost * host);
397: </PRE>
398: <H3>
399: Get input and output Streams for this Host
400: </H3>
401: <PRE>
402: extern HTInputStream * HTHost_getInput (HTHost * host, HTTransport * transport,
403: void * param, int mode);
404:
405: extern HTOutputStream * HTHost_getOutput (HTHost * host, HTTransport * tp,
406: void * param, int mode);
407: </PRE>
408: <H3>
2.24 frystyk 409: Reading Data and Keeping Track of how Much
2.8 frystyk 410: </H3>
2.24 frystyk 411: <P>
412: Because of the push streams, the streams must keep track of how much data
413: actually was consumed by that stream.
2.8 frystyk 414: <PRE>
415: extern int HTHost_read(HTHost * host, HTNet * net);
2.24 frystyk 416:
2.8 frystyk 417: extern BOOL HTHost_setConsumed(HTHost * host, size_t bytes);
2.24 frystyk 418: extern BOOL HTHost_setRemainingRead(HTHost * host, size_t remainaing);
419: extern size_t HTHost_remainingRead (HTHost * host);
2.3 frystyk 420: </PRE>
2.12 frystyk 421: <H2>
2.24 frystyk 422: <A NAME="Pipeline">Pipelining Requests</A>
2.23 frystyk 423: </H2>
424: <P>
2.24 frystyk 425: When possible, we try to pipeline requests onto the same connection as this
426: saves a lot of time and leads to much higher throughput.
427: <H3>
428: How many Requests can we Pipeline onto the same Connection?
429: </H3>
430: <P>
431: Use these functions to set the max number of requests that can be pipelined
432: at any one time on a single, persistent connection. The higher the number,
433: the more we have to recover if the server closes the connection prematurely.
434: The default is about 50 requests which is enough to fill most links.
435: <PRE>
436: extern BOOL HTHost_setMaxPipelinedRequests (int max);
437: extern int HTHost_maxPipelinedRequests (void);
438: </PRE>
2.23 frystyk 439: <H3>
2.27 frystyk 440: How many Pending and Outstanding Net objects are there on a Host?
441: </H3>
442: <P>
443: You can query how many Het objects (essentially requests) are outstanding
444: or pending on a host object using these methods:
445: <PRE>
446: extern int HTHost_numberOfOutstandingNetObjects (HTHost * host);
447: extern int HTHost_numberOfPendingNetObjects (HTHost * host);
448: </PRE>
449: <H3>
2.23 frystyk 450: Pipeline Recovery
451: </H3>
452: <P>
2.24 frystyk 453: Pipelines normally run by themselves (requests are issued and responses
454: recieved). However, it may be necessry to either prematurely abort a pipeline
455: or to recover a broken pipeline due to communication problems with the server.
2.23 frystyk 456: In case a pipeline is broken then we have to recover it and start again.
457: This is handled automatically by the host object, so you do not have to call
458: this one explicitly.
459: <PRE>
460: extern BOOL HTHost_recoverPipe (HTHost * host);
461: extern BOOL HTHost_doRecover (HTHost * host);
462: </PRE>
463: <H3>
464: Kill a Pipeline
465: </H3>
466: <P>
467: Call this function to terminate all requests (pending as well as active)
468: registered with a host object. This is typically the function that handles
469: timeout, abort (user hits the red button, etc). You can also use the
470: <A HREF="HTNet.html">HTNet object kill method</A> which in terms call this
471: function.
472: <PRE>extern BOOL HTHost_killPipe (HTHost * host);
473: </PRE>
474: <H2>
2.24 frystyk 475: <A NAME="Event">Event Management</A>
476: </H2>
477: <P>
478: These functions are used to register and unregister events (read, write,
479: etc.) so that the host object knows about it.
480: <PRE>
481: extern int HTHost_register(HTHost * host, HTNet * net, HTEventType type);
482: extern int HTHost_unregister(HTHost * host, HTNet * net, HTEventType type);
483: extern int HTHost_tickleFirstNet(HTHost * host, HTEventType type);
484:
485: extern SockA * HTHost_getSockAddr(HTHost * host);
486: </PRE>
487: <H3>
488: <A NAME="RequestTimeout">Request Timeouts</A>
489: </H3>
490: <P>
491: Events can be assigned a timeout which causes the event to be triggered if
492: the timeout happens before other action is available on the socket. You can
493: assign a global timeout for all host object using the following methods.
494: The default is no timeout.
495: <PRE>
496: extern int HTHost_eventTimeout (void);
497: extern void HTHost_setEventTimeout (int millis);
498: </PRE>
499: <H2>
500: <A NAME="Delayed">Delayed Flush Timer</A>
501: </H2>
502: <P>
503: These methods can control how long we want to wait for a flush on a pipelined
504: channel. The default is 30ms which is OK in most situations.
505: <PRE>
506: extern BOOL HTHost_setWriteDelay (HTHost * host, ms_t delay);
507: extern ms_t HTHost_writeDelay (HTHost * host);
508: extern int HTHost_findWriteDelay(HTHost * host, ms_t lastFlushTime, int buffSize);
509: </PRE>
510: <P>
511: It is also possible to explicitly require a flush using the following method.
512: This can also be set directly in the <A HREF="HTReq.html">request object</A>
513: for a single request.
514: <PRE>
515: extern int HTHost_forceFlush(HTHost * host);
516: </PRE>
517: <P>
518: You can also set the <EM>global</EM> value so that all new host objects (and
519: therefore all new requests) will inherit this value instead of setting it
520: individually.
521: <PRE>extern BOOL HTHost_setDefaultWriteDelay (ms_t delay);
522: extern ms_t HTHost_defaultWriteDelay (void);
523: </PRE>
524: <H2>
2.12 frystyk 525: Multi homed Host Management
526: </H2>
527: <P>
2.24 frystyk 528: We keep track of hosts with multiple IP addresses - socalled <I>multi-homed
529: hosts</I>. This is used for two things: finding the fastest IP address of
530: that host and as a backup if one or more of the hosts are down. This is handled
531: in connection with the <A HREF="HTDNS.html">DNS manager</A>
2.1 frystyk 532: <PRE>
2.12 frystyk 533: extern BOOL HTHost_setHome (HTHost * host, int home);
534: extern int HTHost_home (HTHost * host);
2.13 frystyk 535:
536: extern BOOL HTHost_setRetry (HTHost * host, int retry);
537: extern int HTHost_retry (HTHost * host);
538: extern BOOL HTHost_decreaseRetry (HTHost * host);
2.19 kahan 539: </PRE>
2.23 frystyk 540: <H2>
541: Notify Request that it has become Active
542: </H2>
2.19 kahan 543: <P>
2.24 frystyk 544: A new callback plugged to the activation of a request which allows an application
545: to know when a request has become active.
2.19 kahan 546: <PRE>
2.24 frystyk 547: typedef int HTHost_ActivateRequestCallback (HTRequest * request);
548: extern void HTHost_setActivateRequestCallback
549: (HTHost_ActivateRequestCallback * cbf);
2.19 kahan 550: </PRE>
551: <P>
2.12 frystyk 552: <PRE>
2.30 ! vbancrof 553: #ifdef __cplusplus
! 554: }
! 555: #endif
! 556:
2.1 frystyk 557: #endif /* HTHOST_H */
558: </PRE>
2.3 frystyk 559: <P>
560: <HR>
2.1 frystyk 561: <ADDRESS>
2.30 ! vbancrof 562: @(#) $Id: HTHost.html,v 2.29 1999/07/07 15:43:28 frystyk Exp $
2.1 frystyk 563: </ADDRESS>
2.3 frystyk 564: </BODY></HTML>
Webmaster
![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to HTHost.html CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Public] / libwww / Library / src