FAQ

Page Discussion History

Difference between revisions of "Bugs"

m (moved NginxBugs to Bugs: Removing Nginx prefix from page titles)
 
(Nginx Bugs: Link to the new bug tracker)
 
Line 1: Line 1:
 
= Nginx Bugs =
 
= Nginx Bugs =
 +
 +
To report bugs, see [http://trac.nginx.org/nginx/ Trac].
 +
 +
 +
= OLD / OBSOLETE =
  
 
This is a poor man's bug tracker, until something better comes along.
 
This is a poor man's bug tracker, until something better comes along.

Latest revision as of 20:20, 2 July 2013

Contents

Nginx Bugs

To report bugs, see Trac.


OLD / OBSOLETE

This is a poor man's bug tracker, until something better comes along.

A segmentation fault occurs when using the fastcgi_catch_stderr directive.

Reported by Manlio Perillo.

[PATCH] mail bugs

From: Mansoor Peerbhoy <mansoor@...>
Subject: (resending) bug in ngx_mail_proxy_read_response
Newsgroups: gmane.comp.web.nginx.english
Date: 2007-11-11 11:22:36 GMT

Hello Igor, please ignore my earlier e-mail since it was incomplete:

We have come across a small bug in the function ngx_mail_proxy_read_response() in src/mail/ngx_mail_proxy_module.c:
Basically, after sending the LOGIN command (along with the password) to the upstream server, NGINX
immediately expects the tagged response (OK/NO) from the upstream server.

However, according to the IMAP RFC 3501, section 6.2.3:

: A server MAY include a CAPABILITY response code in the tagged OK
: response to a successful LOGIN command in order to send
: capabilities automatically.  It is unnecessary for a client to
: send a separate CAPABILITY command if it recognizes these
: automatic capabilities.

This breaks nginx because it is searching for the tagged response in the switch case inside the
ngx_mail_proxy_read_response() function (case ngx_imap_passwd).

This causes the following error to appear in nginx logs, because the code is not able to handle the untagged response:

2007/11/11 16:03:40 [info]  3917#0: *3 upstream sent invalid response: "* CAPABILITY IMAP4rev1 ACL
BINARY CATENATE CHILDREN CONDSTORE ESEARCH ID IDLE LIST-EXTENDED LITERAL+ LOGIN-REFERRALS
MULTIAPPEND NAMESPACE QUOTA RIGHTS=ektx SASL-IR UIDPLUS UNSELECT WITHIN X-DRAFT-I05-SEARCHRES
1 OK LOGIN completed" while reading response from upstream, client: 127.0.0.1, server: 0.0.0.0:1143,
login: "user1@...", upstream: 127.0.0.1:7143

There is also another issue. During integration of nginx proxy with our Zimbra IMAP mail server, we have
noticed the following: If the server side does a flush between sending the untagged capability response
and the tagged result to the LOGIN command, as follows:

* OK localhost Zimbra IMAP4rev1 service ready
1 login mansoor secret
* CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ESEARCH ID IDLE LIST-EXTENDED LITERAL+
LOGIN-REFERRALS MULTIAPPEND NAMESPACE QUOTA RIGHTS=ektx SASL-IR UIDPLUS UNSELECT WITHIN X-DRAFT-I05-SEARCHRES
// ----- upstream server flushes socket -----
1 OK LOGIN completed

In this case, the recv() function call at the start of the ngx_mail_proxy_read_response function does not
receive both the lines in one call (we require to make a second call to recv() to fetch the tagged response).

The attached patch fixes both issues, I have commented the code as necessary.

Please consider including the patch into nginx (I tested the bug, and the patch on nginx-0.5.33).

Regards,

Md. Mansoor Peerbhoy
http://www.zimbra.com/

Attachment: [1]