Annotation of libwww/Library/src/HTFormat.html, revision 2.68
2.10 timbl 1: <HTML>
2: <HEAD>
2.68 ! frystyk 3: <!-- Changed by: Henrik Frystyk Nielsen, 5-Jun-1996 -->
! 4: <TITLE>W3C Reference Library libwww Stream Pipe Manager</TITLE>
2.10 timbl 5: </HEAD>
2.1 timbl 6: <BODY>
2.67 frystyk 7: <H1>
2.68 ! frystyk 8: The Stream Pipe Manager
2.67 frystyk 9: </H1>
2.33 frystyk 10: <PRE>
11: /*
2.41 frystyk 12: ** (c) COPYRIGHT MIT 1995.
2.33 frystyk 13: ** Please first read the full copyright statement in the file COPYRIGH.
14: */
15: </PRE>
2.67 frystyk 16: <P>
2.68 ! frystyk 17: The Stream Pipe Manager is responsible for setting up the stream pipe from
! 18: the <A HREF="HTChannl.html">Channel Object</A> to the
! 19: <A HREF="HTReq.html">Request Object</A> when data is arriving, for example
! 20: as a response to s <A HREF="HTTP.html">HTTP</A> <B>Get</B> request. As data
! 21: arrives, we start to parse it and the more we know the more we can build
! 22: up our stream pipe. For example, in the case of HTTP, we first have a stream
! 23: that can parse the HTTP response line containing "<CODE>200 OK</CODE>". Then
! 24: we have a <A HREF="HTMIME.html">MIME parser</A> for handling the MIME headers.
! 25: When the MIME headers have been parsed, we know the content type and any
! 26: encoding of the MIME body. If we need to decode a chunked encoding then we
! 27: set up a chunked decoder, and if we have to parse a HTML object then we set
! 28: up a HTML parser.
2.67 frystyk 29: <P>
30: The Format Manager is also responsible for keeping track of the
31: "<I>preferences</I>" of the application and/or user. It is an integral part
32: of the Web and HTTP, that the client application can express its preferences
33: as a set of "accept" headers in a HTTP request. This task is highly related
34: to the task mentioned above as we there use the modules that are registered
35: and here tell the remote server what we are capable of doing and what we
36: would prefer.
37: <P>
38: <B>Note</B>: The library <B>core</B> does not define any default decoders
39: or parsers - they are all considered part of the application. The library
40: comes with a default set of parsers including the ones mentioned above which
41: can be initiated using the functions in <A HREF="HTInit.html">HTInit
42: module</A>. There are different initialization functions for content type
43: parsers and content encodings respectively.
44: <P>
45: Currently there are four dimensions for handling "accept" headers:
46: <P>
47: <UL>
48: <LI>
49: <A HREF="#type">Content Type Converters and Presenters</A>
50: <LI>
51: <A HREF="#encoding">Content Encoders and Decoders</A>
52: <LI>
53: <A HREF="#charset">Content Charsets</A>
54: <LI>
55: <A HREF="#language">Natural Languages</A>
56: </UL>
57: <P>
58: The application can assign its preferences in two ways: either <I>locally</I>
59: to a single request or <I>globally</I> to all requests. The local assignment
60: can either <I>add to </I>or <I>override</I> the global settings depending
61: on how they are registered. All local registration is handled by the
62: <A HREF="HTReq.html">Request Object</A> and the global registration is handled
63: by the Format Manager
64: <P>
65: <UL>
66: <LI>
67: <A HREF="#global">Global Preferences</A>
68: </UL>
69: <P>
70: When data is arriving and the Format Manager is to build a stream pipe from
71: the <A HREF="HTChannl.html">HTChannel Object</A> to the
72: <A HREF="HTReq.html">Request Object</A>, it uses a special set of <I>stream
73: stack algorithms</I>. These algorithms take the complete set of content type
74: converters, for example, and finds the one best suited for the task. We currently
75: have three stream stack algorithms: one for content types, one for content
76: encodings, and one for content transfer encodings:
77: <P>
78: <UL>
79: <LI>
80: <A HREF="#CTStack">The Content Type Stream Stack</A>
81: <LI>
82: <A HREF="#CEStack">The Content Encoding Stream Stack</A>
83: <LI>
84: <A HREF="#CTEStack">The Content Transfer Encoding Stream Stack</A>
85: </UL>
86: <P>
87: This module is implemented by <A HREF="HTFormat.c">HTFormat.c</A>, and it
88: is a part of the <A HREF="http://www.w3.org/pub/WWW/Library/">W3C Reference
89: Library</A>.
2.31 frystyk 90: <PRE>
91: #ifndef HTFORMAT_H
2.1 timbl 92: #define HTFORMAT_H
93:
2.63 frystyk 94: #include "<A HREF="HTUtils.html">HTUtils.h</A>"
95: #include "<A HREF="HTStream.html">HTStream.h</A>"
96: #include "<A HREF="HTAtom.html">HTAtom.h</A>"
97: #include "<A HREF="HTList.html">HTList.h</A>"
98: #include "<A HREF="HTAnchor.html">HTAnchor.h</A>"
99: #include "<A HREF="HTReq.html">HTReq.h</A>"
2.31 frystyk 100: </PRE>
2.67 frystyk 101: <H2>
102: <A NAME="type">Content Type Converters and Presenters</A>
103: </H2>
104: <P>
105: All content type converters are subclassed from the Generic stream objetc.
106: That way, we allow the application to do very fast progressive display of
107: incoming data. In other words, the stream model of the Library provides data
108: as soon as it arrives from the network, the application does not have to
109: wait until the whole document has been down loaded before it starts parsing
110: it.
111: <H3>
112: Content Type Converters
113: </H3>
114: <P>
115: A <CODE>converter</CODE> is a stream with a special set of parameters and
116: which is registered as capable of converting from a MIME type to something
117: else (maybe another MIME-type). A converter is defined to be a function returning
118: a stream and accepting the following parameters. The content type elements
119: are atoms for which we have defined a prototype.
2.31 frystyk 120: <PRE>
2.52 frystyk 121: typedef HTStream * HTConverter (HTRequest * request,
122: void * param,
123: HTFormat input_format,
124: HTFormat output_format,
125: HTStream * output_stream);
2.42 frystyk 126: </PRE>
2.67 frystyk 127: <H3>
128: The HTPresentation Object
129: </H3>
130: <P>
131: A <CODE>presenter</CODE> is a module (possibly an external program) which
132: can present a graphic object of a certain MIME type to the user. That is,
133: <CODE>presenters</CODE> are normally used to present objects that the
134: <CODE>converters</CODE> are not able to handle. Data is transferred to the
135: external program using for example the
136: <A HREF="HTFWrite.html">HTSaveAndExecute</A> stream which writes to a local
137: file. Both presenters and converters are of the type
138: <A HREF="#converter">HTConverter</A>.
2.31 frystyk 139: <PRE>
2.42 frystyk 140: typedef struct _HTPresentation {
141: HTFormat rep; /* representation name atomized */
142: HTFormat rep_out; /* resulting representation */
143: HTConverter *converter; /* The routine to gen the stream stack */
144: char * command; /* MIME-format string */
145: char * test_command; /* MIME-format string */
146: double quality; /* Between 0 (bad) and 1 (good) */
147: double secs;
148: double secs_per_byte;
149: } HTPresentation;
2.28 frystyk 150: </PRE>
2.67 frystyk 151: <H3>
152: Basic Content type Converters
153: </H3>
154: <P>
155: We have a small set of basic converters that can be hooked in anywhere. They
156: don't "convert" anything but are nice to have.
157: <PRE>extern HTConverter HTThroughLine;
2.63 frystyk 158: extern HTConverter HTBlackHoleConverter;
159: </PRE>
2.67 frystyk 160: <H3>
161: Predefined Content Types
162: </H3>
163: <P>
164: These macros (which used to be constants) define some basic internally referenced
165: representations. The <CODE>www/xxx</CODE> ones are of course not MIME standard.
166: They are internal representations used in the Library but they can't be exported
167: to other apps!
2.28 frystyk 168: <PRE>
2.57 frystyk 169: #define WWW_RAW HTAtom_for("www/void") /* Raw output from Protocol */
2.28 frystyk 170: </PRE>
2.67 frystyk 171: <P>
172: <CODE>WWW_RAW</CODE> is an output format which leaves the input untouched
173: <EM>exactly</EM> as it is received by the protocol module. For example, in
174: the case of FTP, this format returns raw ASCII objects for directory listings;
175: for HTTP, everything including the header is returned, for Gopher, a raw
176: ASCII object is returned for a menu etc.
177: <PRE>
178: #define WWW_SOURCE HTAtom_for("*/*")
179: </PRE>
180: <P>
181: <CODE>WWW_SOURCE</CODE> is an output format which leaves the input untouched
182: <EM>exactly</EM> as it is received by the protocol module <B>IF</B> not a
183: suitable converter has been registered with a quality factor higher than
184: 1 (for example 2). In this case the <EM>SUPER CONVERTER</EM> is preferred
185: for the raw output. This can be used as a filter effect that allows conversion
186: from, for example raw FTPdirectory listings into HTML but passes a MIME body
187: untouched.
188: <PRE>
189: #define WWW_PRESENT HTAtom_for("www/present")
190: </PRE>
191: <P>
192: <CODE>WWW_PRESENT</CODE> represents the user's perception of the document.
193: If you convert to <CODE>WWW_PRESENT</CODE>, you present the material to the
194: user.
2.58 frystyk 195: <PRE>
196: #define WWW_DEBUG HTAtom_for("www/debug")
197: </PRE>
2.67 frystyk 198: <P>
199: <CODE>WWW_DEBUG</CODE> represents the user's perception of debug information,
200: for example sent as a HTML document in a HTTP redirection message.
2.28 frystyk 201: <PRE>
2.52 frystyk 202: #define WWW_UNKNOWN HTAtom_for("www/unknown")
2.28 frystyk 203: </PRE>
2.67 frystyk 204: <P>
205: <CODE>WWW_UNKNOWN</CODE> is a really unknown type. It differs from the real
206: MIME type <EM>"application/octet-stream"</EM> in that we haven't even tried
207: to figure out the content type at this point.
208: <P>
2.31 frystyk 209: These are regular MIME types defined. Others can be added!
2.28 frystyk 210: <PRE>
2.52 frystyk 211: #define WWW_HTML HTAtom_for("text/html")
2.28 frystyk 212: #define WWW_PLAINTEXT HTAtom_for("text/plain")
2.52 frystyk 213:
214: #define WWW_MIME HTAtom_for("message/rfc822")
2.60 frystyk 215: #define WWW_MIME_HEAD HTAtom_for("message/x-rfc822-head")
2.65 frystyk 216: #define WWW_MIME_FOOT HTAtom_for("message/x-rfc822-foot")
2.52 frystyk 217:
2.10 timbl 218: #define WWW_AUDIO HTAtom_for("audio/basic")
2.52 frystyk 219:
2.26 frystyk 220: #define WWW_VIDEO HTAtom_for("video/mpeg")
2.52 frystyk 221:
2.66 frystyk 222: #define WWW_GIF HTAtom_for("image")
2.63 frystyk 223: #define WWW_JPEG HTAtom_for("image/jpeg")
224: #define WWW_TIFF HTAtom_for("image/tiff")
2.52 frystyk 225: #define WWW_PNG HTAtom_for("image/png")
226:
227: #define WWW_BINARY HTAtom_for("application/octet-stream")
228: #define WWW_POSTSCRIPT HTAtom_for("application/postscript")
229: #define WWW_RICHTEXT HTAtom_for("application/rtf")
2.48 frystyk 230: </PRE>
2.67 frystyk 231: <P>
232: We also have some MIME types that come from the various protocols when we
233: convert from ASCII to HTML.
2.48 frystyk 234: <PRE>
235: #define WWW_GOPHER_MENU HTAtom_for("text/x-gopher")
2.53 frystyk 236: #define WWW_CSO_SEARCH HTAtom_for("text/x-cso")
2.48 frystyk 237:
238: #define WWW_FTP_LNST HTAtom_for("text/x-ftp-lnst")
239: #define WWW_FTP_LIST HTAtom_for("text/x-ftp-list")
240:
241: #define WWW_NNTP_LIST HTAtom_for("text/x-nntp-list")
242: #define WWW_NNTP_OVER HTAtom_for("text/x-nntp-over")
243: #define WWW_NNTP_HEAD HTAtom_for("text/x-nntp-head")
2.59 frystyk 244:
245: #define WWW_HTTP HTAtom_for("text/x-http")
2.55 frystyk 246: </PRE>
2.67 frystyk 247: <P>
248: Finally we have defined a special format for our RULE files as they can be
249: handled by a special converter.
2.55 frystyk 250: <PRE>
2.57 frystyk 251: #define WWW_RULES HTAtom_for("application/x-www-rules")
2.28 frystyk 252: </PRE>
2.67 frystyk 253: <H3>
254: Register Presenters
255: </H3>
256: <P>
257: This function creates a presenter object and adds to the list of conversions.
258: These are the parameters :
2.1 timbl 259: <DL>
2.67 frystyk 260: <DT>
261: conversions
262: <DD>
263: The list of <CODE>conveters</CODE> and <CODE>presenters</CODE>
264: <DT>
265: rep_in
266: <DD>
267: the MIME-style format name
268: <DT>
269: rep_out
270: <DD>
271: is the resulting content-type after the conversion
272: <DT>
273: converter
274: <DD>
275: is the routine to call which actually does the conversion
276: <DT>
277: quality
278: <DD>
279: A degradation faction [0..1]
280: <DT>
281: maxbytes
282: <DD>
283: A limit on the length acceptable as input (0 infinite)
284: <DT>
285: maxsecs
286: <DD>
287: A limit on the time user will wait (0 for infinity)
2.1 timbl 288: </DL>
2.31 frystyk 289: <PRE>
2.49 frystyk 290: extern void HTPresentation_add (HTList * conversions,
2.61 frystyk 291: const char * representation,
292: const char * command,
293: const char * test_command,
2.49 frystyk 294: double quality,
295: double secs,
296: double secs_per_byte);
2.1 timbl 297:
2.50 frystyk 298: extern void HTPresentation_deleteAll (HTList * list);
299: </PRE>
2.67 frystyk 300: <H3>
301: Register Converters
302: </H3>
303: <P>
304: This function creates a presenter object and adds to the list of conversions.
2.1 timbl 305: <DL>
2.67 frystyk 306: <DT>
307: conversions
308: <DD>
309: The list of <CODE>conveters</CODE> and <CODE>presenters</CODE>
310: <DT>
311: rep_in
312: <DD>
313: the MIME-style format name
314: <DT>
315: rep_out
316: <DD>
317: is the resulting content-type after the conversion
318: <DT>
319: converter
320: <DD>
321: is the routine to call which actually does the conversion
322: <DT>
323: quality
324: <DD>
325: A degradation faction [0..1]
326: <DT>
327: maxbytes
328: <DD>
329: A limit on the length acceptable as input (0 infinite)
330: <DT>
331: maxsecs
332: <DD>
333: A limit on the time user will wait (0 for infinity)
2.1 timbl 334: </DL>
335: <PRE>
2.49 frystyk 336: extern void HTConversion_add (HTList * conversions,
2.61 frystyk 337: const char * rep_in,
338: const char * rep_out,
2.49 frystyk 339: HTConverter * converter,
340: double quality,
341: double secs,
342: double secs_per_byte);
2.63 frystyk 343:
344: extern void HTConversion_deleteAll (HTList * list);
2.42 frystyk 345: </PRE>
2.67 frystyk 346: <H2>
347: <A NAME="encoding">Content and Transfer Encoders and Decoders</A>
348: </H2>
349: <P>
350: Content codins are transformations applied to an entity object after it was
351: created in its original form. The Library handles two types of codings:
2.64 frystyk 352: <DL>
2.67 frystyk 353: <DT>
354: <B>Content Codings</B>
355: <DD>
356: Content codings values indicate an encoding transformation that has been
357: applied to a resource. Content cosings are primarily used to allow a document
358: to be compressed or encrypted without loosing the identity of its underlying
359: media type.
360: <DT>
361: <B>Content Transfer Codings</B>
362: <DD>
363: Content transfer codings values are used to indicate an encoding transformation
364: that has been, can be, or may be need to be applied to an enity body in order
365: to ensure safe transport through the network. This differs from a content
366: coding in that the transfer coding is a property of the message, not the
367: original message.
2.64 frystyk 368: </DL>
2.67 frystyk 369: <P>
370: Both types of encodings use the same registration mechanism in the Library
371: which we describe below:
372: <H3>
373: Encoders and Decoders
374: </H3>
375: <P>
376: <EM>Encoders</EM> and <EM>decoders</EM> are subclassed from the
377: <A HREF="HTStream.html">generic stream class</A>. <EM>Encoders</EM> are capable
378: of adding a content coding to a data object and <EM>decoders</EM> can remove
379: a content coding.
2.50 frystyk 380: <PRE>
2.64 frystyk 381: typedef HTStream * HTCoder (HTRequest * request,
382: void * param,
383: HTEncoding coding,
384: HTStream * target);
2.50 frystyk 385: </PRE>
2.67 frystyk 386: <P>
387: The <EM>encoding</EM> is the name of the encoding mechanism reporesented
388: as an <A HREF="HTAtom.html">atom</A>, for example "zip", "chunked", etc.
389: Encodings are registered in lists and content encodings are separated from
390: transfer encodings by registering them in different lists.
391: <H3>
392: The HTCoding Object
393: </H3>
394: <P>
395: The <EM>HTCoding</EM> object represents a registered encoding together with
396: a encoder and a decoder.
2.63 frystyk 397: <PRE>
2.64 frystyk 398: typedef struct _HTCoding HTCoding;
2.63 frystyk 399: </PRE>
2.67 frystyk 400: <P>
401: Predefined Coding Types We have a set of pre defined atoms for various types
402: of content encodings and transfer encodings. "chunked" is not exactly in
403: the same group as the other encodings such as "binary" but it really doesn't
404: make any difference as it is just a matter of how the words are chosen. The
405: first three transfer encodings are actually not encodings - they are just
406: left overs from brain dead mail systems.
2.42 frystyk 407: <PRE>
2.63 frystyk 408: #define WWW_CTE_7BIT HTAtom_for("7bit")
409: #define WWW_CTE_8BIT HTAtom_for("8bit")
410: #define WWW_CTE_BINARY HTAtom_for("binary")
2.64 frystyk 411:
2.63 frystyk 412: #define WWW_CTE_BASE64 HTAtom_for("base64")
413: #define WWW_CTE_MACBINHEX HTAtom_for("macbinhex")
2.64 frystyk 414: #define WWW_CTE_CHUNKED HTAtom_for("chunked")
2.63 frystyk 415:
416: #define WWW_CE_COMPRESS HTAtom_for("compress")
417: #define WWW_CE_GZIP HTAtom_for("gzip")
2.42 frystyk 418: </PRE>
2.67 frystyk 419: <H3>
420: Register Content Coders
421: </H3>
422: <P>
2.63 frystyk 423: There is no difference in registrering a content encoder or a content decoder,
424: it all depends on how you use the list of encoders/decoders.
2.42 frystyk 425: <PRE>
2.64 frystyk 426: extern BOOL HTCoding_add (HTList * list,
427: const char * encoding,
428: HTCoder * encoder,
429: HTCoder * decoder,
430: double quality);
2.63 frystyk 431:
2.64 frystyk 432: extern void HTCoding_deleteAll (HTList * list);
2.42 frystyk 433:
2.64 frystyk 434: extern const char * HTCoding_name (HTCoding * me);
2.42 frystyk 435: </PRE>
2.67 frystyk 436: <H2>
437: <A NAME="charset">Content Charsets</A>
438: </H2>
439: <H3>
440: Register a Charset
441: </H3>
2.42 frystyk 442: <PRE>
2.50 frystyk 443: extern void HTCharset_add (HTList * list,
2.61 frystyk 444: const char * charset,
2.50 frystyk 445: double quality);
2.42 frystyk 446: </PRE>
2.67 frystyk 447: <H3>
448: Delete a list of Charsets
449: </H3>
2.50 frystyk 450: <PRE>
2.63 frystyk 451: typedef struct _HTAcceptNode {
452: HTAtom * atom;
453: double quality;
454: } HTAcceptNode;
455: </PRE>
456: <PRE>
2.50 frystyk 457: extern void HTCharset_deleteAll (HTList * list);
458: </PRE>
2.67 frystyk 459: <H2>
460: <A NAME="language">Content Languages</A>
461: </H2>
462: <H3>
463: Register a Language
464: </H3>
2.31 frystyk 465: <PRE>
2.50 frystyk 466: extern void HTLanguage_add (HTList * list,
2.61 frystyk 467: const char * lang,
2.50 frystyk 468: double quality);
469: </PRE>
2.67 frystyk 470: <H3>
471: Delete a list of Languages
472: </H3>
2.50 frystyk 473: <PRE>
2.51 frystyk 474: extern void HTLanguage_deleteAll (HTList * list);
2.50 frystyk 475: </PRE>
2.67 frystyk 476: <P>
477: <H2>
478: <A NAME="global">Global Preferences</A>
479: </H2>
480: <P>
2.50 frystyk 481: There are two places where these preferences can be registered: in a
2.67 frystyk 482: <EM>global</EM> list valid for <B>all</B> requests and a <EM>local</EM> list
483: valid for a particular request only. These are valid for <EM>all</EM> requests.
484: See the <A HREF="HTReq.html">Request Manager</A> fro local sets.
485: <H3>
486: Converters and Presenters
487: </H3>
488: <P>
489: The <EM>global</EM> list of specific conversions which the format manager
490: can do in order to fulfill the request. There is also a
491: <A HREF="HTReq.html"><EM>local</EM></A> list of conversions which contains
492: a generic set of possible conversions.
2.50 frystyk 493: <PRE>
2.64 frystyk 494: extern void HTFormat_setConversion (HTList * list);
2.50 frystyk 495: extern HTList * HTFormat_conversion (void);
2.31 frystyk 496: </PRE>
2.67 frystyk 497: <H3>
498: Content Codings
499: </H3>
2.50 frystyk 500: <PRE>
2.64 frystyk 501: extern void HTFormat_setContentCoding (HTList * list);
502: extern HTList * HTFormat_contentCoding (void);
2.50 frystyk 503: </PRE>
2.67 frystyk 504: <H3>
505: Content Transfer Codings
506: </H3>
2.64 frystyk 507: <PRE>
508: extern void HTFormat_setTransferCoding (HTList * list);
509: extern HTList * HTFormat_transferCoding (void);
510: </PRE>
2.67 frystyk 511: <P>
512: We also define a macro to find out whether a transfer encoding is really
513: an encoding or whether it is just a "dummy" as for example 7bit, 8bit, and
514: binary.
2.64 frystyk 515: <PRE>
516: #define HTFormat_isUnityTransfer(me) \
517: ((me)==NULL \
518: || (me)==WWW_CTE_BINARY || (me)==WWW_CTE_7BIT || (me)==WWW_CTE_8BIT)
519: </PRE>
2.67 frystyk 520: <H3>
521: Content Languages
522: </H3>
2.50 frystyk 523: <PRE>
2.64 frystyk 524: extern void HTFormat_setLanguage (HTList * list);
2.50 frystyk 525: extern HTList * HTFormat_language (void);
526: </PRE>
2.67 frystyk 527: <H3>
528: Content Charsets
529: </H3>
2.31 frystyk 530: <PRE>
2.64 frystyk 531: extern void HTFormat_setCharset (HTList * list);
2.50 frystyk 532: extern HTList * HTFormat_charset (void);
2.31 frystyk 533: </PRE>
2.67 frystyk 534: <H3>
535: Delete All Global Lists
536: </H3>
537: <P>
2.50 frystyk 538: This is a convenience function that might make life easier.
2.34 frystyk 539: <PRE>
2.50 frystyk 540: extern void HTFormat_deleteAll (void);
2.34 frystyk 541: </PRE>
2.67 frystyk 542: <H2>
543: <A NAME="CTStack">The Content Type Stream Stack</A>
544: </H2>
545: <P>
546: This is the routine which actually sets up the content type conversion. It
547: currently checks only for direct conversions, but multi-stage conversions
548: are forseen. It takes a stream into which the output should be sent in the
549: final format, builds the conversion stack, and returns a stream into which
550: the data in the input format should be fed. If <CODE>guess</CODE> is true
551: and input format is <CODE>www/unknown</CODE>, try to guess the format by
552: looking at the first few bytes of the stream.
553: <P>
2.31 frystyk 554: <PRE>
2.52 frystyk 555: extern HTStream * HTStreamStack (HTFormat rep_in,
556: HTFormat rep_out,
557: HTStream * output_stream,
558: HTRequest * request,
559: BOOL guess);
2.1 timbl 560: </PRE>
2.67 frystyk 561: <H3>
562: Cost of a Stream Stack
563: </H3>
564: <P>
565: Must return the cost of the same stack which HTStreamStack would set up.
2.31 frystyk 566: <PRE>
2.52 frystyk 567: extern double HTStackValue (HTList * conversions,
568: HTFormat format_in,
569: HTFormat format_out,
570: double initial_value,
571: long int length);
2.64 frystyk 572: </PRE>
2.67 frystyk 573: <H2>
574: <A NAME="CEStack">Content Encoding Stream Stack</A>
575: </H2>
576: <P>
577: When creating a coding stream stack, it is important that we keep the right
578: order of encoders and decoders. As an example, the HTTP spec specifies that
579: the list in the <EM>Content-Encoding</EM> header follows the order in which
580: the encodings have been applied to the object. Internally, we represent the
581: content encodings as <A HREF="HTAtom.html">atoms</A> in a linked
582: <A HREF="HTList.html">list object</A>.
583: <P>
584: The creation of the content coding stack is not based on quality factors
585: as we don't have the freedom as with content types. When using content codings
586: we <EM>must</EM> apply the codings specified or fail.
2.64 frystyk 587: <PRE>
588: extern HTStream * HTContentCodingStack (HTEncoding coding,
589: HTStream * target,
590: HTRequest * request,
591: void * param,
592: BOOL encoding);
593: </PRE>
2.67 frystyk 594: <P>
595: Here you can provide a complete list instead of a single token. The list
596: has to be filled up in the order the _encodings_ are to be applied
2.64 frystyk 597: <PRE>
598: extern HTStream * HTContentEncodingStack (HTList * encodings,
599: HTStream * target,
600: HTRequest * request,
601: void * param);
602: </PRE>
2.67 frystyk 603: <P>
604: Here you can provide a complete list instead of a single token. The list
605: has to be in the order the _encodings_ were applied - that is, the same way
606: that _encodings_ are to be applied. This is all consistent with the order
607: of the Content-Encoding header.
2.64 frystyk 608: <PRE>
609: extern HTStream * HTContentDecodingStack (HTList * encodings,
610: HTStream * target,
611: HTRequest * request,
612: void * param);
613: </PRE>
2.67 frystyk 614: <P>
615: <H2>
616: <A NAME="CTEStack">Content Transfer Encoding Stream Stack</A>
617: </H2>
618: <P>
619: Creating the transfer content encoding stream stack is not based on quality
620: factors as we don't have the freedom as with content types. Specify whether
621: you you want encoding or decoding using the BOOL "encode" flag.
2.64 frystyk 622: <PRE>
623: extern HTStream * HTTransferCodingStack (HTEncoding encoding,
624: HTStream * target,
625: HTRequest * request,
626: void * param,
627: BOOL encode);
628: </PRE>
629: <PRE>
2.42 frystyk 630: #endif /* HTFORMAT */
2.38 frystyk 631: </PRE>
2.67 frystyk 632: <P>
633: <HR>
2.63 frystyk 634: <ADDRESS>
2.68 ! frystyk 635: @(#) $Id: HTFormat.html,v 2.67 1996/06/01 17:46:48 frystyk Exp $
2.63 frystyk 636: </ADDRESS>
2.67 frystyk 637: </BODY></HTML>
Webmaster