Annotation of libwww/Library/src/HTReq.html, revision 2.63
2.1 frystyk 1: <HTML>
2: <HEAD>
2.40 frystyk 3: <!-- Changed by: Henrik Frystyk Nielsen, 15-Jul-1996 -->
2.51 frystyk 4: <TITLE>W3C Sample Code Library libwww Request Class</TITLE>
2.1 frystyk 5: </HEAD>
6: <BODY>
2.30 frystyk 7: <H1>
8: The Request Class
9: </H1>
2.1 frystyk 10: <PRE>
11: /*
12: ** (c) COPYRIGHT MIT 1995.
13: ** Please first read the full copyright statement in the file COPYRIGH.
14: */
15: </PRE>
16: <P>
2.31 frystyk 17: Libwww is based on a request/response paradigm and the Request class defines
18: "<I>an operation to be performed on a URL</I>". The request object is the
19: main entry point for an application to issue a request to the Library - all
20: operations on a URL <I>must</I> use a Request object. The request object
21: is application independent in that both servers and clients use the same
22: Request class. Examples of requests passed to the Library are a client
23: application issuing a <B>GET</B> request on a HTTP URL, or a server issuing
24: a load on a local file URL. The only difference is that the client gets the
25: input from a user whereas the server gets the input via the network.
26: <P>
27: A request object is created with a default set of parameters which are applicable
28: for many URL requests but the class defines a huge set of methods that an
29: be used to customize a request for a particular purpose. Example of things
30: that you can define is natural language, media types, what RFC 822 headers
31: to use, whether the request should be refreshed from cache etc. Scroll down
32: and see the set of parameters you can tune.
33: <P>
34: A request object is registered in the library by issuing an operation on
35: a URL - for example <B>PUT</B>, <B>POST</B>, or <B>DELETE</B>. You can find
36: many higher level "request issuing functions" in the
37: <A HREF="HTAccess.html">Access module</A> - the methods defined by the Request
38: class itself are very low level but can of course be used directly if needed.
39: <P>
40: Whereas the lifetime of the URL (in form of an anchor) often is very long
41: (for example as long as the application is running), the lifetime of a request
42: is limited to the time it takes to service the request. The core does not
43: automatically delete any request object created by the application - it is
44: for the application to do. In many cases a request object can be deleted
45: when any of the <A HREF="HTNet.html#callout">termination callback functions</A>
46: are called but the application may keep request objects around longer than
47: that
48: <P>
49: The Library can accept an unlimited number of simultaneous requests passed
50: by the application. One of the main functions of the Library core is to handle
51: any number of ongoing requests in an intelligent manner by limiting the number
52: of active request to the fit the available resources as defined by the
53: application. This is described in more detail in the <A HREF="HTNet.html">HTNet
54: module</A>.
2.30 frystyk 55: <P>
56: This module is implemented by <A HREF="HTReqMan.c">HTReqMan.c</A>, and it
2.56 frystyk 57: is a part of the <A HREF="http://www.w3.org/Library/"> W3C Sample Code
2.30 frystyk 58: Library</A>.
2.1 frystyk 59: <PRE>
60: #ifndef HTREQ_H
61: #define HTREQ_H
62:
2.20 frystyk 63: typedef long HTRequestID;
2.1 frystyk 64: typedef struct _HTRequest HTRequest;
65:
2.29 frystyk 66: #include "HTEvent.h"
2.1 frystyk 67: #include "HTList.h"
2.23 frystyk 68: #include "HTAssoc.h"
2.1 frystyk 69: #include "HTFormat.h"
70: #include "HTStream.h"
2.10 frystyk 71: #include "HTError.h"
2.1 frystyk 72: #include "HTNet.h"
2.31 frystyk 73: #include "HTUser.h"
2.47 frystyk 74: #include "HTResponse.h"
2.1 frystyk 75: </PRE>
2.30 frystyk 76: <H2>
2.31 frystyk 77: Issuing a Request
2.30 frystyk 78: </H2>
79: <P>
2.31 frystyk 80: This is the "<I>basic request issue method</I>" provided by the Request class.
81: This is a very low level API as the caller must have set up the request object
82: before passing it to the Library. You can find many higher level issuing
83: functions in the <A HREF="HTAccess.html">HTAccess module</A>. If you like,
84: you can of course use this directly!
2.1 frystyk 85: <PRE>
2.9 frystyk 86: extern BOOL HTLoad (HTRequest * request, BOOL recursive);
2.1 frystyk 87: </PRE>
2.30 frystyk 88: <H2>
2.33 frystyk 89: Killing a Request
90: </H2>
91: <P>
92: This function kills this particular request, see <A HREF="HTNet.html">HTNet
2.61 frystyk 93: module</A> for a function that kills them all. If you know that you are
2.62 kahan 94: pipelining requests (typically the case for GUI browsers, robots etc.) then it
95: is often not enough to just kill a single request as the whole pipeline gets
96: affected. Therefore, in that case you MUST call the <TT><A
97: HREF="HTHost.html#Pipeline">HTHost_killPipe</A></TT> function instead,
98:
2.33 frystyk 99: <PRE>
100: extern BOOL HTRequest_kill(HTRequest * request);
101: </PRE>
2.61 frystyk 102: <P>
103: Note that you can get to the HTHost object via the <A HREF="HTNet.html">HTNet
104: object</A> which you can <A HREF="#HTNet">get by calling
105: HTRequest_net(...)</A>.
2.33 frystyk 106: <H2>
2.30 frystyk 107: Creation and Deletion Methods
108: </H2>
109: <P>
110: The request object is intended to live as long as the request is still active,
2.31 frystyk 111: but can be deleted as soon as it has terminated, for example in one of the
2.30 frystyk 112: request termination callback functions as described in the
113: <A HREF="HTNet.html">Net Manager</A>. Only the anchor object stays around
114: after the request itself is terminated.
115: <H3>
116: Create new Object
117: </H3>
118: <P>
119: Creates a new request object with a default set of options -- in most cases
120: it will need some information added which can be done using the methods in
121: this module, but it will work as is for a simple request.
2.1 frystyk 122: <PRE>
123: extern HTRequest * HTRequest_new (void);
2.22 frystyk 124: </PRE>
2.30 frystyk 125: <H3>
126: Clear a Request Object
127: </H3>
128: <P>
129: Clears all protocol specific information so that the request object can be
130: used for another request. It should be use with care as application specific
131: information is <B>not</B> re-initialized. Returns YES if OK, else NO.
2.22 frystyk 132: <PRE>
133: extern BOOL HTRequest_clear (HTRequest * me);
2.1 frystyk 134: </PRE>
2.30 frystyk 135: <H3>
136: Create a duplicate
137: </H3>
138: <P>
139: Creates a new HTRequest object as a duplicate of the src request. Returns
140: YES if OK, else NO
2.14 frystyk 141: <PRE>
142: extern HTRequest * HTRequest_dup (HTRequest * src);
143: </PRE>
2.30 frystyk 144: <H4>
145: Create a duplicate for Internal use
146: </H4>
147: <P>
148: Creates a new HTRequest object as a duplicate of the src request. The difference
149: to the HTRequest_dup function is that we don't copy the error_stack and other
150: information that the application keeps in its copy of the request object.
151: Otherwise it will be freed multiple times. Returns YES if OK, else NO
2.19 frystyk 152: <PRE>
153: extern HTRequest * HTRequest_dupInternal (HTRequest * src);
154: </PRE>
2.30 frystyk 155: <H3>
156: Delete Object
157: </H3>
158: <P>
2.1 frystyk 159: This function deletes the object and cleans up the memory.
160: <PRE>
161: extern void HTRequest_delete (HTRequest * request);
162: </PRE>
2.30 frystyk 163: <H2>
2.47 frystyk 164: Date and Time Stamp when Request was Issued
2.31 frystyk 165: </H2>
166: <P>
2.47 frystyk 167: The start time when the request was issued may be of value to the cache
168: validation mechanism as described by the HTTP/1.1 specification. The value
169: is automatically set when creating the request headers and sending off the
170: request. The time is a local time.
171: <PRE>
172: extern time_t HTRequest_date (HTRequest * request);
173: extern BOOL HTRequest_setDate (HTRequest * request, time_t date);
2.31 frystyk 174: </PRE>
175: <H2>
2.30 frystyk 176: Set the Method for the Request
177: </H2>
178: <P>
179: The Method is the operation to be executed on the requested object. The default
180: set if the set of operations defined by the HTTP protocol, that is "GET",
181: "HEAD", "PUT", "POST", "LINK", "UNLINK", and "DELETE" but many of these can
182: be used in other protocols as well. The important thing is to think of the
183: requested element as an object on which you want to perform an operation.
184: Then it is for the specific protocol implementation to try and carry this
185: operation out. However, not all operations can be implemented (or make sense)
186: in all protocols.
187: <P>
188: Methods are handled by the <A HREF="HTMethod.html">Method Module</A>, and
189: the default value is "GET".
2.1 frystyk 190: <PRE>
191: extern void HTRequest_setMethod (HTRequest *request, HTMethod method);
192: extern HTMethod HTRequest_method (HTRequest *request);
193: </PRE>
2.30 frystyk 194: <H2>
2.47 frystyk 195: Priority Management
2.45 frystyk 196: </H2>
197: <P>
2.47 frystyk 198: The request can be assigned an initial priority which then gets inherited
199: by all HTNet objects and other requests objects created as a result of this
200: one. You can also assign a separate priority to an indicidual HTNet object
201: by using the methods in the <A HREF="HTNet.html">Net manager</A>.
2.46 frystyk 202: <PRE>
2.47 frystyk 203: extern HTPriority HTRequest_priority (HTRequest * request);
204: extern BOOL HTRequest_setPriority (HTRequest * request, HTPriority priority);
2.45 frystyk 205: </PRE>
206: <H2>
2.50 frystyk 207: Pipelining Managament
208: </H2>
209: <P>
210: Libwww supports HTTP/1.1 pipelining which greatly optimizes HTTP's behavior
211: over TCP. libwww also tries very hard to minimize the number of TCP packets
212: sent over the network. This is done by buffering outgoing requests until
213: either a minimum amount of data has been collected or a timeout causes a
214: flush to happen. The application can override the output buffering by explicit
215: request a request object to be flushed.
216: <PRE>
217: extern BOOL HTRequest_setFlush (HTRequest * me, BOOL mode);
218: extern BOOL HTRequest_flush (HTRequest * me);
219: </PRE>
220: <H2>
2.47 frystyk 221: Binding to a User Profile
2.30 frystyk 222: </H2>
223: <P>
2.47 frystyk 224: Each request is associated with a <A HREF="HTUser.html">User profile</A>
225: which contains information about the local host name, email address of the
226: user, news server etc. A request object is created with a default "generic
227: user" but can be assigned a specific user at any time.
2.1 frystyk 228: <PRE>
2.47 frystyk 229: extern BOOL HTRequest_setUserProfile (HTRequest * request, HTUserProfile * up);
230: extern HTUserProfile * HTRequest_userProfile (HTRequest * request);
2.45 frystyk 231: </PRE>
2.30 frystyk 232: <H2>
2.62 kahan 233: <A NAME="HTNet">Binding to a Net Object</A>
2.30 frystyk 234: </H2>
235: <P>
2.47 frystyk 236: If a request is actually going on the net then the <A HREF="HTNet.html">Net
237: Manager</A> is contacted to handle the request. The Net manager creates a
238: HTNEt object and links it to the Request object. You can get to the HTNet
239: object using the following functions.
2.19 frystyk 240: <PRE>
2.47 frystyk 241: extern HTNet * HTRequest_net (HTRequest * request);
242: extern BOOL HTRequest_setNet (HTRequest * request, HTNet * net);
2.19 frystyk 243: </PRE>
2.61 frystyk 244: <P>
245: Note that you can go from the HTNet object to the
246: <A HREF="HTHost.html">HTHost</A> object by calling <TT>HTNet_host(...)</TT>.
2.30 frystyk 247: <H2>
2.47 frystyk 248: Binding to a Response Object
2.30 frystyk 249: </H2>
250: <P>
2.47 frystyk 251: If a request is actually going on the net and we are getting a response back
252: then we also create a HTResponse object and bind it to the request object.
253: Once we know what to do with the response, we may transfer the information
254: to the anchor object.
2.38 frystyk 255: <PRE>
2.47 frystyk 256: extern HTResponse * HTRequest_response (HTRequest * request);
257: extern BOOL HTRequest_setResponse (HTRequest * request, HTResponse * response);
2.38 frystyk 258: </PRE>
2.30 frystyk 259: <H2>
2.47 frystyk 260: <A NAME="Error">Error Object</A>
2.44 frystyk 261: </H2>
262: <P>
2.47 frystyk 263: Errors are like almost anything kept in lists and a error list can be associated
264: with a request using the following functions. In order to make life easier,
265: there are also some easy mapping functions to the
266: <A HREF="HTError.html">HTError object</A>, so that you can add an error directly
267: to a request object.
2.44 frystyk 268: <PRE>
2.47 frystyk 269: extern HTList * HTRequest_error (HTRequest * request);
270: extern void HTRequest_setError (HTRequest * request, HTList * list);
2.55 frystyk 271: extern void HTRequest_deleteAllErrors (HTRequest * request);
2.45 frystyk 272: </PRE>
273: <P>
2.47 frystyk 274: These are the cover functions that go directly to the
275: <A HREF="HTError.html">Error Object</A>
2.46 frystyk 276: <PRE>
2.47 frystyk 277: extern BOOL HTRequest_addError (HTRequest * request,
278: HTSeverity severity,
279: BOOL ignore,
280: int element,
281: void * par,
282: unsigned int length,
283: char * where);
284:
285: extern BOOL HTRequest_addSystemError (HTRequest * request,
286: HTSeverity severity,
287: int errornumber,
288: BOOL ignore,
289: char * syscall);
2.46 frystyk 290: </PRE>
291: <H2>
292: Max number of Retrys for a Down Load
293: </H2>
2.30 frystyk 294: <P>
2.1 frystyk 295: Automatic reload can happen in two situations:
296: <UL>
2.30 frystyk 297: <LI>
298: The server sends a redirection response
299: <LI>
300: The document has expired
2.1 frystyk 301: </UL>
2.30 frystyk 302: <P>
303: In order to avoid the Library going into an infinite loop, it is necessary
304: to keep track of the number of automatic reloads. Loops can occur if the
305: server has a reload to the same document or if the server sends back a Expires
306: header which has already expired. The default maximum number of automatic
307: reloads is 6.
2.1 frystyk 308: <PRE>
309: extern BOOL HTRequest_setMaxRetry (int newmax);
310: extern int HTRequest_maxRetry (void);
2.41 frystyk 311:
312: extern int HTRequest_retrys (HTRequest * request);
313: extern BOOL HTRequest_doRetry (HTRequest *request);
2.44 frystyk 314: extern BOOL HTRequest_addRetry (HTRequest * request);
2.62 kahan 315:
316: extern int HTRequest_AAretrys (HTRequest * request);
317: extern BOOL HTRequest_addAARetry (HTRequest * request);
2.1 frystyk 318: </PRE>
2.30 frystyk 319: <H2>
2.43 frystyk 320: Set Max Forwards for TRACE methods
321: </H2>
322: <P>
323: The <CODE>TRACE</CODE> method is used to invoke a remote, application-layer
324: loop-back of the request message. The final recipient of the request SHOULD
325: reflect the message received back to the client as the entity-body of a 200
326: (OK) response. The final recipient is either the origin server or the first
327: proxy or gateway to receive a Max-Forwards value of zero (0) in the request.
328: A <CODE>TRACE</CODE> request <I>MUST NOT</I> include an entity.
329: <PRE>extern BOOL HTRequest_setMaxForwards (HTRequest * request, int maxforwards);
330: extern int HTRequest_maxForwards (HTRequest * request);
331: </PRE>
332: <H2>
2.60 frystyk 333: <A NAME="preemptive">Preemptive or Non-preemptive Access</A>
2.46 frystyk 334: </H2>
335: <P>
2.47 frystyk 336: A access scheme is defined with a default for using either preemptive (blocking
337: I/O) or non-premitve (non-blocking I/O). This is basically a result of the
338: implementation of the protocol module itself. However, if non-blocking I/O
339: is the default then some times it is nice to be able to set the mode to blocking
340: instead. For example when loading the first document (the home page) then
341: blocking can be used instead of non-blocking.
2.46 frystyk 342: <PRE>
2.47 frystyk 343: extern void HTRequest_setPreemptive (HTRequest *request, BOOL mode);
344: extern BOOL HTRequest_preemptive (HTRequest *request);
2.46 frystyk 345: </PRE>
346: <H2>
2.47 frystyk 347: Content Negotiation
2.30 frystyk 348: </H2>
349: <P>
2.47 frystyk 350: When accessing the local file system, the Library is capable of performing
351: content negotioation as described by the HTTP protocol. This is mainly for
352: server applications, but some client applications might also want to use
353: content negotiation when accessing the local file system. This method enables
354: or disables content negotiation - the default value is <EM>ON</EM>.
2.1 frystyk 355: <PRE>
2.47 frystyk 356: extern void HTRequest_setNegotiation (HTRequest *request, BOOL mode);
357: extern BOOL HTRequest_negotiation (HTRequest *request);
2.1 frystyk 358: </PRE>
2.30 frystyk 359: <H2>
2.57 frystyk 360: Request Preconditions
361: </H2>
2.62 kahan 362: Should this request use preconditions when doing a PUT or a POST? These are the
363: if-* header fields that can be used to avoid version conflicts etc. The default is no.
2.57 frystyk 364: <PRE>
365: extern void HTRequest_setPreconditions (HTRequest * me, BOOL mode);
366: extern BOOL HTRequest_preconditions (HTRequest * me);
367: </PRE>
368: <H2>
2.30 frystyk 369: Handling Metainformation (RFC822 Headers)
370: </H2>
371: <P>
372: The Library supports a large set of headers that can be sent along with a
373: request (or a response for that matter). All headers can be either disabled
374: or enabled using bit flags that are defined in the following.
375: <H3>
376: <A NAME="gnhd">General HTTP Header Mask</A>
377: </H3>
378: <P>
379: There are a few header fields which have general applicability for both request
380: and response mesages, but which do not apply to the communication parties
381: or theentity being transferred. This mask enables and disables these headers.
2.54 frystyk 382: If the bit is not turned on they are not sent.
2.1 frystyk 383: <PRE>
384: typedef enum _HTGnHd {
2.45 frystyk 385: HT_G_CC = 0x1,
386: HT_G_CONNECTION = 0x2,
387: HT_G_DATE = 0x4,
388: HT_G_PRAGMA_NO_CACHE= 0x8,
389: HT_G_FORWARDED = 0x10,
390: HT_G_MESSAGE_ID = 0x20,
2.53 frystyk 391: HT_G_MIME = 0x40,
2.54 frystyk 392: HT_G_TRAILER = 0x80,
393: HT_G_TRANSFER = 0x100
2.1 frystyk 394: } HTGnHd;
395:
2.54 frystyk 396: #define DEFAULT_GENERAL_HEADERS \
397: HT_G_CONNECTION + HT_G_CC + HT_G_TRANSFER + HT_G_TRAILER
2.1 frystyk 398:
399: extern void HTRequest_setGnHd (HTRequest *request, HTGnHd gnhd);
400: extern void HTRequest_addGnHd (HTRequest *request, HTGnHd gnhd);
401: extern HTGnHd HTRequest_gnHd (HTRequest *request);
402: </PRE>
2.30 frystyk 403: <H3>
404: <A NAME="rqhd">Request Headers</A>
405: </H3>
406: <P>
407: The request header fields allow the client to pass additional information
408: about the request (and about the client itself) to the server. All headers
409: are optional but the default value is all request headers if present
410: <EM>except</EM> <CODE>From</CODE> and <CODE>Pragma</CODE>.
2.1 frystyk 411: <PRE>
412: typedef enum _HTRqHd {
2.16 frystyk 413: HT_C_ACCEPT_TYPE = 0x1,
414: HT_C_ACCEPT_CHAR = 0x2,
415: HT_C_ACCEPT_ENC = 0x4,
2.53 frystyk 416: HT_C_ACCEPT_TE = 0x8,
417: HT_C_ACCEPT_LAN = 0x10,
418: HT_C_AUTH = 0x20, /* Includes proxy authentication */
419: HT_C_EXPECT = 0x40,
420: HT_C_FROM = 0x80,
421: HT_C_HOST = 0x100,
422: HT_C_IMS = 0x200,
423: HT_C_IF_MATCH = 0x400,
2.63 ! frystyk 424: HT_C_IF_MATCH_ALL = 0x800,
! 425: HT_C_IF_NONE_MATCH = 0x1000,
! 426: HT_C_IF_NONE_MATCH_ALL=0x2000,
! 427: HT_C_IF_RANGE = 0x4000,
! 428: HT_C_IF_UNMOD_SINCE = 0x8000,
! 429: HT_C_MAX_FORWARDS = 0x10000,
! 430: HT_C_RANGE = 0x20000,
! 431: HT_C_REFERER = 0x40000,
! 432: HT_C_USER_AGENT = 0x80000
2.1 frystyk 433: } HTRqHd;
434:
2.16 frystyk 435: #define DEFAULT_REQUEST_HEADERS \
2.37 frystyk 436: HT_C_ACCEPT_TYPE + HT_C_ACCEPT_CHAR + \
2.53 frystyk 437: HT_C_ACCEPT_ENC + HT_C_ACCEPT_TE + HT_C_ACCEPT_LAN + HT_C_AUTH + \
438: HT_C_EXPECT + HT_C_HOST + HT_C_REFERER + HT_C_USER_AGENT
2.1 frystyk 439:
440: extern void HTRequest_setRqHd (HTRequest *request, HTRqHd rqhd);
441: extern void HTRequest_addRqHd (HTRequest *request, HTRqHd rqhd);
442: extern HTRqHd HTRequest_rqHd (HTRequest *request);
443: </PRE>
2.30 frystyk 444: <H3>
445: <A NAME="rshd">Response Headers</A>
446: </H3>
447: <P>
448: The response header fields allow the server to pass additional information
449: about the response (and about the server itself) to the client. All headers
450: are optional.
2.16 frystyk 451: <PRE>
452: typedef enum _HTRsHd {
2.37 frystyk 453: HT_S_AGE = 0x1,
454: HT_S_LOCATION = 0x2,
455: HT_S_PROXY_AUTH = 0x4,
456: HT_S_PUBLIC = 0x8,
457: HT_S_RETRY_AFTER = 0x10,
458: HT_S_SERVER = 0x20,
459: HT_S_VARY = 0x40,
460: HT_S_WARNING = 0x80,
2.53 frystyk 461: HT_S_WWW_AUTH = 0x100,
462: HT_S_TRAILER = 0x200
2.16 frystyk 463: } HTRsHd;
464:
465: #define DEFAULT_RESPONSE_HEADERS HT_S_SERVER
466:
467: extern void HTRequest_setRsHd (HTRequest * request, HTRsHd rshd);
468: extern void HTRequest_addRsHd (HTRequest * request, HTRsHd rshd);
2.17 frystyk 469: extern HTRsHd HTRequest_rsHd (HTRequest * request);
2.16 frystyk 470: </PRE>
2.30 frystyk 471: <H3>
472: <A NAME="enhd">Entity Header Mask</A>
473: </H3>
474: <P>
475: The entity headers contain information about the object sent in the HTTP
476: transaction. See the <A HREF="HTAnchor.html">Anchor module</A>, for the storage
477: of entity headers. This flag defines which headers are to be sent in a request
478: together with an entity body. All headers are optional but the default value
479: is <EM>ALL ENTITY HEADERS IF PRESENT</EM>
2.1 frystyk 480: <PRE>
481: typedef enum _HTEnHd {
2.37 frystyk 482: HT_E_ALLOW = 0x1,
483: HT_E_CONTENT_BASE = 0x2,
484: HT_E_CONTENT_ENCODING = 0x4,
485: HT_E_CONTENT_LANGUAGE = 0x8,
486: HT_E_CONTENT_LENGTH = 0x10,
487: HT_E_CONTENT_LOCATION = 0x20,
488: HT_E_CONTENT_MD5 = 0x40,
489: HT_E_CONTENT_RANGE = 0x80,
490: HT_E_CTE = 0x100, /* Content-Transfer-Encoding */
491: HT_E_CONTENT_TYPE = 0x200,
492: HT_E_DERIVED_FROM = 0x400,
493: HT_E_ETAG = 0x800,
494: HT_E_EXPIRES = 0x1000,
495: HT_E_LAST_MODIFIED = 0x2000,
496: HT_E_LINK = 0x4000,
497: HT_E_TITLE = 0x8000,
498: HT_E_URI = 0x10000,
499: HT_E_VERSION = 0x20000
2.1 frystyk 500: } HTEnHd;
501:
502: #define DEFAULT_ENTITY_HEADERS 0xFFFF /* all */
503:
504: extern void HTRequest_setEnHd (HTRequest *request, HTEnHd enhd);
505: extern void HTRequest_addEnHd (HTRequest *request, HTEnHd enhd);
506: extern HTEnHd HTRequest_enHd (HTRequest *request);
507: </PRE>
2.47 frystyk 508: <H2>
509: Local MIME header Parsers
510: </H2>
2.37 frystyk 511: <P>
512: MIMEParsers get their own type which is optimized for static and regex parser
513: strings.
2.34 eric 514: <PRE>
515: typedef struct _HTMIMEParseSet HTMIMEParseSet;
516: extern void HTRequest_setMIMEParseSet (HTRequest *request,
517: HTMIMEParseSet * parseSet, BOOL local);
518: extern HTMIMEParseSet * HTRequest_MIMEParseSet (HTRequest *request,
519: BOOL * pLocal);
520: </PRE>
2.30 frystyk 521: <H2>
2.48 frystyk 522: <A NAME="Accept">Accept Headers</A>
2.47 frystyk 523: </H2>
524: <P>
525: The Accept family of headers is an important part of HTTP handling the format
526: negotiation. The Library supports both a global set of accept headers that
527: are used in <EM>all</EM> HTTP requests and a local set of accept headers
528: that are used in specific requests only. The global ones are defined in the
529: <A HREF="HTFormat.html">Format Manager</A>.
530: <P>
531: Each request can have its local set of accept headers that either are added
532: to the global set or replaces the global set of accept headers. Non of the
533: headers <EM>have</EM> to be set. If the global set is sufficient for all
534: requests then this us perfectly fine. If the parameter "override" is set
535: then only local accept headers are used, else <EM>both</EM> local and global
536: headers are used.
537: <H3>
538: Content Types
539: </H3>
540: <P>
541: The <EM>local</EM> list of specific conversions which the format manager
542: can do in order to fulfill the request. It typically points to a list set
543: up on initialisation time for example by <A HREF="HTInit.html">HTInit()</A>.
544: There is also a <A HREF="HTFormat.html#z17"><EM>global</EM></A> list of
545: conversions which contains a generic set of possible conversions.
546: <PRE>
547: extern void HTRequest_setConversion (HTRequest *request, HTList *type, BOOL override);
548: extern HTList * HTRequest_conversion (HTRequest *request);
549: </PRE>
550: <H3>
551: Content Encodings
552: </H3>
553: <P>
554: The list of encodings acceptable in the output stream.
555: <PRE>
556: extern void HTRequest_setEncoding (HTRequest *request, HTList *enc, BOOL override);
557: extern HTList * HTRequest_encoding (HTRequest *request);
558: </PRE>
559: <H3>
2.53 frystyk 560: Transfer Encodings
2.47 frystyk 561: </H3>
562: <P>
563: The list of transfer encodings acceptable in the output stream.
564: <PRE>
2.53 frystyk 565: extern void HTRequest_setTransfer (HTRequest *request, HTList *te, BOOL override);
2.47 frystyk 566: extern HTList * HTRequest_transfer (HTRequest *request);
567: </PRE>
568: <H3>
569: Content Languages
570: </H3>
571: <P>
572: The list of (human) language values acceptable in the response. The default
573: is all languages.
574: <PRE>
575: extern void HTRequest_setLanguage (HTRequest *request, HTList *lang, BOOL override);
576: extern HTList * HTRequest_language (HTRequest *request);
577: </PRE>
578: <H3>
579: Content Charsets
580: </H3>
581: <P>
582: The list of charsets accepted by the application
583: <PRE>
584: extern void HTRequest_setCharset (HTRequest *request, HTList *charset, BOOL override);
585: extern HTList * HTRequest_charset (HTRequest *request);
586: </PRE>
587: <H2>
588: HTTP Cache Validation and Cache Control
589: </H2>
590: <P>
591: The Library has two concepts of caching: in memory and on file. When loading
592: a document, this flag can be set in order to define who can give a response
593: to the request. The mempory buffer is considered to be equivalent to a history
594: buffer. That is, it doesn't not follow the same expiration mechanism that
595: is characteristic for a persistent file cache.
596: <P>
597: You can also set the cache to run in disconnected mode - see the
598: <A HREF="HTCache.html">Cache manager</A> for more details on how to do this.
599: <PRE>
600: typedef enum _HTReload {
601: HT_CACHE_OK = 0x0, /* Use any version available */
602: HT_CACHE_FLUSH_MEM = 0x1, /* Reload from file cache or network */
603: HT_CACHE_VALIDATE = 0x2, /* Validate cache entry */
604: HT_CACHE_END_VALIDATE = 0x4, /* End to end validation */
605: HT_CACHE_RANGE_VALIDATE = 0x8,
2.52 frystyk 606: HT_CACHE_FLUSH = 0x10, /* Force full reload */
607: HT_CACHE_ERROR = 0x20 /* An error occurred in the cache */
2.47 frystyk 608: } HTReload;
609:
610: extern void HTRequest_setReloadMode (HTRequest *request, HTReload mode);
611: extern HTReload HTRequest_reloadMode (HTRequest *request);
612: </PRE>
613: <H3>
614: HTTP Cache Control Directives
615: </H3>
616: <P>
617: The cache control directives are all part of the cache control header and
618: control the behavior of any intermediate cache between the user agent and
619: the origin server. This association list is a list of the connection control
620: directives that are to be sent as part of the <CODE>Cache-Control</CODE>
621: header.
622: <PRE>
623: extern BOOL HTRequest_addCacheControl (HTRequest * request,
624: char * token, char *value);
625: extern BOOL HTRequest_deleteCacheControlAll (HTRequest * request);
626: extern HTAssocList * HTRequest_cacheControl (HTRequest * request);
627: </PRE>
2.62 kahan 628:
2.53 frystyk 629: <H3>
630: HTTP Expect Directives
631: </H3>
2.62 kahan 632:
633: The Expect request-header field is used to indicate that particular
634: server behaviors are required by the client. A server that does not
635: understand or is unable to comply with any of the expectation values in
636: the Expect field of a request MUST respond with appropriate error
637: status.
638:
2.53 frystyk 639: <PRE>
640: extern BOOL HTRequest_addExpect (HTRequest * me,
641: char * token, char * value);
642: extern BOOL HTRequest_deleteExpect (HTRequest * me);
643: extern HTAssocList * HTRequest_expect (HTRequest * me);
644: </PRE>
2.62 kahan 645:
2.47 frystyk 646: <H3>
647: Partial Requests and Range Retrievals
648: </H3>
649: <P>
650: Libwww can issue range requests in case we have already obtained a part of
651: the entity body. Since all HTTP entities are represented in HTTP messages
652: as sequences of bytes, the concept of a byte range is meaningful for any
653: HTTP entity. (However, not all clients and servers need to support byte-range
654: operations.) Byte range specifications in HTTP apply to the sequence of bytes
655: in the entity-body (not necessarily the same as the message-body). A byte
656: range operation may specify a single range of bytes, or a set of ranges within
657: a single entity.
658: <PRE>
659: extern BOOL HTRequest_addRange (HTRequest * request,
660: char * unit, char * range);
661: extern BOOL HTRequest_deleteRangeAll (HTRequest * request);
662: extern HTAssocList * HTRequest_range (HTRequest * request);
663: </PRE>
664: <H2>
665: HTTP Connection Control Request Directives
666: </H2>
667: <P>
668: The connection control directives are all part of the connection header and
669: control the behavior of this connection. This association list is a list
670: of the connection control directives that are to be sent as part of the
671: <CODE>Connection</CODE> header.
672: <PRE>
673: extern BOOL HTRequest_addConnection (HTRequest * request,
674: char * token, char * value);
675: extern BOOL HTRequest_deleteConnection (HTRequest * request);
676: extern HTAssocList * HTRequest_connection (HTRequest * request);
677: </PRE>
678: <H2>
679: <A NAME="Access">HTTP Access Authentication Credentials</A>
680: </H2>
681: <P>
682: When a access denied response is returned to the Library, for example from
683: a remote HTTP server, this code is passed back to the application. The
684: application can then decide whether a new request should be established or
685: not. These two methods return the authentication information required to
686: issue a new request, that is the new anchor and any list of keywords associated
687: with this anchor.
688: <PRE>
689: extern BOOL HTRequest_addCredentials (HTRequest * request,
690: char * token, char * value);
691: extern BOOL HTRequest_deleteCredentialsAll (HTRequest * request);
692: extern HTAssocList * HTRequest_credentials (HTRequest * request);
693: </PRE>
694: <H3>
695: Realms
696: </H3>
2.59 frystyk 697: The realm is normally set and used by the authentication filters.
2.62 kahan 698:
2.47 frystyk 699: <PRE>
700: extern BOOL HTRequest_setRealm (HTRequest * request, char * realm);
701: extern const char * HTRequest_realm (HTRequest * request);
2.59 frystyk 702: extern BOOL HTRequest_deleteRealm (HTRequest * me);
2.47 frystyk 703: </PRE>
704: <H2>
705: HTTP Extensions (PEP)
706: </H2>
707: <P>
708: HTTP can be extended in several ways but traditionally it has been by using
709: new headers. Here we present a new idea which provides a framework for describing
710: extensions and their scope. This is only an idea an may be modified later!
711: The implementation of the extensions can be found in the
712: <A HREF="HTPEP.html">PEP module</A>
713: <H3>
714: Protocol
715: </H3>
716: <P>
717: This association list is a list of the extension directives that are to be
718: sent as part of the request.
719: <PRE>
720: extern BOOL HTRequest_addProtocol (HTRequest * request,
721: char * token, char * value);
722: extern BOOL HTRequest_deleteProtocolAll (HTRequest * request);
723: extern HTAssocList * HTRequest_Protocol (HTRequest * request);
724: </PRE>
725: <H3>
726: Protocol Info
727: </H3>
728: <P>
729: This association list is a list of the extension directives that are to be
730: sent as part of the request.
731: <PRE>
732: extern BOOL HTRequest_addProtocolInfo (HTRequest * request,
733: char * token, char * value);
734: extern BOOL HTRequest_deleteProtocolInfoAll (HTRequest * request);
735: extern HTAssocList * HTRequest_ProtocolInfo (HTRequest * request);
736: </PRE>
737: <H3>
738: Protocol Request
739: </H3>
740: <P>
741: This association list is a list of the extension directives that are to be
742: sent as part of the request.
743: <PRE>
744: extern BOOL HTRequest_addProtocolRequest (HTRequest * request,
745: char * token, char * value);
746: extern BOOL HTRequest_deleteProtocolRequestAll (HTRequest * request);
747: extern HTAssocList * HTRequest_ProtocolRequest (HTRequest * request);
748: </PRE>
749: <H2>
750: HTTP Referer Field
751: </H2>
752: <P>
753: If this parameter is set then a `Referer: <parent address> can be generated
754: in the request to the server, see
2.62 kahan 755: <A HREF="http://www.w3.org/Protocols/">Referer field in a HTTP
756: Request</A>
2.47 frystyk 757: <PRE>
758: extern void HTRequest_setParent (HTRequest *request, HTParentAnchor *parent);
759: extern HTParentAnchor * HTRequest_parent (HTRequest *request);
760: </PRE>
761: <H2>
762: Extra Headers
763: </H2>
764: <P>
765: Extra header information can be send along with a request using this variable.
766: The text is sent as is so it must be preformatted with
767: <CODE><CRLF></CODE> line terminators. This will get changed at some
768: point so that you can register a header together with a handler in the MIME
769: parser.
770: <PRE>
771: extern void HTRequest_setGenerator (HTRequest *request, HTList *gens,
772: BOOL override);
773: extern HTList * HTRequest_generator (HTRequest *request, BOOL *override);
774: </PRE>
775: <H2>
776: <A NAME="before">BEFORE and AFTER Filters</A>
777: </H2>
778: <P>
779: The request object may have it's own before and after
780: <A HREF="HTFilter.html">filters</A>. These may override or suplement the
781: global set in <A HREF="HTNet.html">HTNet</A>. The request object itself handles
782: the list element, that is this should not be freed bu the caller.
783: <H3>
784: BEFORE Filters
785: </H3>
786: <P>
787: The BEFORE <A HREF="HTFilter.html">filters</A> are called just after the
788: request has been passed to the Library but before any request is issued over
789: the network. A BEFORE can infact stop a request completely from being processed.
790: <H4>
791: Add a local BEFORE Filter
792: </H4>
793: <P>
794: You can add a local <I>BEFORE</I> filter for a single request so that the
795: both the local and global <I>BEFORE</I> filters are called or you can replace
796: the global filters with a local set. Note that the local set can be NULL.
797: This can be used to effectively disable all <I>BEFORE</I> filters without
798: unregistering the global ones.
799: <PRE>
800: extern BOOL HTRequest_addBefore (HTRequest * request, HTNetBefore * filter,
801: const char * tmplate, void * param,
2.48 frystyk 802: HTFilterOrder order, BOOL override);
2.47 frystyk 803: extern HTList * HTRequest_before (HTRequest * request, BOOL * override);
804: </PRE>
805: <H4>
806: Delete a Local BEFORE Filter
807: </H4>
808: <P>
809: You can delete a local BEFORE filter explicitly by passing the filter itself
810: or you can delete all filters which are registered for a certain status code.
811: <PRE>extern BOOL HTRequest_deleteBefore (HTRequest * request, HTNetBefore * filter);
812: extern BOOL HTRequest_deleteBeforeAll (HTRequest * request);
813: </PRE>
814: <H3>
815: AFTER Filters
816: </H3>
817: <P>
818: You can add a local AFTER filter for a single request so that the both the
819: local and global AFTER filters are called or you can replace the global filters
820: with a local set. Note that the local set can be NULL. This can be used to
821: effectively disable all AFTER filters without unregistering the global ones.
822: <P>
823: AFTER filters can be registered to handle a certain set of return values
824: from the protocol modules, for example explicitly to handle redirection,
825: authentication, etc. You can find all the available codes in the HTNet object
826: description.
827: <H4>
828: Add a local AFTER Filter
829: </H4>
830: <PRE>
831: extern BOOL HTRequest_addAfter (HTRequest * request, HTNetAfter * filter,
832: const char * tmplate, void * param,
2.48 frystyk 833: int status, HTFilterOrder order,
834: BOOL override);
2.47 frystyk 835: extern HTList * HTRequest_after (HTRequest * request, BOOL * override);
836: </PRE>
837: <H4>
838: Delete an AFTER Filter
839: </H4>
840: <P>
841: You can delete a local AFTER filter explicitly by passing the filter itself
842: or you can delete all filters which are registered for a certain status code.
843: <PRE>
844: extern BOOL HTRequest_deleteAfter (HTRequest * request, HTNetAfter * filter);
845: extern BOOL HTRequest_deleteAfterStatus (HTRequest * request, int status);
846: extern BOOL HTRequest_deleteAfterAll (HTRequest * request);
847: </PRE>
848: <H2>
849: Sending data to the Network
2.30 frystyk 850: </H2>
851: <P>
2.33 frystyk 852: Multiple Request objects can be connected in order to create a
853: <A HREF="../User/Architecture/PostWeb.html">PostWeb</A> for sending data
854: from one location (source) to another (destination). Request objects are
855: bound together by connecting the output stream of the source with the input
856: stream of the destination requst. The connection can be done directly so
857: that the output from the source is exactly what is sent to the destination
858: or there can be a conversion between the two streams so that we can do
859: conversions on the fly while copying data. This is in fact the way we use
860: for building a proxy server.
861: <P>
2.30 frystyk 862: The Library supports two ways of posting a data object to a remote destination:
863: Input comes from a socket descriptor or from memory. In the case where you
864: want to <EM>copy</EM> a URL, for example from local file system <EM>or</EM>
865: from a remote HTTP server then you must use the
2.33 frystyk 866: <A HREF="../User/Architecture/PostWeb.html">PostWeb design</A>. This model
2.30 frystyk 867: operates by using at least two request objects which gets linked to eachother
2.33 frystyk 868: as part of the PostWeb model. However, if you are posting from memory, we
2.30 frystyk 869: only use <EM>one</EM> request object to perform the operation. In order to
870: do this, the application must register a callback function that can be called
871: when the <A HREF="HTTP.c">HTTP client module</A> is ready for accepting data.
872: be included as part of the body and/or as extra metainformation. In the latter
873: case you need to register a callback function of the following type using
874: the methods provided in the next section.
2.9 frystyk 875: <PRE>
2.21 frystyk 876: typedef int HTPostCallback (HTRequest * request, HTStream * target);
2.33 frystyk 877:
878: extern void HTRequest_setPostCallback (HTRequest * request, HTPostCallback * cbf);
879: extern HTPostCallback * HTRequest_postCallback (HTRequest * request);
2.9 frystyk 880: </PRE>
2.40 frystyk 881: <P>
882: The Entity Anchor is either the anchor directly associated with the Request
883: object or the post anchor associated with the object. The purpose of the
884: entity anchor is if we are to send data to a remote server then we get the
885: metainformation using the entity anchor.
2.39 frystyk 886: <PRE>
887: extern BOOL HTRequest_setEntityAnchor (HTRequest * request, HTParentAnchor * anchor);
888: extern HTParentAnchor * HTRequest_entityAnchor (HTRequest * request);
889: </PRE>
2.30 frystyk 890: <H3>
891: Input Stream
892: </H3>
893: <P>
894: The input stream is to be used to put data <EM>to</EM> the network. Normally
895: each protocol sets the input stream in order to generate the protocol headers
896: while making a request.
2.27 frystyk 897: <PRE>
898: extern void HTRequest_setInputStream (HTRequest * request, HTStream * input);
899: extern HTStream *HTRequest_inputStream (HTRequest * request);
900: </PRE>
2.33 frystyk 901: <H3>
902: Is This Request part of a Post Web?
903: </H3>
904: <P>
905: Check to see if this request object is part of a Post Web.
906: <PRE>
907: extern BOOL HTRequest_isPostWeb (HTRequest * request);
908: </PRE>
909: <H3>
910: Source of a Request
911: </H3>
912: <P>
913: A request may have a source in which is another request object that as output
914: stream has the input stream of this request object.
915: <PRE>
916: extern BOOL HTRequest_setSource (HTRequest * request, HTRequest * source);
917: extern HTRequest * HTRequest_source (HTRequest * request);
918: </PRE>
2.30 frystyk 919: <H2>
920: Streams From Network to Application
921: </H2>
922: <H3>
923: Default Output Stream
924: </H3>
925: <P>
2.1 frystyk 926: The output stream is to be used to put data down to as they come in
2.30 frystyk 927: <B>from</B> the network and back to the application. The default value is
928: <CODE>NULL</CODE> which means that the stream goes to the user (display).
2.1 frystyk 929: <PRE>
930: extern void HTRequest_setOutputStream (HTRequest *request, HTStream *output);
2.6 frystyk 931: extern HTStream *HTRequest_outputStream (HTRequest *request);
2.1 frystyk 932: </PRE>
2.37 frystyk 933: <H3>
934: Has Output Stream been Connected to Channel?
935: </H3>
936: <P>
937: Has output stream been connected to the channel? If not then we must free
938: it explicitly when deleting the request object
939: <PRE>extern void HTRequest_setOutputConnected (HTRequest * request, BOOL mode);
940: extern BOOL HTRequest_outputConnected (HTRequest * request);
941: </PRE>
2.30 frystyk 942: <P>
943: The desired format of the output stream. This can be used to get unconverted
944: data etc. from the library. If <CODE>NULL</CODE>, then
945: <A HREF="HTFormat.html#FormatTypes">WWW_PRESENT</A> is default value.
2.1 frystyk 946: <PRE>
947: extern void HTRequest_setOutputFormat (HTRequest *request, HTFormat format);
2.6 frystyk 948: extern HTFormat HTRequest_outputFormat (HTRequest *request);
2.1 frystyk 949: </PRE>
2.30 frystyk 950: <H3>
951: Debug Stream
952: </H3>
953: <P>
954: All object bodies sent from the server with status codes different from
955: <CODE>200 OK</CODE> will be put down this stream. This can be used for
956: redirecting body information in status codes different from "200 OK" to for
957: example a debug window. If the value is NULL (default) then the stream is
958: not set up.
2.1 frystyk 959: <PRE>
960: extern void HTRequest_setDebugStream (HTRequest *request, HTStream *debug);
2.6 frystyk 961: extern HTStream *HTRequest_debugStream (HTRequest *request);
2.1 frystyk 962: </PRE>
2.30 frystyk 963: <P>
964: The desired format of the error stream. This can be used to get unconverted
965: data etc. from the library. The default value if <CODE>WWW_HTML</CODE> as
966: a character based only has one WWW_PRESENT.
2.1 frystyk 967: <PRE>
968: extern void HTRequest_setDebugFormat (HTRequest *request, HTFormat format);
2.6 frystyk 969: extern HTFormat HTRequest_debugFormat (HTRequest *request);
2.1 frystyk 970: </PRE>
2.33 frystyk 971: <H2>
2.30 frystyk 972: <A NAME="context">Context Swapping</A>
973: </H2>
974: <P>
975: In multi threaded applications it is often required to keep track of the
976: context of a request so that when the Library returns a result of a request,
977: it can be put into the context it was in before the request was first passed
978: to the Library. This call back function allows the application to do this.
2.1 frystyk 979: <PRE>
980: typedef int HTRequestCallback (HTRequest * request, void *param);
981:
982: extern void HTRequest_setCallback (HTRequest *request, HTRequestCallback *cb);
983: extern HTRequestCallback *HTRequest_callback (HTRequest *request);
984: </PRE>
2.30 frystyk 985: <P>
986: The callback function can be passed an arbitrary pointer (the void part)
987: which can describe the context of the current request structure. If such
988: context information is required then it can be set using the following methods:
2.1 frystyk 989: <PRE>
990: extern void HTRequest_setContext (HTRequest *request, void *context);
991: extern void *HTRequest_context (HTRequest *request);
2.20 frystyk 992: </PRE>
2.30 frystyk 993: <H2>
994: Binding to an Anchor Object
995: </H2>
996: <P>
2.33 frystyk 997: Every request object has an <A HREF="HTAnchor.html">anchor</A> associated
998: with it. The anchor normally lives until the application terminates but a
2.47 frystyk 999: request object only lives as long as the request is being serviced. If the
1000: anchor that we have requested is infact a child anchor then we always load
1001: the parent anchor and then after the load jump to the location. A child anchor
1002: is a an anchor which points to a subpart of the document (has a "#" in the
1003: URL).
2.45 frystyk 1004: <PRE>extern void HTRequest_setAnchor (HTRequest *request, HTAnchor *anchor);
2.30 frystyk 1005: extern HTParentAnchor * HTRequest_anchor (HTRequest *request);
2.45 frystyk 1006:
1007: extern HTChildAnchor * HTRequest_childAnchor (HTRequest * request);
2.30 frystyk 1008: </PRE>
1009: <H2>
2.33 frystyk 1010: Should we Issue a full HTTP Request-URI?
2.31 frystyk 1011: </H2>
1012: <P>
1013: In early versions of HTTP, the request sent to the remote server varies whether
1014: we use a proxy or go directly to the origin server. The default value is
2.42 frystyk 1015: <EM>OFF</EM> but we use a full request if we are talking to a proxy server.
2.31 frystyk 1016: <PRE>
2.32 frystyk 1017: extern void HTRequest_setFullURI (HTRequest *request, BOOL mode);
1018: extern BOOL HTRequest_fullURI (HTRequest *request);
2.31 frystyk 1019: </PRE>
1020: <H2>
2.42 frystyk 1021: Proxy URL
1022: </H2>
1023: <P>
1024: In case we are using a proxy for this requst then we can register it together
1025: with the request object. That way we can find the proxy and look for
1026: authentication information, for example in the
2.43 frystyk 1027: <A HREF="HTAAUtil.html">Authentication filter</A>. The string is freed by
1028: the Request object on deletion.
2.42 frystyk 1029: <PRE>
2.43 frystyk 1030: extern BOOL HTRequest_setProxy (HTRequest * request, const char * proxy);
1031: extern char * HTRequest_proxy (HTRequest * request);
1032: extern BOOL HTRequest_deleteProxy (HTRequest * request);
2.42 frystyk 1033: </PRE>
1034: <H2>
2.58 frystyk 1035: Enity Bytes Read or Written in a Request
2.30 frystyk 1036: </H2>
1037: <P>
1038: This function returns the bytes read in the current request. For a deeper
1039: description of what the current request is, please read the user's guide.
1040: This function can be used in for example the <A HREF="HTAlert.html">HTAlert
1041: module</A> to give the number of bytes read or written in a progress message.
2.1 frystyk 1042: <PRE>
2.49 frystyk 1043: extern long HTRequest_bodyRead (HTRequest * request);
2.58 frystyk 1044: extern long HTRequest_bodyWritten (HTRequest * request);
1045: </PRE>
2.62 kahan 1046:
1047: You can also get the total number of bytes read or written including the headers
1048:
2.58 frystyk 1049: <PRE>
1050: extern long HTRequest_bytesRead (HTRequest * request);
2.19 frystyk 1051: extern long HTRequest_bytesWritten (HTRequest * request);
2.1 frystyk 1052: </PRE>
2.62 kahan 1053:
2.30 frystyk 1054: <H2>
2.33 frystyk 1055: Internal Request Objects
2.30 frystyk 1056: </H2>
1057: <P>
2.33 frystyk 1058: The library may under certain circumstances create its own Request objects.
1059: These are all handled internal and does not show up on the application side
1060: at all.
2.1 frystyk 1061: <PRE>
2.33 frystyk 1062: extern BOOL HTRequest_setInternal (HTRequest * request, BOOL mode);
1063: extern BOOL HTRequest_internal (HTRequest * request);
2.49 frystyk 1064: extern int HTRequest_forceFlush (HTRequest * request);
2.1 frystyk 1065: </PRE>
1066: <PRE>
1067: #endif /* HTREQ_H */
1068: </PRE>
2.30 frystyk 1069: <P>
1070: <HR>
2.27 frystyk 1071: <ADDRESS>
2.63 ! frystyk 1072: @(#) $Id: HTReq.html,v 2.62 1998/10/23 18:26:42 kahan Exp $
2.27 frystyk 1073: </ADDRESS>
2.30 frystyk 1074: </BODY></HTML>
Webmaster
![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to HTReq.html CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Public] / libwww / Library / src