Re: nnimap versus tls

[Gaute B Strokkenes <gs234@cam.ac.uk>]

On 10 jul 2003, jas@extundo.com wrote:

> Gaute B Strokkenes <gs234@cam.ac.uk> writes:
>
>> Debugger entered--Lisp error: (error "Selecting deleted buffer")
>> imap-arrival-filter(#<process imap<1>> "*** Received corrupted
>> data(-9) - server has terminated the connection abnormally\n")
>> delete-process(#<process imap<2>>) imap-close(#<buffer *imap
>> source*>)
>>
>> See?  gnutls-cli likes to spit out that line "*** Received
>> corrupted"... after the connection is closed.
>
> IMHO, gnutls-cli should print this to stderr instead of stdout.

It does.  It doesn't make a difference: the elisp manual states that
stderr and stdout of subprocesses can't be separated without using
shell redirection or something similar, and unless I misread the code,
we do no such thing.

>> Similarly openssl seems to like to write out "read:errno=0" when
>> the connection goes down.
>
> To stdout?  When -quiet is used?  Then I'd consider this a bug too,
> it should go to stderr.

It does go to stderr, but as above it makes no difference.

> Of course, nnimap should not misbehave even when the tunnel
> application print junk to stderr,

I'd like to point out that this is not the only problem case that
these patches correct.  There was a race in imap-wait-for-tag, in
which if the process dies we would not necessarily process everything
it output.  This lead to a similar error, but with the tail end of the
imapd's BYE response prepended to "*** Receved...".  I fixed that by
adding a final call to accept-process output, called only when
imap-wait-for-tag ends its loop due to the process exiting.  However,
that didn't the problem of the server outputting extra
junk--imap-wait-for-tag can return as soon as it gets all of the
response to the LOGOUT command, leaving the junk unprocessed (if the
timing is right.)

Looking at imap.el, there are lots of places where 'run and 'close
seem to be used synonymously as process statuses.  I don't think
that's quite correct--a network connection will remain open until
you've read everything the other end has sent you, but a subprocess
will not necessarily stay alive until you've read everything it has to
say.  (Or at least, that's the best estimation of the semantics that I
can make based on my observations; the emacs lisp manual is annoyingly
vague on this particular topic.)

> so your work and patches are still useful to have.  Thanks.

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
You mean you don't want to watch WRESTLING from ATLANTA?