With this change all such frames will be added in front of the output queue, and will be sent first. It prevents HOL blocking when response with higher priority is blocked by response with lower priority in the middle of the queue because the order of their SYN_REPLY frames cannot be changed. Proposed by Yury Kirpichev.
While ngx_http_spdy_write_handler() should not make any harm with current code, calling it during finalization of SPDY connection was not intended.
If an error occurs in a SPDY connection, the c->error flag is set on every fake request connection, and its read or write event handler is called, in order to finalize it. But while waiting for request headers, it was a no-op since the read event handler had been set to ngx_http_empty_handler().
If an error occurs in a SPDY connection, the c->error flag is set on every fake request connection, and its read or write event handler is called, in order to finalize it. But while waiting for a request body, it was a no-op since the read event handler ngx_http_request_handler() calls r->read_event_handler that had been set to ngx_http_block_reading().
A configuration like "mail { starttls on; server {}}" triggered NULL
pointer dereference in ngx_mail_ssl_merge_conf() as conf->file was not set.
Reported by Markus Linnala.
See here for details: http://nginx.org/pipermail/nginx/2010-August/021713.html http://nginx.org/pipermail/nginx/2010-August/021784.html http://nginx.org/pipermail/nginx/2010-August/021785.html
Basically, this does the following two changes (and corresponding modifications of related code): 1. Does not reset session buffer unless it's reached it's end, and always wait for LF to terminate command (even if we detected invalid command). 2. Record command name to make it available for handlers (since now we can't assume that command starts from s->buffer->start).
A server MUST send greeting before other replies, while before this change in case of smtp_greeting_delay violation the 220 greeting was sent after several 503 replies to commands received before greeting, resulting in protocol synchronization loss. Moreover, further commands were accepted after the greeting. While closing a connection isn't strictly RFC compliant (RFC 5321 requires servers to wait for a QUIT before closing a connection), it's probably good enough for practial uses.