[Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp

[noreply@sourceforge.net]

Bugs item #619732, was opened at 2002-10-08 00:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fails with literals in LIST resp

Initial Comment:
Hello,

imaplib is behaving weirdly when a LIST response
contains literals -- the {25} sort of syntax.

I have encountered a server in the wild that returns
the folder name part of the response as a literal.

imaplib returns a different sort of result for the two
cases.

Consider this snippet from the imaplib debug log from a
LIST response:

DEBUG[imap]:   30:09.81 untagged_responses[LIST] =>
['() "\\" Admin', ('() "\\" {19}',
'Admin\CamillaHansen')

That is:

result[0] = '() "\\" Admin'
result[1] = ('() "\\" {19}', 'Admin\CamillaHansen')

Yes, result[0] is a string, and result[1] is a *tuple*!
 And moreover, the tuple even contains the {19}.  This
is silly.  Both are presenting the same data.  Both
should be returned the same way -- possibly as a tuple
to start with.  There is no reason that the client
progrma should have to strip out the {19}, nor that it
should have to check whether the data being returned is
a string or a tuple.  imaplib should do all the
necessary processing internally.

-- John


----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-10-16 16:24

Message:
Logged In: YES 
user_id=196212

Thanks for the log.

The behaviour you are seeing is the correct one.

If the response to a command returns a tuple instead of a
string, then the tuple is in the form (head, data) - ie: in
the same format as the response from a FETCH command. So,
one needs to check for a tuple in the response, and if so,
find the data in the second element of it.

The philosophy of this module is that it always returns all
the data returned by the server without processing it.

I think the documentation is less than clear on this point
so I'll beef it up.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-10-16 04:21

Message:
Logged In: YES 
user_id=491567

I am attaching a full logfile from OfflineIMAP 3.99.1  that
demonstrates this problem.  It uses imaplib with Debug = 5.

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-10-11 21:28

Message:
Logged In: YES 
user_id=196212

Certainly the wrong behaviour!

In order to nail down the source of the problem, would you
kindly
run "imaplib.py -d5 ..." in a way that demontrates the bug
and email me with the entire output? (Send it to
<piers@communitysolutions.com.au>)

That should make clear why the code that deals with the
{nnn} form isn't picking this up.

Thanks.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470