Data Port

© 2005 Goetz Heller

Table of Contents Copyright Note back

Using HTML <META> Tags as Data Headers

It is quite common that during exchange of data some meta information about the data is needed which goes beyond structural information, which is delivered using XML. The most natural candidate to serve this purpose is the HTML <META> element, and exactly this idea applies in the dataPort framework. Meta has two attributes defined which we will be using throughout: name and content.

The kind of information transported via this mechanism can be classified into several domains. This classification is reflected by a prefix to the name attribute value, and is as follows:

prefixdomain
prgeneral processing
errerror handling
secsecurity related
sessession state handling
trtransport related processing directives

The following table summarizes the information pieces which have been identified so far to be useful in data headers.

namecontent
prRetValthe return code issued by the server side processing module
prHandleridentifies a client-side routine to process the message body contents. This is meant to support workflow branching the decision point for which was met on the server.
errCodecode of an error condition detected by the server side processing module
errTexterror message text
secAuthMethodrequired authentication method
secChallengea challenge to be responded to by the client to prove authenticity
secSrvIdthe encrypted servername which proves the server's identity
secEncryptionMethodidentifies the algorithm used to encrypt the data
secKeyencrypted key. the decrypted key can be used to decrypt the data
sesSidserver side session identifier
trBase64indicates that contents of message body need to be base64-decoded
trCompressedindicates that contents of message body need to be decrompressed

Note that the meta tag named prRetVal should not return application specific semantics to ease creation of standardized general protocol handling routines. Rather it should indicate normal termination, failure to handle a request (which refers to the error related meta tags for details), acknowledgement of a request, acknowledgement of a request with delayed processing and the like. Application specific information should be transported inside the message body. For the same reason, error information transported via err-meta tags should not be to specific. It should be sufficient to display a meaningful message to the user. Detailed error information (trace lists, faulty parameters etc.) should be placed into an error report inside the body. In combination with prHandler this should provide for enough flexibility to implement application specific error handling.