Nginx-1.5.8

Server NGINX
1

Changes with nginx 1.5.8 17 Dec
2013

*) Feature: IPv6 support in resolver.

*) Feature: the "listen" directive supports the "fastopen"

parameter.
Thanks to Mathew Rodley.

*) Feature: SSL support in the ngx_http_uwsgi_module.
   Thanks to Roberto De Ioris.

*) Feature: vim syntax highlighting scripts were added to contrib.
   Thanks to Evan M..

*) Bugfix: a timeout might occur while reading client request body

in an
SSL connection using chunked transfer encoding.

*) Bugfix: the "master_process" directive did not work correctly in
   nginx/Windows.

*) Bugfix: the "setfib" parameter of the "listen" directive might

not
work.

*) Bugfix: in the ngx_http_spdy_module.

–
Maxim D.
http://nginx.org/en/donation.html

2

Where would we find documentation on the “fastopen” parameter?

Posted at Nginx Forum:

3

On 12/19/13 13:59, athalas wrote:

Where would we find documentation on the “fastopen” parameter?

“fastopen” parameter set TCP_FASTOPEN socket option on Linux:

4

On Thu, Dec 19, 2013 at 04:59:34AM -0500, athalas wrote:

Where would we find documentation on the “fastopen” parameter?

It’s in the works.

5

On 12/19/13 1:59 PM, athalas wrote:

Where would we find documentation on the “fastopen” parameter?

http://nginx.org/r/listen

–
Maxim K.

6

On 2013-12-20 21:19, Maxim K. wrote:

On 12/19/13 1:59 PM, athalas wrote:

Where would we find documentation on the “fastopen” parameter?

Module ngx_http_core_module

In the documentation above it’s pointed out that the server needs to
tolerate the possibility of receiving duplicate initial SYN segments. I
am not exactly sure on what level I would ensure that the server
performs properly in this regard. According to the draft on TFO
(draft-cheng-tcpm-fastopen-00), 2.1.:

Rather than trying to capture all the dubious SYN packets to make TFO
100% compatible with TCP semantics, we’ve made a design decision
early on to accept old SYN packets with data, i.e., to allow TFO for
a class of applications that are tolerant of duplicate SYN packets
with data, e.g., idempotent or query type transactions. We believe
this is the right design trade-off balancing complexity with
usefulness. There is a large class of applications that can tolerate
dubious transaction requests.

For this reason, TFO MUST be disabled by default, and only enabled
explicitly by applications on a per service port basis.

Wouldn’t it be the responsibility of nginx (the application) to handle
duplicate SYNs?

7

Hello Nginx users,

Now available: Nginx 1.5.8 for Windows Nginx 1.5.8 for Windows – Kevin Worthington (32-bit and
64-bit versions)

These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Officially supported native Windows binaries are
at
nginx.org.

Announcements are also available via my Twitter stream (
http://twitter.com/kworthington), if you prefer to receive updates that
way.

Thank you,
Kevin

Kevin W.
kworthington @ (gmail] [dot} {com)

http://twitter.com/kworthington

8

On Fri, Dec 20, 2013 at 10:06:59PM +0100, Alex wrote:

(draft-cheng-tcpm-fastopen-00), 2.1.:
For this reason, TFO MUST be disabled by default, and only enabled
explicitly by applications on a per service port basis.

Wouldn’t it be the responsibility of nginx (the application) to handle
duplicate SYNs?

It’s the property of the Web application, not the server (nginx).

Please see section 3.1 of

for a less formal explanation of when it’s safe to enable TFO:

: We found that to manage stale or duplicate SYN packets would
: add significant complexity to our design, and thus we decided
: to accept old SYN packets with data in some rare cases; this
: decision restricts the use of TFO to applications that are
: tolerant to duplicate connection / data requests. Since a
: wide variety of applications can tolerate duplicate SYN packets
: with data (e.g. those that are idempotent or perform query-style
: transactions), we believe this constitutes an appropriate tradeoff.

9

On 2013-12-21 10:53, Ruslan E. wrote:

It’s the property of the Web application, not the server (nginx).

Please see section 3.1 of

for a less formal explanation of when it’s safe to enable TFO:

Thanks for the explanation and the link, Ruslan. I somehow had the OSI
model (it’s application layer) in mind when I read about the
restriction.