<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http, branch release-1.4.5</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Fixed TCP_DEFER_ACCEPT handling (ticket #353).</title>
<updated>2014-01-28T11:40:46+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2014-01-28T11:40:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=4cdd17f6bff9b27b3b51a8b5f9d4798985485271'/>
<id>4cdd17f6bff9b27b3b51a8b5f9d4798985485271</id>
<content type='text'>
Backed out 05a56ebb084a, as it turns out that kernel can return connections
without any delay if syncookies are used.  This basically means we can't
assume anything about connections returned with deferred accept set.

To solve original problem the 05a56ebb084a tried to solve, i.e. to don't
wait longer than needed if a connection was accepted after deferred accept
timeout, this patch changes a timeout set with setsockopt(TCP_DEFER_ACCEPT)
to 1 second, unconditionally.  This is believed to be enough for speed
improvements, and doesn't imply major changes to timeouts used.

Note that before 2.6.32 connections were dropped after a timeout.  Though
it is believed that 1s is still appropriate for kernels before 2.6.32,
as previously tcp_synack_retries controlled the actual timeout and 1s results
in more than 1 minute actual timeout by default.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Backed out 05a56ebb084a, as it turns out that kernel can return connections
without any delay if syncookies are used.  This basically means we can't
assume anything about connections returned with deferred accept set.

To solve original problem the 05a56ebb084a tried to solve, i.e. to don't
wait longer than needed if a connection was accepted after deferred accept
timeout, this patch changes a timeout set with setsockopt(TCP_DEFER_ACCEPT)
to 1 second, unconditionally.  This is believed to be enough for speed
improvements, and doesn't imply major changes to timeouts used.

Note that before 2.6.32 connections were dropped after a timeout.  Though
it is believed that 1s is still appropriate for kernels before 2.6.32,
as previously tcp_synack_retries controlled the actual timeout and 1s results
in more than 1 minute actual timeout by default.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: reading from a client after connection upgrade.</title>
<updated>2014-01-22T12:05:07+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2014-01-22T12:05:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=612f981744dd4eaa9c25542d5485844e5109ce7f'/>
<id>612f981744dd4eaa9c25542d5485844e5109ce7f</id>
<content type='text'>
Read event on a client connection might have been disabled during
previous processing, and we at least need to handle events.  Calling
ngx_http_upstream_process_upgraded() is a simpliest way to do it.

Notably this change is needed for select, poll and /dev/poll event
methods.

Previous version of this patch was posted here:
http://mailman.nginx.org/pipermail/nginx/2014-January/041839.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Read event on a client connection might have been disabled during
previous processing, and we at least need to handle events.  Calling
ngx_http_upstream_process_upgraded() is a simpliest way to do it.

Notably this change is needed for select, poll and /dev/poll event
methods.

Previous version of this patch was posted here:
http://mailman.nginx.org/pipermail/nginx/2014-January/041839.html
</pre>
</div>
</content>
</entry>
<entry>
<title>SPDY: fixed possible segfault.</title>
<updated>2014-01-22T00:58:19+00:00</updated>
<author>
<name>Valentin Bartenev</name>
<email>vbart@nginx.com</email>
</author>
<published>2014-01-22T00:58:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6b949b3920b0ca0aa2a4e736927a562c13a04376'/>
<id>6b949b3920b0ca0aa2a4e736927a562c13a04376</id>
<content type='text'>
While processing a DATA frame, the link to related stream is stored in spdy
connection object as part of connection state.  But this stream can be closed
between receiving parts of the frame.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While processing a DATA frame, the link to related stream is stored in spdy
connection object as part of connection state.  But this stream can be closed
between receiving parts of the frame.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed "zero size buf in output" alerts.</title>
<updated>2014-01-03T23:32:22+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2014-01-03T23:32:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=142ed3f499931e7620189906683f7d91ed805e1a'/>
<id>142ed3f499931e7620189906683f7d91ed805e1a</id>
<content type='text'>
If a request had an empty request body (with Content-Length: 0), and there
were preread data available (e.g., due to a pipelined request in the buffer),
the "zero size buf in output" alert might be logged while proxying the
request to an upstream.

Similar alerts appeared with client_body_in_file_only if a request had an
empty request body.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a request had an empty request body (with Content-Length: 0), and there
were preread data available (e.g., due to a pipelined request in the buffer),
the "zero size buf in output" alert might be logged while proxying the
request to an upstream.

Similar alerts appeared with client_body_in_file_only if a request had an
empty request body.
</pre>
</div>
</content>
</entry>
<entry>
<title>Request body: fixed r-&gt;count increment on allocation failure.</title>
<updated>2013-05-11T14:49:19+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2013-05-11T14:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ae341c36ab550d245e0741cf94e14890e4b53673'/>
<id>ae341c36ab550d245e0741cf94e14890e4b53673</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Proper backtracking after space in a request line.</title>
<updated>2013-11-19T02:57:58+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2013-11-19T02:57:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=822a148df534fb30000f867d764d31e527e4ae4f'/>
<id>822a148df534fb30000f867d764d31e527e4ae4f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Win32: $request_time fixed.</title>
<updated>2013-09-04T16:48:30+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2013-09-04T16:48:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=8e69bbf44e18a08603a20bd81a7129e834e9b327'/>
<id>8e69bbf44e18a08603a20bd81a7129e834e9b327</id>
<content type='text'>
On win32, time_t is 64 bits wide by default, and passing an ngx_msec_int_t
argument for %T format specifier doesn't work.  This doesn't manifest itself
on other platforms as time_t and ngx_msec_int_t are usually of the same size.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On win32, time_t is 64 bits wide by default, and passing an ngx_msec_int_t
argument for %T format specifier doesn't work.  This doesn't manifest itself
on other platforms as time_t and ngx_msec_int_t are usually of the same size.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed try_files with empty argument (ticket #390).</title>
<updated>2013-08-23T18:18:39+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2013-08-23T18:18:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=b5656b31f14dd1dd126e9ae10fd8d0b932904388'/>
<id>b5656b31f14dd1dd126e9ae10fd8d0b932904388</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Autoindex: improved ngx_de_info() error handling.</title>
<updated>2013-07-30T07:43:21+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2013-07-30T07:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6db33c712b72e313e928374bfd6b471911b3e658'/>
<id>6db33c712b72e313e928374bfd6b471911b3e658</id>
<content type='text'>
This allows to build a directory listing whenever a loop exists in symbolic
link resolution of the path argument.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows to build a directory listing whenever a loop exists in symbolic
link resolution of the path argument.
</pre>
</div>
</content>
</entry>
<entry>
<title>Autoindex: return NGX_ERROR on error if headers were sent.</title>
<updated>2013-07-30T07:43:21+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2013-07-30T07:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=30091e8b38eb54639cc19ea5d2812f767c1be4c3'/>
<id>30091e8b38eb54639cc19ea5d2812f767c1be4c3</id>
<content type='text'>
This prevents ngx_http_finalize_request() from issuing
ngx_http_special_response_handler() on a freed context.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This prevents ngx_http_finalize_request() from issuing
ngx_http_special_response_handler() on a freed context.
</pre>
</div>
</content>
</entry>
</feed>
