nginx.git/src/http, branch release-1.5.2 nginx Fixed ngx_http_parse_chunked() minimal length calculation. 2013-06-28T09:55:05+00:00 Maxim Dounin mdounin@mdounin.ru 2013-06-28T09:55:05+00:00 88fc0f793e6ba4a7ece20f43fcd4357df1231f00 Minimal data length we expect for further calls was calculated incorrectly if parsing stopped right after parsing chunk size. This might in theory affect clients and/or backends using LF instead of CRLF. Patch by Dmitry Popov. 
Minimal data length we expect for further calls was calculated incorrectly
if parsing stopped right after parsing chunk size.  This might in theory
affect clients and/or backends using LF instead of CRLF.

Patch by Dmitry Popov.
Core: support several "error_log" directives. 2013-06-20T16:47:39+00:00 Vladimir Homutov vl@nginx.com 2013-06-20T16:47:39+00:00 11ff177a9fe3129cd1c8b23e1850bfbc3e2c6ae1 When several "error_log" directives are specified in the same configuration block, logs are written to all files with a matching log level. All logs are stored in the singly-linked list that is sorted by log level in the descending order. Specific debug levels (NGX_LOG_DEBUG_HTTP,EVENT, etc.) are not supported if several "error_log" directives are specified. In this case all logs will use debug level that has largest absolute value. 
When several "error_log" directives are specified in the same configuration
block, logs are written to all files with a matching log level.

All logs are stored in the singly-linked list that is sorted by log level in
the descending order.

Specific debug levels (NGX_LOG_DEBUG_HTTP,EVENT, etc.) are not supported
if several "error_log" directives are specified.  In this case all logs
will use debug level that has largest absolute value.
SPDY: fixed code style, no functional changes. 2013-06-13T12:28:42+00:00 Valentin Bartenev vbart@nginx.com 2013-06-13T12:28:42+00:00 420e41ef0972a4c8f91f8200fff04fbc4aee0a4b 






SPDY: pass through the full status when available.
2013-06-07T20:16:00+00:00

Jim Radford
radford@galvanix.com

2013-06-07T20:16:00+00:00

de2ec2c65099b18f02020107fc97b5c639ed5aec

Avoid stripping the status text when proxying for compatibility with http.





Avoid stripping the status text when proxying for compatibility with http.







Perl: fixed r->header_in("Cookie") (ticket #351).
2013-06-10T10:35:00+00:00

Maxim Dounin
mdounin@mdounin.ru

2013-06-10T10:35:00+00:00

ddece08218b4fceaf86afb6a721ed8cd4a6411fe

It was broken by X-Forwarded-For related changes in f7fe817c92a2 (1.3.14)
as hh->offset is no longer 0 for Cookie.





It was broken by X-Forwarded-For related changes in f7fe817c92a2 (1.3.14)
as hh->offset is no longer 0 for Cookie.







Fixed debug logging in ngx_http_parse_complex_uri().
2013-06-05T15:45:08+00:00

Maxim Dounin
mdounin@mdounin.ru

2013-06-05T15:45:08+00:00

dc5c6928fb0d45a80947b2a294f77a432985747a

The *u previously logged isn't yet initialized at this point, and
Valgrind complains.





The *u previously logged isn't yet initialized at this point, and
Valgrind complains.







Valgrind: supressed complaints about uninitialized bytes.
2013-06-05T15:44:22+00:00

Maxim Dounin
mdounin@mdounin.ru

2013-06-05T15:44:22+00:00

40c4e7b73cf35f26125f7d2bb205e91274832ffc

Valgrind complains if we pass uninitialized memory to a syscall:

==36492== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==36492==    at 0x6B5E6A: sendmsg (in /usr/lib/system/libsystem_kernel.dylib)
==36492==    by 0x10004288E: ngx_signal_worker_processes (ngx_process_cycle.c:527)
==36492==    by 0x1000417A7: ngx_master_process_cycle (ngx_process_cycle.c:203)
==36492==    by 0x100001F10: main (nginx.c:410)
==36492==  Address 0x7fff5fbff71c is on thread 1's stack

Even initialization of all members of the structure passed isn't enough, as
there is padding which still remains uninitialized and results in Valgrind
complaint.  Note there is no real problem here as data from uninitialized
memory isn't used.





Valgrind complains if we pass uninitialized memory to a syscall:

==36492== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==36492==    at 0x6B5E6A: sendmsg (in /usr/lib/system/libsystem_kernel.dylib)
==36492==    by 0x10004288E: ngx_signal_worker_processes (ngx_process_cycle.c:527)
==36492==    by 0x1000417A7: ngx_master_process_cycle (ngx_process_cycle.c:203)
==36492==    by 0x100001F10: main (nginx.c:410)
==36492==  Address 0x7fff5fbff71c is on thread 1's stack

Even initialization of all members of the structure passed isn't enough, as
there is padding which still remains uninitialized and results in Valgrind
complaint.  Note there is no real problem here as data from uninitialized
memory isn't used.







Status: the "last_in_chain" flag must be set.
2013-06-05T12:22:40+00:00

Valentin Bartenev
vbart@nginx.com

2013-06-05T12:22:40+00:00

f6650479c30d26b82187bfe0a343a4c92eb9a81a

The module always produces only one and obviously the last buffer in chain.





The module always produces only one and obviously the last buffer in chain.







SPDY: use proper macros for value length and headers counter.
2013-06-04T22:13:52+00:00

Valentin Bartenev
vbart@nginx.com

2013-06-04T22:13:52+00:00

ba4b4991d18aef821086488e0b93a23df8b26039

Currently these macros are synonyms, but this may change in the future
(in particular, spdy/3 uses 4 bytes for lengths).





Currently these macros are synonyms, but this may change in the future
(in particular, spdy/3 uses 4 bytes for lengths).







Core: fixed handling of "stderr" in error_log.
2013-06-04T07:27:36+00:00

Vladimir Homutov
vl@nginx.com

2013-06-04T07:27:36+00:00

26489b16e5abc76eb1b72e37651d01a1e1a657cb

If "stderr" was specified in one of the "error_log" directives,
stderr is not redirected to the first error_log on startup,
configuration reload, and reopening log files.





If "stderr" was specified in one of the "error_log" directives,
stderr is not redirected to the first error_log on startup,
configuration reload, and reopening log files.