note 78648 added to function.imap-fetchstructure

First of all, for a while now (not sure since which PHP version) a new "primary body type" constant exists: TYPEMODEL (int(7)) and TYPEOTHER became int(8). Furthermore the use of these constants can be misleading. The issue is that "other" MIME-types aren't just ==TYPEOTHER, but rather >=TYPEOTHER. I've added a PHP feature request to help solve this (http://bugs.php.net/43061). To learn more, read this extract of a conversation I've had with Mark Crispin of IMAP's extension mailing list at UW (e-mail addresses deleted): ---- Mark Crispin: I certainly understand the frustrations that end users experience with apparent mutual finger-pointing. The way to solve it is through communication. For what it's worth, here are the current semantics of type codes: 0 TEXT 1 MULTIPART 2 MESSAGE 3 APPLICATION 4 AUDIO 5 IMAGE 6 VIDEO 7 MODEL 8 X-UNKNOWN (or expansion types filed up) 9 first expansion type ... TYPEMAX last expansion type (currently 15) On Wed, 17 Oct 2007, Cynergi wrote: (...) > -----Original Message----- > Sent: terça-feira, 16 de Outubro de 2007 17:35 > To: Cynergi > Subject: Re: [Imap-uw] Apparent bug in imap-2006k.DEV.SNAP-0710121414 > (and older?) > > Thank you for your report. > > This is not a bug. The c-client library is designed to behave this way. > > MIME types and encodings are, by definition in MIME, open-ended. From > time to time, the IETF defines new MIME types. It is desirable that > c-client be able to handle these without having to make a source code > modification to c-client. > > To allow applications to support types and encodings that are unknown > to c-client, c-client will automatically add a (limited) number of > unknown types and encodings to its tables before resorting to > TYPEOTHER and ENCOTHER. The names of these added types and encodings > are available in the body_types[] and body_encodings[] arrays. > > Put another way, TYPEOTHER and ENCOTHER are only used if c-client is > overflowed with unknown types and/or encodings. > > If the PHP developers had asked me about this, I would have explained > this to them. Unfortunately, they have a habit of labelling > unexpected behaviors as "bugs" rather than seeking answers. I have > tried to post amended information on the PHP bugzilla in the past, but > was rewarded with a "you are not authorized to do so" so I've given up. > > Hence, a more correct behavior for PHP is not to use type code values, > but instead to use the body_types[type_code] string. > > I hope that this information is helpful. > > On Mon, 15 Oct 2007, Cynergi wrote: > >> Dear Sirs, >> >> I only want to make a bug report. I use PHP for development so I >> really won't be able to keep up with messages from this list. Please >> don't take offense if I unsubscribe in a few days after sending this > message. >> >> While developing a Webmail for www.cynergi.com, we started coming >> upon some >> (spam) messages with bad MIME types. However PHP (via your c-client >> library) reported a MIME type code of 9 instead of TYPEOTHER (8). >> >> Looking at your library I seem to have found the bug. From a comment >> in our source code: >> >> Unknown MIME-types (such as "25-bit") are returned as int(9) due to > a >> bug in c-client's rfc822.c "body_types" array that defines TYPEOTHER >> as "X-UNKNOWN"; then when imap4r1.c goes to match a MIME-type and >> can't match any of body_types' strings (including TYPEOTHER's), it >> returns the next available integer (9). >> This same bug also seems to apply to ENCOTHER. >> >> I am unaware if the body_types array is also used to CREATE >> MIME-types. If so, deleting "X-UNKNOWN" from there won't be the >> solution (the solution will then have to be fixing imap4r1.c's code). >> >> Thank you for your time, and for such a great open-source library!! >> :-) >> >> Pedro Freire >> Cynergi ---- Server IP: 81.92.200.26 Probable Submitter: 89.26.236.64 ---- Manual Page -- http://www.php.net/manual/en/function.imap-fetchstructure.php Edit -- https://master.php.net/note/edit/78648 Del: integrated -- https://master.php.net/note/delete/78648/integrated Del: useless -- https://master.php.net/note/delete/78648/useless Del: bad code -- https://master.php.net/note/delete/78648/bad+code Del: spam -- https://master.php.net/note/delete/78648/spam Del: non-english -- https://master.php.net/note/delete/78648/non-english Del: in docs -- https://master.php.net/note/delete/78648/in+docs Del: other reasons-- https://master.php.net/note/delete/78648 Reject -- https://master.php.net/note/reject/78648 Search -- https://master.php.net/manage/user-notes.php