apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: multipart/foo rfc2046 parser to suppliment rfc822?
Date Tue, 04 Sep 2001 18:03:26 GMT
From: "Dirk-Willem van Gulik" <dirkx@covalent.net>
Sent: Tuesday, September 04, 2001 11:19 AM

> Mime parsers are far from simple. See www.imc.org (The internet mail
> consortsium is a good start) for various contenous interop effords. They
> are horribly complex based.
> C-Client from the IMAP consortsium is a good start; in the MIME faq you'll
> find several others.
> ftp://ftp.sunet.se/pub/unix/mail/emil/
> ftp://nic.funet.fi/pub/unix/mail/mimelt20.zip
> Further down to earth; mupack
> ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z
> is one of my favourites.

I will look at those, thank you!  Notice one important bit.  I am proposing we move
our parser for rfc822 headers from httpd into apr-util.  And I am proposing we add
the parser to fracture a multipart/* mime type between parts (per rfc2046).

I am not suggesting we further attempt to parse the contents of one 'part' of a
multipart document.  We get the document headers, the parts, and allow them to parse
the part headers and get a body.  What they do with that, well, it's their problem ;)

If mod_negotation is given a multipart/alternative document, Martin has suggested that
we use this new parser, and in the negotation phase choose one body to serve from

I'll follow your leads in a week or two and see how far I get with this solution.


> > On Friday 31 August 2001 22:21, William A. Rowe, Jr. wrote:
> > > Justin, Ryan,
> > >
> > >   it seems there are now two interesting rfc822+ Apache apps out there
> > > (pop and mbox) and I was wondering... do either of you already have the
> > > multipart parsing that we could move to apr-util (along with rfc822) to
> > > implement Martin's suggestion of using multipart/alternative (server side)
> > > over the quick-hack .var map files I implemented?
> > >
> > >   Note that rfc2046 and it's successors define a _single_ legitimate
> > > parsing strategy for multipart documents.  Therefore, this parser is simply
> > > implemented in terms of rfc822 headers, and the new body semantics.
> > >
> > >   I think these _very_ common parsers belong in apr-util (if rfc822 isn't
> > > already there, I'm working from memory.)

View raw message