Henrik Frystyk, July 1994

WWW Icon Client Interface for Posting

This document describes the posting interface between a World-Wide Web client and the Library of Common Code. The design has been made so that the interface is flexible enough to support not only the POST method in the HTTP Protocol, but at the same time provide functionality for posting to email addresses using SMTP and NNTP news groups. Posting to other Internet servers such as FTP servers is not considered in this document, but the concept is designed with the possibility of including additional Internet protocols.

The document only describes the Client interface to the library but not how the actual posting should take place using the HTTP protocol. A draft specification is under development but has not been completed at this point (August 1994).

Building a POST Web

The basic idea of the post interface to the library is that when using POST, the user is often interested in posting the data object to more than one recipient, e.g. the user can send the same data object to two mailing lists, a news group and at the same time store the data object as a file on a remote HTTP server. The term "data object" is used instead of "document" because the object to be posted can be in any MIME format and furthermore, it can be compressed or encoded before transmission.

As indicated in the figure, the user builds a "POST Web" around an anchor element before the POST is committed and passed to the library. The rounded boxes are remote logical data objects that are still to be created and the lines are logical links between the post anchor and the remote data objects. The two links to the NNTP box represents that the data object is to be posted to two different news groups. In practice only one physical link would actually exist to the NNTP as all posting to a NNTP Server is done in one single transaction.

The actual user interface is for the client to implement, but typically a GUI-client could use drag-and-drop icons for building the Web. The POST Web could be visualized using a user implemented menu of icons of the most used recipients and then let the user drag lines between the data object to be posted and the recipients. The CERN library helps the user building the Web by providing the functionality of linking the anchors together.

Posting a Document

When the user has decided to commit the POST, the post anchor is passed from the client to the library together with a request structure. This is very similar to the current implementation of a HTTP GET Method. An important consideration in the design has been to include the multi-threaded functionality in the posting module so that both PUT and POST in principle behaves exactly like a GET or any other method using non-blocking I/O, see also the multi-threaded control flow.

However, PUT and POST methods are inherently different from the GET method as they require a data flow in both directions. This is especially the case using PUT as a data object often will be returned from the remote server.

The routine for handling the POST in the library parses the POST Web and groups the individual requests into protocol categories. In the case of a NNTP request, all POST requests are handled at the same time and send to the actual NNTP server. When the parsing of the Web is done, the post module recursively calls the protocol modules to execute the POST.

The posting mechanism is designed to be compatible with the multi-threaded structure of the library. This means that the client is asked for data based on an event driven action taken by the event loop. The client then gets a stream so that the document to be posted can be pumped down the stream and out on the net.

Handling the POST Result

The result of the posting varies as a function of the protocol used. It is a general rule through out the design of the Library of Common Code that other protocols than HTTP should be supported but not extended beyond their individual limitations. This means that the library has to be flexible enough to handle more than one result from a posting transaction dependent on the protocol used.

An immediate result from a post transaction is available using NNTP or HTTP but when using SMTP, the result might be delayed several days. In practice there is no way that the client can await a response for that amount of time. Therefore it is proposed to introduce "sentto" as a new URI scheme specifically to indicate the state of the posting to a mail address. This code means that the data object has been posted but no guarantee is given whether the recipient has actually received the data object or if the data object has been modified under the posting transaction. However, note that even on a successful return code from the server, the user is not guaranteed that the posting action has actually been executed or that the posted data object will not be changed or deleted. The returned URLs from the posting will therefore have the following syntax:

http://remote.server/local/location/foo.bar
The syntax of the generated HTTP URL as a result of a succeeded posting is identical to any other HTTP URL
news:messageid@news.host
The message ID is a unique string generated by the library NNTP Module.
sentto:recipient@host.name
As the success of a mail posting can not be guaranteed, the access scheme has changed from "mailto" to "sentto". Then it is for the user or client to decide what to do with the URL. One solution could be to keep a copy of the posted document in a local cache for a limited time period. Though it is not foreseen that the World-Wide Web client can actually handle delayed return codes from the SMTP protocol, as the client can in fact be a HTTP Proxy server.
In the figure, postings using SMTP are still rounded because it is not possible for the user to actually access the document using the URL returned from the library. As the NNTP posting failed in the figure, the document is still non-existent. Only the HTTP posting has turned into a physical document reference on the remote server.

When all postings are terminated, a new anchor is generated containing the allocated links on the remote servers for future references (except in the SMTP case). The amount of links returned might be a subset of the requested recipients as only postings which terminated successfully are registered. Using this set, the client must determine what to do with failed postings. One possibility would be to try again using the failed part of the POST Web, or simply to discard it.

Summary

This document describes the posting interface between the client application and the World-Wide Web Library of Common Code. The user first builds a "POST Web" where logical links are created between the document to be posted and the set of desired recipients. On commit of the posting the POST web and a request structure is parsed to the general posting routine within the library. The posting routine groups the postings and recursively calls the NNTP, SMTP and or the HTTP module of the library until the POST Web is traversed. The NNTP module is only done once due to the NNTP protocol implementation of posting.

The "sentto" access scheme has been proposed as a new URI access scheme to compensate for the fact that when posting to a SMTP server, no guarantee is given that the data object has actually reached the recipient.

As mentioned in the introduction this document doesn't describe how the HTTP protocol should handle POST as this is all handled internally in the Library. However, the interface between the Library and the client stays the same regardless of the HTTP POST Implementation.

Henrik Frystyk, frystyk@info.cern.ch, July 1994