From: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> 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 multipart/alternative. I'll follow your leads in a week or two and see how far I get with this solution. Bill > > 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.)
