<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head profile="http://internetalchemy.org/2003/02/profile">
<link rel="foaf" type="application/rdf+xml" title="FOAF" href="http://www.openlinksw.com/dataspace/uda/about.rdf" />
<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
<meta name="dc.title" content="17. Internet Services" />
<meta name="dc.subject" content="17. Internet Services" />
<meta name="dc.creator" content="OpenLink Software Documentation Team ; " />
<meta name="dc.copyright" content="OpenLink Software, 1999 - 2009" />
<link rel="top" href="index.html" title="OpenLink Virtuoso Universal Server: Documentation" />
<link rel="search" href="/doc/adv_search.vspx" title="Search OpenLink Virtuoso Universal Server: Documentation" />
<link rel="parent" href="internetservices.html" title="Chapter Contents" />
<link rel="prev" href="nntpnewsgroups.html" title="NNTP Newsgroups" />
<link rel="next" href="ftpservices.html" title="FTP Services" />
<link rel="shortcut icon" href="../images/misc/favicon.ico" type="image/x-icon" />
<link rel="stylesheet" type="text/css" href="doc.css" />
<link rel="stylesheet" type="text/css" href="/doc/translation.css" />
<title>17. Internet Services</title>
<meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8" />
<meta name="author" content="OpenLink Software Documentation Team ; " />
<meta name="copyright" content="OpenLink Software, 1999 - 2009" />
<meta name="keywords" content="" />
<meta name="GENERATOR" content="OpenLink XSLT Team" />
</head>
<body>
<div id="header">
<a name="mime" />
<img src="../images/misc/logo.jpg" alt="" />
<h1>17. Internet Services</h1>
</div>
<div id="navbartop">
<div>
<a class="link" href="internetservices.html">Chapter Contents</a> | <a class="link" href="nntpnewsgroups.html" title="NNTP Newsgroups">Prev</a> | <a class="link" href="ftpservices.html" title="FTP Services">Next</a>
</div>
</div>
<div id="currenttoc">
<form method="post" action="/doc/adv_search.vspx">
<div class="search">Keyword Search: <br />
<input type="text" name="q" /> <input type="submit" name="go" value="Go" />
</div>
</form>
<div>
<a href="http://www.openlinksw.com/">www.openlinksw.com</a>
</div>
<div>
<a href="http://docs.openlinksw.com/">docs.openlinksw.com</a>
</div>
<br />
<div>
<a href="index.html">Book Home</a>
</div>
<br />
<div>
<a href="contents.html">Contents</a>
</div>
<div>
<a href="preface.html">Preface</a>
</div>
<br />
<div class="selected">
<a href="internetservices.html">Internet Services</a>
</div>
<br />
<div>
<a href="webdavserver.html">WebDAV Server</a>
</div>
<div>
<a href="uriqa.html">URIQA Semantic Web Enabler</a>
</div>
<div>
<a href="maildelivstore.html">Mail Delivery & Storage</a>
</div>
<div>
<a href="nntpnewsgroups.html">NNTP Newsgroups</a>
</div>
<div class="selected">
<a href="mime.html">MIME & Internet Messages</a>
<div>
<a href="#aboutinternetmsgs" title="About Simple Internet (RFC 822) Messages">About Simple Internet (RFC 822) Messages</a>
<a href="#mimesupport" title="MIME Messages - Extension to Simple Internet Messages">MIME Messages - Extension to Simple Internet Messages</a>
<a href="#smime" title="S/MIME Support">S/MIME Support</a>
</div>
</div>
<div>
<a href="ftpservices.html">FTP Services</a>
</div>
<div>
<a href="vspguide.html">VSP Guide</a>
</div>
<div>
<a href="ldap.html">LDAP</a>
</div>
<br />
</div>
<div id="text">
<a name="mime" />
<h2>17.5. MIME & Internet Messages</h2>
<a name="aboutinternetmsgs" />
<h3>17.5.1. About Simple Internet (RFC 822) Messages</h3>
<p>RFC 822 messages have two major parts: </p>
<ul>
<li>
<div class="formalpara">
<strong>Message envelope</strong>
<p>The message envelope contains all the information needed to accomplish
transmission and delivery of the message. This information includes the e-mail
address of the message's creator — also known as the originator. This string
matches the information in the Sender: header, if this header is present.
The envelope is created by a user agent (such as MS Outlook) and is meaningful
only to the message transfer agents (MTAs) that move the message on the path
to its destination. </p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Message contents</strong>
<p>The contents make up the object to be delivered to the recipient.
Message contents consist of lines of ASCII text. This text is arranged in the
classic "memo" format, in which the message contains one or more introductory
headers and a body. </p>
</div>
</li>
</ul>
<p>This structure can be seen in the following illustration:</p>
<table class="figure" border="0" cellpadding="0" cellspacing="0">
<tr>
<td>
<img alt="The structure of an Internet mail" src="../images/internetmailmsg.jpg" />
</td>
</tr>
<tr>
<td>Figure: 17.5.1.1. The structure of an Internet mail</td>
</tr>
</table>
<a name="ex_simplemailmsg" />
<div class="example">
<div class="exampletitle">Simple Internet Mail Message</div>
<p>As you can see in the following sample of a message's contents,
the format described in RFC 822 produces messages readable with little
difficulty by humans. </p>
<p>The first few lines, from the first instance of "Received" to "Precedence",
are headers. These lines define the recipients, the sender, the date,
and other information involved with message transmission.</p>
<p>Following the headers is a blank line. This is marked by the consecutive
occurrence of the four characters: CR, LF, CR, LF. After this blank line
starts the body of the message. In the following example, only the final few
lines make up the message body.</p>
<div>
<pre class="programlisting">
Received: from techsupp@openlinksw.co.uk
Message-Id: <v1214040cad6a13935723@>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 4 Jun 1998 09:43:14 -0800
To: customer.services@openlinksw.co.uk
From: OpenLink Technical Support <techsupp@openlinksw.co.uk>
Subject: Happy Reading
Precedence: bulk
Hope you are enjoying this chapter,
Technical Support
</pre>
</div>
</div>
<div class="tip">
<div class="tiptitle">See Also:</div>
<p>
<a href="http://www.rfc-editor.org/rfc/rfc822.txt">RFC 822 at www.rfc-editor.org</a>
</p>
</div>
<br />
<a name="mimesupport" />
<h3>17.5.2. MIME Messages - Extension to Simple Internet Messages</h3>
<p>MIME (Multipurpose Internet Mail Extensions) grew out of a need to
encapsulate messages within messages. It includes multipart messages
comprising a variety of file types such as images, audio, and video.
MIME does all this while following all the standard SMTP and RFC 822 mail rules.
MIME messages can be constructed to transport mail over any mail transport
system that is compliant with SMTP. MIME is able to transmit objects with
varying ranges of complexity in a way that allows any MIME-compliant user
agent (UA) to faithfully process them and hand them off to an appropriate
application. The multiple parts are arranged so that the parts requiring the
least sophisticated UA are at the beginning of the message. In fact, most
MIME UAs include courtesy text when constructing messages to give users
of non-MIME UAs an indication of the message content. This courtesy text is
inserted ahead of any MIME parts.</p>
<p>MIME is consistent with Internet mail protocols using headers and
bodies. It allows for transmission of 7-bit printable US-ASCII characters and
maximum 1000-character lines in message bodies over all Internet mail
transports. It has become the most widely used extension to the simple
e-mail standard. It is also used as a transport mechanism in Web pages.</p>
<p>Each content body part is made up of header fields and content.
The headers convey specific information about the content for the message
recipient. The content can be essentially any serialized stream of bytes, such as
binary data or HTML. When necessary, the content is encoded so that the
entire body complies with RFC 822. If the content is encoded, MIME defines
the header Content-Transfer-Encoding to specify the mechanism. Other
details are sometimes included, such as the Content-Disposition, which
indicates to the recipient whether the content is to be treated simply as an
attachment, or whether it is to be rendered inline with other content in other
body parts.</p>
<a name="ex_mime1" />
<div class="example">
<div class="exampletitle">A simple MIME message sample</div>
<p>Mime message including a picture stored as a file GIF format.
Because .gif files use 8-bit bytes, and the RFC 822 format requires messages
to contain only US-ASCII text, the picture data must be encoded. For the
recipient to correctly decode and display the picture, it needs information
about which encoding mechanism was used. The following example shows part
of a MIME header that identifies that the content is a .gif file, that it is
encoded using the standard base64 algorithm, and that it is to be treated by
the e-mail client as an attachment.</p>
<div>
<pre class="programlisting">
Content-Type: image/gif;
name="picture.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="picture.gif"
[encoded content here]
...
</pre>
</div>
</div>
<p>MIME accomplishes this simplifying and rebuilding of complex files by encoding a
file and transporting it as a message body, or a series of messages with
component parts of the file. A MIME-compliant
user agent (UA) on the receiving end can decode the message, presenting it
to the reader or providing it to another application as a file. A UA that is not
MIME-compliant will be able to process a MIME-encoded mail message, but
may not be able to decode the message. </p>
<p>MIME defines a message format that allows for: </p>
<ul>
<li>Textual message bodies in character sets other than US-ASCII. </li>
<li>Non-textual message bodies. </li>
<li>Multipart message bodies. </li>
<li>Textual header information in character sets other than US-ASCII. </li>
</ul>
<a name="ex_samplemimemesg" />
<div class="example">
<div class="exampletitle">Sample MIME Message</div>
<p>MIME uses headers and separators to tell a UA what processing is
required to re-create the message. An example with no encoded body parts is:</p>
<div>
<pre class="programlisting">
From: OpenLink Support <techsupp@openlinksw.co.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="XXXXboundary text"
This is a multipart message in MIME format.
--XXXXboundary text
Content-Type: text/plain
here is the body text
--XXXXboundary text
Content-Type: text/plain;
Content-Disposition: attachment;
filename="test.txt"
this is the attachment text
--XXXXboundary text--
</pre>
</div>
<p>This example shows the use of a MIME message to send a text message
and an attached text file. Both are body parts of this message. </p>
<p>The "MIME-Version:" header tells the receiving UA to treat this as a MIME message. </p>
<p>The "Content-Type:" header specifies "multipart/mixed". This tells the
receiving UA that this message has parts separated by the string argument
defined in "boundary=". A MIME-compliant UA will only display or otherwise process
content following the specified "boundary=" text strings. The actual
boundaries are constructed using the "boundary=" string, prepended by "--".
The final body part is followed by the "boundary=" string with the "--" both
prepended and appended.</p>
<p>In the preceding example, the courtesy message "This is a multipart
message in MIME format." will not be displayed or otherwise processed by the
MIME UA since it does not follow a "boundary=" string. A UA that does not support
MIME will display it, and at least this part of the message will be readable
no matter what features the reader supports. If our example had encoded
parts, they would make no sense to the human reader using a
non-MIME-compliant UA, but at least the courtesy message would give the
user a hint as to why.</p>
<p>There are two message body parts in our example. Each body part
has headers of its own, in addition to the overall message headers. Each
body-part begins with the boundary string. If there were no headers in the
body parts, then the blank line that must follow headers in RFC 822 messages
would follow the boundary string. The first body part is a plain text message.
It is the message the sender might have typed into a UA. Its single
"Content-Type:" header identifies it as "text/plain", meaning US-ASCII
characters are used exclusively and any UA should be able to display this
body part. Text/plain is the default content type.</p>
<p>The second body part in this example contains the file attachment.
Since the file attachment is an ASCII text file, it is sent with no encoding and
its content-type is given as text/plain. The "Content-Disposition: attachment"
header has an attribute, "filename=", which specifies a suggested name for the
file. This header specifies that this body part is to be treated as a file rather
than being displayed to the user and is to be saved on local storage
under the suggested file name.</p>
</div>
<a name="mimeheaders" />
<h4>17.5.2.1. MIME Headers</h4>
<p>MIME headers appear at the beginning of a MIME message as well as
within the separate body parts. Some MIME headers can be used both as
message headers and in MIME body parts. Some additional headers are defined
for use only in body parts.</p>
<p>The following headers are defined in MIME: </p>
<ul>
<li>
<div class="formalpara">
<strong>MIME-Version </strong>
<p>Required header indicating that this message is to use the rules of
MIME. "MIME-Version: 1.0" is the only currently defined MIME-Version
header allowed. The MIME-Version header is a top-level header only and
does not appear in body parts unless the body part is an encapsulated,
fully formed message of content-type message/rfc822, which might
have its own MIME-Version header.
</p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Content-Type </strong>
<p>Content-Type headers are used to specify the media type and subtype
of data in the body of a message and to fully specify the native representation
of such data. This header embodies much of the power of MIME. The IETF
can add new official content types. Additionally, private content-type values
can be defined by anyone. Such private content types have values of
"x-something" or "X-something", where "something" can take on any value.
</p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Content-Transfer-Encoding </strong>
<p>Content-Transfer-Encoding headers can have two different meanings.
If the value is "base64" or "quoted-printable", then the header indicates the
encoding used for this body part. If the value is "7bit", "8bit", or "binary",
then the header indicates that there is no encoding and that this value indicates
only the type of content this body part contains. The default is "7bit". It should
be noted that "8bit" and "binary" are not guaranteed to be properly handled by all Internet (SMTP) MTAs valid in Internet mail.
Eight bit content is not valid in Internet mail headers.
Provision is made for private Content-Transfer-Encoding headers. These have values that
begin with "x-" or "X-". These are for specialized cases where the users have
the tools to decode or otherwise process a specific "x-" encoding.
</p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Content-ID </strong>
<p>Content-ID headers are world-unique values that identify body
parts, individually or as groups. They are necessary at times to
distinguish body parts and allow cross-referencing between body parts.
</p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Content-Description </strong>
<p>Content-Description headers are optional and are often used to
add descriptive text to non-textual body parts.
</p>
</div>
</li>
<li>
<div class="formalpara">
<strong>Content-Disposition </strong>
<p>Content-Disposition headers provide information about how to present
a message or a body part. When a body part is to be treated as an attached file,
the Content-Disposition header will include a file name attribute.
</p>
</div>
</li>
</ul>
<p>There are additional headers that are applied in specialized situations,
such as Content-Base and Content-Location. All of the "Content-xxx" headers
have defined sub-headers, fields, and/or attributes. Headers that begin
with "Content-" are the only headers that have defined meaning in body parts.
All other body part headers can be ignored and might actually be removed by
message transfer agents (MTAs).</p>
<br />
<a name="mimetree" />
<h4>17.5.2.2. MIME_TREE - MIME parser</h4>
<div class="funcsynopsis">
<div class="funcsynopsis">
<a name="fproto_mime_tree" />
<span class="funcdef">array <a href="fn_mime_tree.html">
<span class="function">mime_tree</span>
</a>
</span>
(<span class="paramdef">in <span class="parameter">message_text</span> string</span>,
<span class="paramdefoptional">[in <span class="optional">flag</span> integer ]</span>);
</div>
</div>
<p>parses MIME messages into an array structure</p>
<br />
<a name="mimemultipart" />
<h4>17.5.2.3. Processing HTTP PUT of type "multipart/form-data"</h4>
<p>
When the Virtuoso server receives a PUT request of type "multipart/form-data"
from the client agent, then it passes the HTTP text to the MIME_TREE function internally
and adds any MIME subpart as an element pair ("name", "value")
of the "params" parameter of the vsp page being specified in the URI.
It also adds an additional "params" pair for each HTTP request MIME part
named "attr-name" and whose value is an array of all MIME header fields of that part.
</p>
<a name="mime002" />
<div class="example">
<div class="exampletitle">Example:</div>
<p>
Consider the following HTTP request:
</p>
<div>
<pre class="programlisting">
PUT handler.vsp
Content-Type: "multipart/form-data"; boundary="--end_part"
----end_part
Content-Type: image/gif
Content-Disposition: form-data; name=upload_control; filename="some image.gif"
GIF...
----end_part
Content-Type: text/plain
Content-Disposition: form-data; name=textarea
The description
----end_part--
</pre>
</div>
<p>
Virtuoso parses that and produces the following params content when calling handler.vsp:
</p>
<div>
<pre class="programlisting">
( "upload_control", "GIF....",
"attr-upload_control", ( "Content-Type", "image/gif",
"Content-Disposition", "form-data", "name",
"upload_control", "filename", "some image.gif"),
"textarea", "The description",
"attr-textarea", ("Content-Type", "text/plain",
"Content-Disposition", "form-data", "name",
"textarea")
)
</pre>
</div>
</div>
<p>
This allows for vsp's to handle uniformly "x-www-form/url-encoded" and
"multipart/form-data" PUTS and to have full access to the MIME headers if needed.
</p>
<br />
<br />
<a name="smime" />
<h3>17.5.3. S/MIME Support</h3>
<p>S/MIME is a specification for secure electronic mail. S/MIME stands for
Secure/Multipurpose Internet Mail Extensions and was designed to add security
to e-mail messages in MIME format. The security services offered are
authentication (using digital signatures) and privacy (using encryption).</p>
<p>The S/MIME specification consists of two documents:
<a href="http://www.rfc-editor.org/rfc/rfc2311">S/MIME Message Specification (RFC 2311)</a> and
<a href="http://www.rfc-editor.org/rfc/rfc2312">S/MIME Certificate Handling (RFC 2312)</a>.
Both of these are Internet Drafts. The S/MIME community has submitted these
to the IETF. The goal is to form a working group and produce an Internet
standard.</p>
<p>All certificates and private keys are read and stored as PEM encoded
strings. If the server is compiled without SSL support then dummy versions
of smime_sign, smime_verify, pem_certificates_to_array and get_certificate_info
are available so that existing SQL code would not be broken. Currently the
Virtuoso server supports S/MIME signing and S/MIME signature verification.
These are done through the following 2 functions:</p>
<p>
<a href="fn_smime_verify.html">smime_verify()</a>
</p>
<p>
<a href="fn_smime_sign.html">smime_sign()</a>
</p>
<p>A useful utility function for S/MIME support is:</p>
<p>
<a href="fn_pem_certificates_to_array.html">pem_certificates_to_array()</a>
</p>
<br />
<table border="0" width="90%" id="navbarbottom">
<tr>
<td align="left" width="33%">
<a href="nntpnewsgroups.html" title="NNTP Newsgroups">Previous</a>
<br />NNTP Newsgroups</td>
<td align="center" width="34%">
<a href="internetservices.html">Chapter Contents</a>
</td>
<td align="right" width="33%">
<a href="ftpservices.html" title="FTP Services">Next</a>
<br />FTP Services</td>
</tr>
</table>
</div>
<div id="footer">
<div>Copyright© 1999 - 2009 OpenLink Software All rights reserved.</div>
<div id="validation">
<a href="http://validator.w3.org/check/referer">
<img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" />
</a>
<a href="http://jigsaw.w3.org/css-validator/">
<img src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!" height="31" width="88" />
</a>
</div>
</div>
</body>
</html>
distrib
>
Fedora
>
14
>
x86_64
>
media
>
updates
>
by-pkgid
>
71d40963b505df4524269198e237b3e3
>
files
>
816
