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-fetchstr
ucture.php
Edit -- https://master
.php.net/note/edit/78648
Del: integrated -- h
ttps://master.php.net/note/delete/78648/integrated
Del: useless -- http
s://master.php.net/note/delete/78648/useless
Del: bad code -- htt
ps://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 -- http
s://master.php.net/note/delete/78648/in+docs
Del: other reasons-- https://mast
er.php.net/note/delete/78648
Reject -- https://mast
er.php.net/note/reject/78648
Search -- https://
master.php.net/manage/user-notes.php
--
PHP Notes Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php
|