Annotation of libwww/Library/src/HTAccess.html, revision 2.89
2.9 timbl 1: <HTML>
2: <HEAD>
2.79 frystyk 3: <!-- Changed by: Henrik Frystyk Nielsen, 15-Jul-1996 -->
2.87 frystyk 4: <TITLE>W3C Sample Code Library libwww Accessing URIs</TITLE>
2.9 timbl 5: </HEAD>
2.5 timbl 6: <BODY>
2.77 frystyk 7: <H1>
2.87 frystyk 8: Accessing URIs
2.77 frystyk 9: </H1>
2.41 frystyk 10: <PRE>
11: /*
2.50 frystyk 12: ** (c) COPYRIGHT MIT 1995.
2.41 frystyk 13: ** Please first read the full copyright statement in the file COPYRIGH.
14: */
15: </PRE>
2.77 frystyk 16: <P>
17: This module is the application interface module to the
2.78 frystyk 18: <A HREF="HTReq.html">Request class</A>. It contains a lot of methods for
2.87 frystyk 19: loading URIs and also for uploading URIs using <CODE>PUT</CODE> or
2.78 frystyk 20: <CODE>POST</CODE>, for example. You can use the Request class directly but
21: this module makes it easier to use by providing a lot of small request functions
22: using the Request class in different ways. It contains help functions for
23: accessing documents and for uploading documents to a remote server.
2.77 frystyk 24: <P>
2.87 frystyk 25: This module contains functions for handling all HTTP/1.1 methods:
26: <DL>
27: <DT>
28: GET Requests
29: <DD>
30: <UL>
31: <LI>
32: <A HREF="#Load">Various GET requests including specialized functions like
33: loading a rule file, etc.</A>
34: <LI>
35: <A HREF="#Search">Search requests based on the GET method</A>
36: <LI>
37: <A HREF="#getforms">Formdata requests based on the GET method</A>
38: </UL>
39: <DT>
40: PUT Requests
41: <DD>
42: <UL>
43: <LI>
44: <A HREF="#SaveASIS">Save a document from memory ASIS using PUT</A>
45: <LI>
46: <A HREF="#SaveStructured">Save a structured document from memory using PUT</A>
47: <LI>
48: <A HREF="#SaveURL">Save any URI (FTP, HTTP, local disk) using PUT</A>
49: </UL>
50: <DT>
51: POST Requests
52: <DD>
53: <UL>
54: <LI>
55: <A HREF="#PostForms">Post Formdata to a remote HTTP server</A>
56: <LI>
57: <A HREF="#PostASIS">Post a document from memory ASIS to a remote HTTP
58: server</A>
59: </UL>
60: <DT>
61: HEAD, DELETE, OPTIONS, and TRACE requests
62: <DD>
63: <UL>
64: <LI>
65: <A HREF="#Head">Get metainformation about a document using HEAD requests</A>
66: <LI>
67: <A HREF="#Delete">Delete documents based on the DELETE method</A>
68: <LI>
69: <A HREF="#OPTIONS">Get information about the features supoprted by a resource
70: using OPTIONS</A>
71: <LI>
72: <A HREF="#TRACE">Trace a request using the TRACE method</A>
73: </UL>
74: </DL>
75: <P>
2.88 frystyk 76: Furthermore, it contains a <A HREF="#serve">few access methods for handling
77: incoming requests</A> - in orther words acting as a server. Although libwww
78: is primarily for clients, it is in fact symmetric in that it can handle both
79: client requests and server requests.
80: <P>
2.77 frystyk 81: This module is implemented by <A HREF="HTAccess.c">HTAccess.c</A>, and it
2.84 frystyk 82: is a part of the <A HREF="http://www.w3.org/Library/"> W3C Sample Code
2.77 frystyk 83: Library</A>.
2.33 frystyk 84: <PRE>
85: #ifndef HTACCESS_H
1.1 timbl 86: #define HTACCESS_H
2.44 roeber 87:
2.64 frystyk 88: #include "HTReq.h"
89: #include "HTAnchor.h"
2.52 frystyk 90: </PRE>
2.77 frystyk 91: <H2>
2.87 frystyk 92: <A NAME="Load">Load a Document (Method = GET)</A>
2.77 frystyk 93: </H2>
94: <P>
2.87 frystyk 95: URIs can be accesses using a character string, for example
2.78 frystyk 96: "<CODE>http://www.w3.org</CODE>" or it can be accessed by using the libwww
2.87 frystyk 97: representation of a URI called an <A HREF="HTAnchor.html">Anchor object</A>.
98: Note that we call all objects accessible through URIs for <I>documents</I>
2.80 frystyk 99: - this is a notion we have inherited from the hypertext world.
2.77 frystyk 100: <H3>
2.87 frystyk 101: Load a Document from Absolute URI
2.77 frystyk 102: </H3>
103: <P>
2.87 frystyk 104: Request a document referencd by an <I>absolute</I> URI. The output from the
2.78 frystyk 105: request is passed to the <A HREF="HTFormat.html">Stream Pipe Manager</A>
106: that figures out where to pump the data. This can for example be to the display
107: or to a local file depending on the set of
108: <A HREF="HTFormat.html#type">converters</A> registered by the application.
109: <PRE>extern BOOL HTLoadAbsolute (const char * url, HTRequest * request);
2.65 frystyk 110: </PRE>
2.77 frystyk 111: <H3>
2.87 frystyk 112: Load a Document from Relative URI
2.77 frystyk 113: </H3>
114: <P>
2.87 frystyk 115: Request a document referenced by a <I>relative</I> URI. The relative URI
2.78 frystyk 116: is made absolute by resolving it relative to the address of the '<I>base</I>'
117: anchor.
118: <PRE>extern BOOL HTLoadRelative (const char * relative,
119: HTParentAnchor * base,
120: HTRequest * request);
2.66 frystyk 121: </PRE>
2.77 frystyk 122: <H3>
2.79 frystyk 123: Load a Document into Memory
2.77 frystyk 124: </H3>
125: <P>
2.87 frystyk 126: Request a document referred to by the URI and load it into a
2.85 frystyk 127: <A HREF="HTChunk.html">HTChunk object</A>. A <A HREF="HTChunk.html">chunk
128: object</A> is a dynamic string so in the end you will have a single memory
129: buffer containing the document. The chunk must be freed by the caller.
2.78 frystyk 130: <PRE>extern HTChunk * HTLoadToChunk (const char * url, HTRequest * request);
2.52 frystyk 131: </PRE>
2.77 frystyk 132: <H3>
2.79 frystyk 133: Load a Document and Save as a Local File
134: </H3>
135: <P>
2.87 frystyk 136: This function loads a URI and saves the contents in the specifed file. The
2.80 frystyk 137: file should not be open, as the load function both opens and closes
138: the file. If the file already exists then it asks the user whether the file
139: should be overwritten or not. the contents is saved <I>ASIS</I> - that is
140: - we do not touch the contents of the file!
2.79 frystyk 141: <PRE>
142: extern BOOL HTLoadToFile (const char * url, HTRequest * request,
143: const char * filename);
144: </PRE>
145: <H3>
146: Load a Document and put the Contents into a Stream
147: </H3>
148: <P>
2.87 frystyk 149: Request a document referenced by an absolute URI and sending the data down
2.80 frystyk 150: a stream. This stream can be anny stream you like, for eample one from the
151: <A HREF="WWWStream.html">Stream Interface</A>.
2.79 frystyk 152: <PRE>
153: extern BOOL HTLoadToStream (const char * url, HTStream * output,
154: HTRequest * request);
155: </PRE>
156: <H3>
157: Load a Document using an Anchor
2.77 frystyk 158: </H3>
159: <P>
2.87 frystyk 160: Here the URI is represented by an <A HREF="HTAnchor.html">Anchor object</A>.
161: You can get an anchor object representing a URI by passing the URI to the
2.80 frystyk 162: appropriate method in the <A HREF="HTAnchor.html">Anchor class</A>.
2.78 frystyk 163: <PRE>extern BOOL HTLoadAnchor (HTAnchor * anchor, HTRequest * request);
2.52 frystyk 164: </PRE>
2.77 frystyk 165: <H3>
2.79 frystyk 166: Load a Document into Memory using an Anchor
2.77 frystyk 167: </H3>
168: <P>
2.87 frystyk 169: This is the same as <CODE>HTLoadToChunk</CODE> but instead of passing a URI
2.85 frystyk 170: string you pass an <A HREF="HTAnchor.html">HTAnchor object</A>. Internally,
2.87 frystyk 171: all URIs are represented as anchors which contains all the information we
2.85 frystyk 172: have about the resource. The chunk must be freed by the caller.
2.78 frystyk 173: <PRE>extern HTChunk * HTLoadAnchorToChunk (HTAnchor * anchor, HTRequest * request);
2.77 frystyk 174: </PRE>
175: <H3>
2.79 frystyk 176: Recursively Request a Document using Anchors
2.77 frystyk 177: </H3>
178: <P>
2.80 frystyk 179: Same as <CODE>HTLoadAnchor()</CODE> but the information in the
180: <A HREF="HTReq.html#Error">error stack</A> in the <A HREF="HTReq.html">request
181: object</A> is kept, so that any error messages in one. This function is almost
182: identical to <CODE>HTLoadAnchor</CODE>, but it doesn't clear the error stack
183: so that the information in there is kept.
2.78 frystyk 184: <PRE>extern BOOL HTLoadAnchorRecursive (HTAnchor * anchor, HTRequest * request);
2.46 frystyk 185: </PRE>
2.78 frystyk 186: <H2>
2.79 frystyk 187: Load Special Documents
2.78 frystyk 188: </H2>
2.79 frystyk 189: <P>
190: We also have a set of functions for loading special files like rules files
2.87 frystyk 191: which also are referenced by a URI but which do have to be treated specially.
2.77 frystyk 192: <H3>
2.79 frystyk 193: Load a Rule File
2.77 frystyk 194: </H3>
195: <P>
2.87 frystyk 196: Rule files can be loaded just like any other URI but you can also just use
197: these functions which do all the work for you: they load a rule find with
198: the URI specified and add the set of rules to the existing set.
199: <P>
200: They come in two flavours - one that asks the user whether it is OK to add
201: the rules and one that does it automatically without asking. As the app would
202: have to call this method explicitly, it may have other ways of protecting
203: the user.
2.86 frystyk 204: <P>
2.87 frystyk 205: Both functions use <A HREF="HTReq.html#preemptive">preemptive requests</A>
206: so that everything else stops in the meantime.
2.86 frystyk 207: <PRE>
208: extern BOOL HTLoadRules (const char * url);
209: extern BOOL HTLoadRulesAutomatically (const char * url);
2.79 frystyk 210: </PRE>
211: <H2>
2.85 frystyk 212: <A NAME="Search">Search a Document (Method = GET)</A>
2.79 frystyk 213: </H2>
214: <P>
2.80 frystyk 215: The search methods all use <CODE>GET</CODE> as the method in the
2.85 frystyk 216: <A HREF="http://www.w3.org/Protocols/">HTTP request</A>. The functions take
217: the keywords and encode them according to
2.80 frystyk 218: <A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1866.txt">RFC
219: 1866 (Hypertext Markup language)</A>. That is, the query part is separated
2.87 frystyk 220: from the rest of the URI by a "?".
2.79 frystyk 221: <P>
222: The keywords are passed to the function as a <A HREF="HTChunk.html">Chunk
2.80 frystyk 223: Object</A> and each keyword <B>must</B> be separated by a space ' '. This
2.87 frystyk 224: will then be converted into a '+' before added to the URI.
2.79 frystyk 225: <H3>
2.87 frystyk 226: Search a Document from Absolute URI
2.79 frystyk 227: </H3>
2.46 frystyk 228: <PRE>
2.79 frystyk 229: extern BOOL HTSearchAbsolute (HTChunk * keywords,
230: const char * base,
231: HTRequest * request);
2.46 frystyk 232: </PRE>
2.77 frystyk 233: <H3>
2.87 frystyk 234: Search a Document from Relative URI
2.77 frystyk 235: </H3>
236: <P>
2.87 frystyk 237: Search a document referenced by a <I>relative</I> URI. The relative URI is
2.79 frystyk 238: made absolute by resolving it relative to the address of the '<I>base</I>'
239: anchor.
240: <PRE>
241: extern BOOL HTSearchRelative (HTChunk * keywords,
242: const char * relative,
243: HTParentAnchor * base,
2.64 frystyk 244: HTRequest * request);
2.39 frystyk 245: </PRE>
2.79 frystyk 246: <H3>
247: Search a Document using an Anchor
248: </H3>
249: <PRE>
250: extern BOOL HTSearchAnchor (HTChunk * keywords,
251: HTAnchor * anchor,
252: HTRequest * request);
253: </PRE>
254: <H3>
255: Search a Document using an Anchor Using a String
256: </H3>
257: <P>
258: This works exactly as the <CODE>HTSearchAnchor()</CODE> function but takes
259: a C string instead of a <A HREF="HTChunk.html">chunk object</A>.
260: <PRE>
261: extern BOOL HTSearchString (const char * keywords,
262: HTAnchor * anchor,
263: HTRequest * request);
264: </PRE>
265: <H2>
2.87 frystyk 266: <A NAME="getforms">Submit Forms Using GET Method</A>
2.79 frystyk 267: </H2>
268: <P>
2.87 frystyk 269: Formdata can be sent to an HTTP server in two ways - it can either use a
2.80 frystyk 270: <CODE>GET</CODE> method or it can use a <CODE>POST</CODE> method. The difference
271: is whether the request "has side effects" or not. For example, if you are
272: ordering a pizza then the (hopefully positive) sideeffect is that you actually
273: get one delivered. However, if you are issuing search data - for example
274: to Alta Vista, then there is no sideeffect. In the former example you would
275: use the <CODE>GET</CODE> form and in the latter you would use the
276: <CODE>POST</CODE> form.
2.79 frystyk 277: <H3>
2.87 frystyk 278: Submit Form from Absolute URI using GET
2.79 frystyk 279: </H3>
280: <P>
2.87 frystyk 281: Submit formdata using GET to the address indicated as the "base" which must
282: be an absolute URI. The list of form data must be given as an
2.80 frystyk 283: <A HREF="HTAssoc.html">association list</A> where the name is the field name
2.87 frystyk 284: and the value is the value of the field.
2.79 frystyk 285: <PRE>
286: extern BOOL HTGetFormAbsolute (HTAssocList * formdata,
287: const char * base,
288: HTRequest * request);
289: </PRE>
290: <H3>
2.87 frystyk 291: Submit Form from Relative URI using GET
2.79 frystyk 292: </H3>
293: <P>
2.87 frystyk 294: Submit formdata using GET to the address indicated relative to the address
295: of the base anchor. The list of form data must be given as an
2.80 frystyk 296: <A HREF="HTAssoc.html">association list</A> where the name is the field name
2.79 frystyk 297: and the value is the value of the field.
298: <PRE>
299: extern BOOL HTGetFormRelative (HTAssocList * formdata,
300: const char * relative,
301: HTParentAnchor * base,
302: HTRequest * request);
303: </PRE>
304: <H3>
305: Send a Form using an Anchor and the GET Method
306: </H3>
307: <P>
2.87 frystyk 308: Submit formdata using GET to the address indicated of the anchor. The list
309: of form data must be given as an <A HREF="HTAssoc.html">association list</A>
310: where the name is the field name and the value is the value of the field.
2.79 frystyk 311: <PRE>
312: extern BOOL HTGetFormAnchor (HTAssocList * formdata,
313: HTAnchor * anchor,
314: HTRequest * request);
315: </PRE>
316: <H2>
2.87 frystyk 317: <A NAME="PostForms">Submit Forms Using POST Method</A>
2.79 frystyk 318: </H2>
319: <P>
2.87 frystyk 320: The data in a <CODE>POST</CODE> form is sent as the body part of the
321: <A HREF="http://www.w3.org/Protocols/">HTTP</A> message whereas a
322: <CODE>GET</CODE> form wraps it all up into the URI. In order to be able to
2.85 frystyk 323: use the <CODE>POST</CODE> data object at a later point in time, we create
2.87 frystyk 324: a new anchor on the fly. This anchor has a URI file location which points
2.79 frystyk 325: into the temporary area given by the <A HREF="HTUser.html">User Profile
2.80 frystyk 326: Object</A>. That is - you can actually save the anchor using a
327: <CODE>PUT</CODE> request and then be able to retrive the form data at a later
328: point in time. Even though this may seem "ambitious" for posting form data,
329: it is really just a special example of sending any kind of data to a remote
330: server. All <CODE>POST</CODE> form functions return the new anchor or
331: <CODE>NULL</CODE> if they fail.
2.79 frystyk 332: <H3>
2.87 frystyk 333: Submit Form from Absolute URI using POST
2.79 frystyk 334: </H3>
335: <P>
2.87 frystyk 336: Submit formdata using POST to the address indicated as the "base" which must
337: be an absolute URI. The list of form data must be given as an
338: <A HREF="HTAssoc.html">association list</A> where the name is the field name
339: and the value is the value of the field.
2.79 frystyk 340: <PRE>
341: extern HTParentAnchor * HTPostFormAbsolute (HTAssocList * formdata,
342: const char * base,
343: HTRequest * request);
344: </PRE>
345: <H3>
2.87 frystyk 346: Submit Form from a Relative URI using GET
2.79 frystyk 347: </H3>
348: <P>
2.87 frystyk 349: Submit formdata using POST to the address indicated relative to the address
350: of the base anchor. The list of form data must be given as an association
351: list where the name is the field name and the value is the value of the field.
2.79 frystyk 352: <PRE>
353: extern HTParentAnchor * HTPostFormRelative (HTAssocList * formdata,
354: const char * relative,
355: HTParentAnchor * base,
356: HTRequest * request);
357: </PRE>
358: <H3>
2.87 frystyk 359: Submit Form using an Anchor and the POST Method
2.79 frystyk 360: </H3>
361: <P>
2.87 frystyk 362: Submit formdata using POST to the address indicated of the anchor. The list
363: of form data must be given as an <A HREF="HTAssoc.html">association list</A>
364: where the name is the field name and the value is the value of the field.
2.79 frystyk 365: <PRE>
366: extern HTParentAnchor * HTPostFormAnchor (HTAssocList * formdata,
367: HTAnchor * anchor,
368: HTRequest * request);
369: </PRE>
2.85 frystyk 370: <H3>
2.87 frystyk 371: Submit Form and Save the Result in a Memory Buffer
2.85 frystyk 372: </H3>
373: <P>
2.87 frystyk 374: Submit formdata to the address referred to by the
375: <A HREF="HTAnchor.html">HTAnchor object</A> and load the result of the POST
376: into a <A HREF="HTChunk.html">HTChunk object</A>. A
377: <A HREF="HTChunk.html">chunk object</A> is a dynamic memory buffer so in
378: the end you will have a single memory buffer containing the document. The
379: chunk must be freed by the caller.
2.85 frystyk 380: <PRE>
381: extern HTChunk * HTPostFormAnchorToChunk (HTAssocList * formdata,
382: HTAnchor * anchor,
383: HTRequest * request);
384: </PRE>
2.77 frystyk 385: <H2>
2.80 frystyk 386: <A NAME="Head">Get Metainformation about a Document (Method = HEAD)</A>
2.79 frystyk 387: </H2>
388: <P>
389: If you are not interested in the document itself but only in the
2.87 frystyk 390: <I>metainformation</I> that <I>describes</I> the document then you should
391: use the <CODE>HEAD</CODE> method in your request.
2.79 frystyk 392: <H3>
2.87 frystyk 393: Get Metainformation about a Document from Absolute URI
2.79 frystyk 394: </H3>
395: <P>
396: Request metainfomration about a document referencd by an <I>absolute</I>
2.87 frystyk 397: URI.
2.79 frystyk 398: <PRE>extern BOOL HTHeadAbsolute (const char * url, HTRequest * request);
399: </PRE>
400: <H3>
2.87 frystyk 401: Get Metainformation about a Document from Relative URI
2.79 frystyk 402: </H3>
403: <P>
404: Request metainformation about a document referenced by a <I>relative</I>
2.87 frystyk 405: URI.
2.79 frystyk 406: <PRE>extern BOOL HTHeadRelative (const char * relative,
407: HTParentAnchor * base,
408: HTRequest * request);
409: </PRE>
410: <H3>
411: Get Metainformation about a Document using an Anchor
412: </H3>
413: <P>
2.87 frystyk 414: Here the URI is represented by an <A HREF="HTAnchor.html">Anchor object</A>.
415: You can get an anchor object representing a URI by passing the URI to the
2.79 frystyk 416: approproiate method in the <A HREF="HTAnchor.html">Anchor class</A>.
417: <PRE>extern BOOL HTHeadAnchor (HTAnchor * anchor, HTRequest * request);
418: </PRE>
419: <H2>
2.80 frystyk 420: <A NAME="Delete">Delete a Document (Method = DELETE)</A>
2.79 frystyk 421: </H2>
422: <P>
423: If you want to delete a document (or make the document inaccessible for future
424: references) then you can use the <CODE>DELETE</CODE> method in your request.
425: <H3>
2.87 frystyk 426: Delete a Document from Absolute URI
2.79 frystyk 427: </H3>
428: <P>
429: Request metainfomration about a document referencd by an <I>absolute</I>
2.87 frystyk 430: URI.
2.79 frystyk 431: <PRE>extern BOOL HTDeleteAbsolute (const char * url, HTRequest * request);
432: </PRE>
433: <H3>
2.87 frystyk 434: Delete a Document from Relative URI
2.79 frystyk 435: </H3>
436: <P>
437: Request metainformation about a document referenced by a <I>relative</I>
2.87 frystyk 438: URI.
2.79 frystyk 439: <PRE>extern BOOL HTDeleteRelative (const char * relative,
440: HTParentAnchor * base,
441: HTRequest * request);
442: </PRE>
443: <H3>
444: Delete a Document using an Anchor
445: </H3>
446: <P>
2.87 frystyk 447: Here the URI is represented by an <A HREF="HTAnchor.html">Anchor object</A>.
448: You can get an anchor object representing a URI by passing the URI to the
2.79 frystyk 449: approproiate method in the <A HREF="HTAnchor.html">Anchor class</A>.
450: <PRE>extern BOOL HTDeleteAnchor (HTAnchor * anchor, HTRequest * request);
451: </PRE>
452: <H2>
2.87 frystyk 453: <A NAME="SaveASIS">Save a Document ASIS From Memory (Method = PUT)</A>
2.80 frystyk 454: </H2>
455: <P>
2.87 frystyk 456: If you already have a document in memory and it is associated with an
457: <A HREF="HTAnchor.html">Anchor object</A> then you can PUT this document
458: to a remote server using the following methods. Other information that you
459: can set in the anchor is metadata like the media type, the document length,
460: the language, or any other information that you want to associate with the
461: document to be uploaded.
462: <P>
463: This set of functions takes the document <B>ASIS</B> - that it the
464: <I>exact</I> content of the document associated with this anchor will be
465: sent to the remote server. If your anchor represents a structured content
2.80 frystyk 466: and the document itself is a parse tree, for example, then you can use the
2.87 frystyk 467: <A HREF="#SaveStructured">structured PUT functions</A>.
2.80 frystyk 468: <P>
2.87 frystyk 469: If your application is an editor, then you may want to create a new anchor
2.80 frystyk 470: on the fly for temporary backups on local disk before you save it to a remote
2.87 frystyk 471: server. An easy way to get a new anchor with a local file URI is to use the
472: <A HREF="HTHome.html#temp">HTTmpAnchor</A> function which is part of the
473: <A HREF="WWWApp.html">WWWApp interface</A>.
2.80 frystyk 474: <H3>
2.87 frystyk 475: Save a Document ASIS from Memory Using Absolute URI (PUT)
2.80 frystyk 476: </H3>
477: <P>
2.87 frystyk 478: The source is an anchor with the contents already in memory and the destination
479: is an absolute URI.
2.80 frystyk 480: <PRE>
481: extern BOOL HTPutAbsolute (HTParentAnchor * source,
482: const char * destination,
483: HTRequest * request);
484: </PRE>
485: <H3>
2.87 frystyk 486: Save a Document ASIS from Memory Using Relative URI (PUT)
2.80 frystyk 487: </H3>
488: <P>
2.87 frystyk 489: The source is an anchor with the contents already in memory and the destination
490: is a relative URI relative to the destination anchor
2.80 frystyk 491: <PRE>
492: extern BOOL HTPutRelative (HTParentAnchor * source,
493: const char * relative,
494: HTParentAnchor * destination_base,
495: HTRequest * request);
496: </PRE>
497: <H3>
2.87 frystyk 498: Save a Document ASIS from Memory Using an Anchor (PUT)
2.80 frystyk 499: </H3>
500: <P>
2.87 frystyk 501: Both the source and the anchor are anchor objects. The source anchor already
502: has the contents in memory
2.80 frystyk 503: <PRE>
504: extern BOOL HTPutAnchor (HTParentAnchor * source,
505: HTAnchor * dest,
506: HTRequest * request);
507: </PRE>
508: <H2>
509: <A NAME="SaveStructured">Save a Structured Document (Using PUT)</A>
2.77 frystyk 510: </H2>
2.80 frystyk 511: <P>
2.87 frystyk 512: If you want to save a document from memory but it contains structured information
513: (for example, it is in the form of a parse tree) then you can use this interface.
514: The only difference from above is that the caller must provide the function
515: that provides data while sending it accross the network - we can't just take
516: it as a block. You can for example have a look at the
517: <CODE>HTEntity_callback</CODE> function which is used in the
518: <A HREF="#SaveASIS"><B>ASIS</B> interface</A> if you want to write your own
519: data feeding method.
520: <H3>
521: Save a Structured Document from Memory to Absolute URI (PUT)
522: </H3>
523: <P>
524: Upload a document referenced by an absolute URI.
2.80 frystyk 525: <PRE>
526: extern BOOL HTPutStructuredAbsolute (HTParentAnchor * source,
527: const char * destination,
528: HTRequest * request,
529: HTPostCallback * input);
530: </PRE>
531: <H3>
2.87 frystyk 532: Save a Structured Document from Memory to Relative URI (PUT)
2.80 frystyk 533: </H3>
534: <P>
2.87 frystyk 535: The source is an anchor with the contents already in memory and the destination
536: is a relative URI relative to the destination anchor
2.80 frystyk 537: <PRE>
538: extern BOOL HTPutStructuredRelative (HTParentAnchor * source,
539: const char * relative,
540: HTParentAnchor * destination_base,
541: HTRequest * request,
542: HTPostCallback * input);
543: </PRE>
544: <H3>
545: Save a Structured Document Using an Anchor and the PUT Method
546: </H3>
547: <P>
2.87 frystyk 548: The source is an anchor with the contents already in memory and the destination
549: is a relative URI. The HTPostCallback function type is declared in the HTRequest
2.80 frystyk 550: object.
551: <PRE>
552: extern BOOL HTPutStructuredAnchor (HTParentAnchor * source,
553: HTAnchor * destination,
554: HTRequest * request,
555: HTPostCallback * input);
556: </PRE>
557: <H2>
2.87 frystyk 558: <A NAME="SaveURL">Save a Remote Document (Using PUT)</A>
2.80 frystyk 559: </H2>
560: <P>
2.87 frystyk 561: If the content of the document associated with the anchor is <B>NOT</B> in
562: memory then you can use this interface. These methods make two requests:
563: first they go out and get the source which can be on an FTP server, on local
564: disk, on another HTTP server etc. and then they PUT this document ASIS to
565: the destination HTTP server.
2.80 frystyk 566: <H3>
2.87 frystyk 567: Save a Document from Absolute URI using PUT
2.80 frystyk 568: </H3>
569: <P>
2.87 frystyk 570: Get the source and PUT it to the destination which is an absolute URI
2.80 frystyk 571: <PRE>
572: extern BOOL HTPutDocumentAbsolute (HTParentAnchor * source,
573: const char * destination,
574: HTRequest * request);
575: </PRE>
576: <H3>
2.87 frystyk 577: Save a Document from Relative URI using PUT
2.80 frystyk 578: </H3>
579: <P>
2.87 frystyk 580: Get the source and PUT it to the destination which is a relative URI
2.80 frystyk 581: <PRE>
582: extern BOOL HTPutDocumentRelative (HTParentAnchor * source,
583: const char * relative,
584: HTParentAnchor * destination_base,
585: HTRequest * request);
586: </PRE>
587: <H3>
588: Save a Document Using an Anchor and the PUT Method
589: </H3>
590: <P>
2.87 frystyk 591: Get the source and PUT it to the destination which is an anchor object.
2.80 frystyk 592: <PRE>
593: extern BOOL HTPutDocumentAnchor (HTParentAnchor * source,
594: HTAnchor * destination,
595: HTRequest * request);
596: </PRE>
597: <H2>
2.87 frystyk 598: <A NAME="PostASIS">Post a Document from Memory ASIS (Method = POST)</A>
2.81 frystyk 599: </H2>
600: <P>
2.87 frystyk 601: If you already have a document in memory and it is associated with an
602: <A HREF="HTAnchor.html">Anchor object</A> then you can POST this document
603: to a remote server using the following methods. Other information that you
604: can set in the anchor is metadata like the media type, the document length,
605: the language, or any other information that you want to associate with the
606: document to be uploaded.
2.81 frystyk 607: <P>
2.87 frystyk 608: This set of functions takes the document <B>ASIS</B> - that it the
609: <I>exact</I> content of the document associated with this anchor will be
610: sent to the remote server.
2.81 frystyk 611: <P>
2.87 frystyk 612: If your application is an editor, then you may want to create a new anchor
2.81 frystyk 613: on the fly for temporary backups on local disk before you save it to a remote
2.87 frystyk 614: server. An easy way to get a new anchor with a local file URI is to use the
615: <A HREF="HTHome.html#temp">HTTmpAnchor</A> function which is part of the
616: <A HREF="WWWApp.html">WWWApp interface</A>.
2.81 frystyk 617: <H3>
2.87 frystyk 618: Post a Document from Memory ASIS using Absolute URI (POST)
2.81 frystyk 619: </H3>
620: <P>
2.87 frystyk 621: Upload a document using POST referenced by an absolute URI.
2.81 frystyk 622: <PRE>
623: extern BOOL HTPostAbsolute (HTParentAnchor * source,
624: const char * destination,
625: HTRequest * request);
626: </PRE>
627: <H3>
2.87 frystyk 628: Post a Document from Memory ASIS using Relative URI (POST)
2.81 frystyk 629: </H3>
630: <P>
2.87 frystyk 631: Upload a document using POST referenced by a relative URI.
2.81 frystyk 632: <PRE>
633: extern BOOL HTPostRelative (HTParentAnchor * source,
634: const char * relative,
635: HTParentAnchor * destination_base,
636: HTRequest * request);
637: </PRE>
638: <H3>
2.87 frystyk 639: Post a Document from Memory ASIS using an Anchor (POST)
2.81 frystyk 640: </H3>
641: <P>
2.87 frystyk 642: POST an anchor - here both the source and the anchor are anchor objects.
643: The source anchor already has the contents in memory.
2.81 frystyk 644: <PRE>
645: extern BOOL HTPostAnchor (HTParentAnchor * source,
646: HTAnchor * dest,
647: HTRequest * request);
648: </PRE>
649: <H2>
2.87 frystyk 650: <A NAME="OPTIONS">Get Available Options for a Document (Method = OPTIONS)</A>
2.80 frystyk 651: </H2>
652: <P>
653: If you want to get information about a document then you can use the the
654: <CODE>OPTIONS</CODE> method in your request. The <CODE>OPTIONS</CODE> method
655: represents a request for information about the communication options available
2.82 frystyk 656: on the request/response chain identified by the <CODE>Request-URI</CODE>.
657: This method allows the client to determine the options and/or requirements
658: associated with a resource, or the capabilities of a server, without implying
659: a resource action or initiating a resource retrieval.
660: <P>
661: A speciality about the <CODE>OPTIONS</CODE> method is that the client can
662: issue a request with no pathinfo at all but only with a "<CODE>*</CODE>".
663: That is, the request line can look like this "<CODE>OPTIONS * HTTP/1.1</CODE>".
664: This means that we request information about the server as a whole and not
2.87 frystyk 665: only about a single URI. You can get this effect by using a URI containing
2.82 frystyk 666: the hostname alone with <B>NO</B> extra slash at the end, for example
667: <CODE>http://www.w3.org</CODE>, <CODE>http://www.cern.ch</CODE>.
2.80 frystyk 668: <H3>
2.87 frystyk 669: Options Available for Document from Absolute URI
2.80 frystyk 670: </H3>
671: <P>
2.87 frystyk 672: Request options about a document referencd by an <I>absolute</I> URI.
2.80 frystyk 673: <PRE>extern BOOL HTOptionsAbsolute (const char * url, HTRequest * request);
674: </PRE>
675: <H3>
2.87 frystyk 676: Options Available for Document from Relative URI
2.80 frystyk 677: </H3>
678: <P>
2.87 frystyk 679: Request options about a document referenced by a <I>relative</I> URI.
2.80 frystyk 680: <PRE>extern BOOL HTOptionsRelative (const char * relative,
681: HTParentAnchor * base,
682: HTRequest * request);
683: </PRE>
684: <H3>
685: Options Available for Document using an Anchor
686: </H3>
687: <P>
2.87 frystyk 688: Here the URI is represented by an <A HREF="HTAnchor.html">Anchor object</A>.
689: You can get an anchor object representing a URI by passing the URI to the
2.80 frystyk 690: appropriate method in the <A HREF="HTAnchor.html">Anchor class</A>.
691: <PRE>extern BOOL HTOptionsAnchor (HTAnchor * anchor, HTRequest * request);
692: </PRE>
693: <H2>
2.87 frystyk 694: <A NAME="TRACE">Get Trace Loop back Information for a Document (Method =
695: TRACE)</A>
2.82 frystyk 696: </H2>
697: <P>
698: The TRACE method is used to invoke a remote, application-layer loop-back
699: of the request message. The final recipient of the request SHOULD reflect
700: the message received back to the client as the entity-body of a 200 (OK)
701: response. The final recipient is either the origin server or the first proxy
702: or gateway to receive a Max-Forwards value of zero (0) in the request (see
703: section 14.31). A TRACE request MUST NOT include an entity.
704: <P>
705: TRACE allows the client to see what is being received at the other end of
706: the request chain and use that data for testing or diagnostic information.
707: The value of the Via header field (section 14.44) is of particular interest,
708: since it acts as a trace of the request chain. Use of the Max-Forwards header
709: field allows the client to limit the length of the request chain, which is
710: useful for testing a chain of proxies forwarding messages in an infinite
711: loop.
712: <P>
713: If successful, the response SHOULD contain the entire request message in
714: the entity-body, with a Content-Type of <CODE>"message/http"</CODE>. Responses
715: to this method MUST NOT be cached.
716: <H3>
2.87 frystyk 717: Traces Available for Document from Absolute URI
2.82 frystyk 718: </H3>
719: <P>
2.87 frystyk 720: Request traces about a document referencd by an <I>absolute</I> URI.
2.82 frystyk 721: <PRE>extern BOOL HTTraceAbsolute (const char * url, HTRequest * request);
722: </PRE>
723: <H3>
2.87 frystyk 724: Traces Available for Document from Relative URI
2.82 frystyk 725: </H3>
726: <P>
2.87 frystyk 727: Request traces about a document referenced by a <I>relative</I> URI.
2.82 frystyk 728: <PRE>extern BOOL HTTraceRelative (const char * relative,
729: HTParentAnchor * base,
730: HTRequest * request);
731: </PRE>
732: <H3>
733: Traces Available for Document using an Anchor
734: </H3>
735: <P>
2.87 frystyk 736: Here the URI is represented by an <A HREF="HTAnchor.html">Anchor object</A>.
737: You can get an anchor object representing a URI by passing the URI to the
2.82 frystyk 738: appropriate method in the <A HREF="HTAnchor.html">Anchor class</A>.
739: <PRE>extern BOOL HTTraceAnchor (HTAnchor * anchor, HTRequest * request);
740: </PRE>
741: <H2>
2.89 ! frystyk 742: <A NAME="serve">Serve a Request</A>
2.88 frystyk 743: </H2>
744: <P>
745: Although libwww is primarily for clients, it is in fact symmetric in that
746: it can handle both client requests and server requests. The way this is handled
747: is that each <A HREF="HTProt.html">protocol</A> is registered with both a
748: client handler and a server handler - depending on which type of request
749: you use, one of them is called. Note that in order to be able to serve any
750: document, there actually have to be a server handler. However, libwww only
751: comes with a <A HREF="HTSocket.html">raw socket loader</A> which isn't much
752: of a server. There is an <A HREF="HTTPServ.html">attempt of an HTTP server</A>
753: but it is not complete
754: <P>
755: The protocol handler used to serve the request is determined by the URI -
756: just as for client side requests. That is, libwww can in fact simultaneously
757: be the server for multiple protocols if you really want to. Examples of URIs
758: that you can use are <TT>noop://localhost:8888</TT> which means that libwww
759: starts listening on port 8888 (see the <A HREF="../Examples/listen.c">listen
760: example</A> for details). Other examples are <TT>http://localhost:7777</TT>
761: which means that it listens for HTTP on port 7777. Again, there is no HTTP
762: server in libwww - this is just an example.
763: <PRE>
764: extern BOOL HTServeAbsolute (const char * address, HTRequest * request);
765: </PRE>
766: <H2>
2.87 frystyk 767: Save a URI To Multiple Destinations - Not supported!!!
2.80 frystyk 768: </H2>
769: <P>
2.87 frystyk 770: <STRONG>Note: This is no longer supported</STRONG>
2.80 frystyk 771: <P>
772: These are the generic versions of the <CODE>PUT</CODE> and <CODE>POST</CODE>
773: functions. They can be used to send documents to multiple destinations
774: simultanously using the PostWeb model.
2.77 frystyk 775: <H3>
2.87 frystyk 776: Copy an anchor - not supported
2.77 frystyk 777: </H3>
778: <P>
2.87 frystyk 779: Fetch the URI from either local file store <B>or</B> from a remote HTTP server
2.77 frystyk 780: and send it using either PUT or POST to the remote destination using HTTP.
781: The caller can decide the exact method used and which HTTP header fields
782: to transmit by setting the user fields in the request structure. If posting
783: to NNTP then we can't dispatch at this level but must pass the source anchor
784: to the news module that then takes all the refs to NNTP and puts into the
785: "newsgroups" header Returns YES if request accepted, else NO
2.78 frystyk 786: <PRE>extern BOOL HTCopyAnchor (HTAnchor * src_anchor, HTRequest * main_req);
2.47 frystyk 787: </PRE>
2.77 frystyk 788: <H3>
2.87 frystyk 789: Upload an Anchor - not supported
2.77 frystyk 790: </H3>
791: <P>
792: This function can be used to send data along with a request to a remote server.
793: It can for example be used to POST form data to a remote HTTP server - or
794: it can be used to post a newsletter to a NNTP server. In either case, you
795: pass a callback function which the request calls when the remote destination
796: is ready to accept data. In this callback you get the current request object
797: and a stream into where you can write data. It is very important that you
798: return the value returned by this stream to the Library so that it knows
799: what to do next. The reason is that the outgoing stream might block or an
800: error may occur and in that case the Library must know about it. If you do
2.71 frystyk 801: not want to handle the stream interface yourself then you can use the
2.79 frystyk 802: <CODE>HTUpload_callback</CODE> which is declared below. The source anchor
803: represents the data object in memory and it points to the destination anchor
804: by using the <A HREF="../User/Architecture/PostWeb.html">POSTWeb method</A>.
805: The source anchor contains metainformation about the data object in memory
806: and the destination anchor represents the reponse from the remote server.
807: Returns YES if request accepted, else NO
2.78 frystyk 808: <PRE>extern BOOL HTUploadAnchor (HTAnchor * source_anchor,
2.71 frystyk 809: HTRequest * request,
810: HTPostCallback * callback);
811: </PRE>
2.77 frystyk 812: <H3>
2.87 frystyk 813: POST Callback Handler - not supported
2.77 frystyk 814: </H3>
815: <P>
816: Is you do not want to handle the stream interface on your own, you can use
817: this "middleman" function which does the actual writing to the target stream
818: for the anchor upload and also handles the return value from the stream.
819: Now, your application is called via the callback function that you may associate
820: with a request object. You indicate when you have sent all the data you want
821: by returning HT_LOADED from the callback.
2.43 frystyk 822: <PRE>
2.72 frystyk 823: extern int HTUpload_callback (HTRequest * request, HTStream * target);
2.46 frystyk 824: </PRE>
2.25 luotonen 825: <PRE>
2.63 frystyk 826: #endif /* HTACCESS_H */
2.38 howcome 827: </PRE>
2.77 frystyk 828: <P>
829: <HR>
2.75 frystyk 830: <ADDRESS>
2.89 ! frystyk 831: @(#) $Id: HTAccess.html,v 2.88 1998/12/15 05:34:27 frystyk Exp $
2.75 frystyk 832: </ADDRESS>
2.77 frystyk 833: </BODY></HTML>
Webmaster