A PHP documentation note has been added near the appropriate PHP function (imap_fetchstructure); see http://www.php.net/manual/en/function.imap-fetchstructure.php (may take a few hours to be shown, should be visible Monday Oct 22nd)
A PHP feature request has also been added; see http://bugs.php.net/43061 Thank you! Pedro Freire -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: quarta-feira, 17 de Outubro de 2007 18:25 To: Cynergi Cc: imap-uw@u.washington.edu Subject: RE: [Imap-uw] Apparent bug in imap-2006k.DEV.SNAP-0710121414 (and older?) Please feel free to make whatever reports or references to the PHP developers that you like. I'll be happy to assist with whatever information is needed. 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: > Hi. > > Thank you for your detailed reply! > That makes sense. And yes, PHP assumed too much. But it would now > break much PHP code out there to make use of body_types[], but that could be added. > > Could I make a PHP bug report / feature request quoting this message > from you? Do you want me to delete you e-mail address (as these things > are publicly available) from the quoted text? Do you prefer to try and > make the PHP bug report yourself, again? > > Thank you! > > Pedro Freire > Cynergi > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin > Sent: terça-feira, 16 de Outubro de 2007 17:35 > To: Cynergi > Cc: imap-uw@u.washington.edu > 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 >> >> _______________________________________________ >> Imap-uw mailing list >> Imap-uw@u.washington.edu >> https://mailman1.u.washington.edu/mailman/listinfo/imap-uw >> > > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. > > -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
