[PATCH] Configure: don't test alternatives if preferred feature is found

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064812 25200
#  Mon Jun 27 15:00:12 2016 -0700
# Node ID e4375e338d9acf927ffdc4cd18c704bb7ea1fd4e
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: don't test alternatives if preferred feature is found.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r e4375e338d9a auto/cc/conf
--- a/auto/cc/conf
+++ b/auto/cc/conf
@@ -197,6 +197,7 @@ if [ "$NGX_PLATFORM" != win32 ]; then
 
 if [ "$NGX_CC_NAME" = "ccc" ]; then
 echo "checking for C99 variadic macros ... disabled"
+ngx_found=no
 else
 ngx_feature="C99 variadic macros"
 ngx_feature_name="NGX_HAVE_C99_VARIADIC_MACROS"
@@ -209,20 +210,24 @@ if [ "$NGX_PLATFORM" != win32 ]; then
   var(0, buf, \"%d\", 1);
   if (buf[0] != '1') return 1"
 . auto/feature
- fi
+fi
 
 
-ngx_feature="gcc variadic macros"
-ngx_feature_name="NGX_HAVE_GCC_VARIADIC_MACROS"
-ngx_feature_run=yes
-ngx_feature_incs="#include 
+if [ $ngx_found = no ]; then
+
+ngx_feature="gcc variadic macros"
+ngx_feature_name="NGX_HAVE_GCC_VARIADIC_MACROS"
+ngx_feature_run=yes
+ngx_feature_incs="#include 
 #define var(dummy, args...)  sprintf(args)"
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="char  buf[30]; buf[0] = '0';
-  var(0, buf, \"%d\", 1);
-  if (buf[0] != '1') return 1"
-. auto/feature
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="char  buf[30]; buf[0] = '0';
+  var(0, buf, \"%d\", 1);
+  if (buf[0] != '1') return 1"
+. auto/feature
+
+fi
 
 
 ngx_feature="gcc builtin 64 bit byteswap"
diff -r d452cb27639f -r e4375e338d9a auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -184,14 +184,18 @@ ngx_feature_test="fcntl(0, F_READAHEAD, 
 . auto/feature
 
 
-ngx_feature="posix_fadvise()"
-ngx_feature_name="NGX_HAVE_POSIX_FADVISE"
-ngx_feature_run=no
-ngx_feature_incs="#include "
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL);"
-. auto/feature
+if [ $ngx_found = no ]; then
+
+ngx_feature="posix_fadvise()"
+ngx_feature_name="NGX_HAVE_POSIX_FADVISE"
+ngx_feature_run=no
+ngx_feature_incs="#include "
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL);"
+. auto/feature
+
+fi
 
 
 ngx_feature="O_DIRECT"
@@ -208,25 +212,34 @@ if [ $ngx_found = yes -a "$NGX_SYSTEM" =
 have=NGX_HAVE_ALIGNED_DIRECTIO . auto/have
 fi
 
-ngx_feature="F_NOCACHE"
-ngx_feature_name="NGX_HAVE_F_NOCACHE"
-ngx_feature_run=no
-ngx_feature_incs="#include "
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="fcntl(0, F_NOCACHE, 1);"
-. auto/feature
 
+if [ $ngx_found = no ]; then
 
-ngx_feature="directio()"
-ngx_feature_name="NGX_HAVE_DIRECTIO"
-ngx_feature_run=no
-ngx_feature_incs="#include 
-  #include "
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="directio(0, DIRECTIO_ON);"
-. auto/feature
+ngx_feature="F_NOCACHE"
+ngx_feature_name="NGX_HAVE_F_NOCACHE"
+ngx_feature_run=no
+ngx_feature_incs="#include "
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="fcntl(0, F_NOCACHE, 1);"
+. auto/feature
+
+fi
+
+
+if [ $ngx_found = no ]; then
+
+ngx_feature="directio()"
+ngx_feature_name="NGX_HAVE_DIRECTIO"
+ngx_feature_run=no
+ngx_feature_incs="#include 
+  #include "
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="directio(0, DIRECTIO_ON);"
+. auto/feature
+
+fi
 
 
 ngx_feature="statfs()"
@@ -242,16 +255,20 @@ ngx_feature_test="struct statfs  fs;
 . auto/feature
 
 
-ngx_feature="statvfs()"
-ngx_feature_name="NGX_HAVE_STATVFS"
-ngx_feature_run=no
-ngx_feature_incs="#include 
-  #include "
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="struct statvfs  fs;
-  statvfs(\".\", );"
-. auto/feature
+if [ $ngx_found = no ]; then
+
+ngx_feature="statvfs()"
+ngx_feature_name="NGX_HAVE_STATVFS"
+ngx_feature_run=no
+ngx_feature_incs="#include 
+  #include "
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="struct statvfs  fs;
+  statvfs(\".\", );"
+. auto/feature
+
+fi
 
 
 ngx_feature="dlopen()"
@@ -356,28 +373,36 @@ ngx_feature_test="setsockopt(0, IPPROTO_
 
 # Linux transparent proxying
 
-ngx_feature="IP_TRANSPARENT"
-ngx_feature_name="NGX_HAVE_TRANSPARENT_PROXY"
-ngx_feature_run=no
-ngx_feature_incs="#include 
-  #include "
-ngx_feature_path=
-ngx_feature_libs=
-ngx_feature_test="setsockopt(0, IPPROTO_IP, IP_TRANSPARENT, NULL, 0)"
-. auto/feature
+if [ $ngx_found = no ]; then
+
+ngx_feature="IP_TRANSPARENT"
+

[PATCH] Core: reorder #ifdef in .h file to match order in .c file

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064811 25200
#  Mon Jun 27 15:00:11 2016 -0700
# Node ID 11a53446bd90b8927cb93847c98672a8f056d182
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Core: reorder #ifdef in .h file to match order in .c file.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 11a53446bd90 src/os/unix/ngx_setaffinity.h
--- a/src/os/unix/ngx_setaffinity.h
+++ b/src/os/unix/ngx_setaffinity.h
@@ -11,16 +11,16 @@
 
 #define NGX_HAVE_CPU_AFFINITY 1
 
-#if (NGX_HAVE_SCHED_SETAFFINITY)
-
-typedef cpu_set_t  ngx_cpuset_t;
-
-#elif (NGX_HAVE_CPUSET_SETAFFINITY)
+#if (NGX_HAVE_CPUSET_SETAFFINITY)
 
 #include 
 
 typedef cpuset_t  ngx_cpuset_t;
 
+#elif (NGX_HAVE_SCHED_SETAFFINITY)
+
+typedef cpu_set_t  ngx_cpuset_t;
+
 #endif
 
 void ngx_setaffinity(ngx_cpuset_t *cpu_affinity, ngx_log_t *log);

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Shuxin,

> How do you manage to tackle this scenario without changing your existing
> code:
>
> backend server responses with trailer "lol = 123", and you define the
> same trailer,
> "lol = $haha" in *.conf. You have two options as to how to combine them:
> either override the
> one from origin, and override the one from your *.conf.

...or the third option - emit both trailers ;)

This is consistent with how duplicate headers are currently handled in
NGINX, that is: headers emitted by upstream and those added with
"add_header" are both transmitted to the client.

> It seems to me that the
> chunk-module is again a best place for such change.

Again, chunked module is HTTP/1.1 specific and nothing other than
"encode trailers from r->headers_out.trailers to HTTP/1.1" should be
handled there.

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH 2 of 2] Core: remove NGX_TIME_T_SIZE

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064810 25200
#  Mon Jun 27 15:00:10 2016 -0700
# Node ID a2892701d91e6aba62719b54792e1e14eeea11a0
# Parent  1059f59c44039020843ced5bca39f165c322bacb
Core: remove NGX_TIME_T_SIZE.

Replace ./configure-time test with equivalent compile-time test.

Signed-off-by: Piotr Sikora 

diff -r 1059f59c4403 -r a2892701d91e auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -624,7 +624,6 @@ ngx_param=NGX_MAX_OFF_T_VALUE; ngx_value
 ngx_param=NGX_OFF_T_LEN; ngx_value=$ngx_max_len; . auto/types/value
 
 ngx_type="time_t"; . auto/types/sizeof
-ngx_param=NGX_TIME_T_SIZE; ngx_value=$ngx_size; . auto/types/value
 ngx_param=NGX_TIME_T_LEN; ngx_value=$ngx_max_len; . auto/types/value
 ngx_param=NGX_MAX_TIME_T_VALUE; ngx_value=$ngx_max_value; . auto/types/value
 
diff -r 1059f59c4403 -r a2892701d91e src/core/ngx_module.h
--- a/src/core/ngx_module.h
+++ b/src/core/ngx_module.h
@@ -18,9 +18,7 @@
 #define NGX_MODULE_UNSET_INDEX  (ngx_uint_t) -1
 
 
-#define NGX_MODULE_SIGNATURE_0\
-ngx_value(NGX_PTR_SIZE) ","   \
-ngx_value(NGX_TIME_T_SIZE) ","
+#define NGX_MODULE_SIGNATURE_0   ngx_value(NGX_PTR_SIZE) ","
 
 #if (NGX_HAVE_KQUEUE)
 #define NGX_MODULE_SIGNATURE_1   "1"
diff -r 1059f59c4403 -r a2892701d91e src/core/ngx_parse_time.c
--- a/src/core/ngx_parse_time.c
+++ b/src/core/ngx_parse_time.c
@@ -264,13 +264,9 @@ ngx_parse_http_time(u_char *value, size_
 
 - 719527 + 31 + 28) * 86400 + hour * 3600 + min * 60 + sec;
 
-#if (NGX_TIME_T_SIZE <= 4)
-
-if (time > 0x7fff) {
+if (sizeof(time_t) <= 4 && time > 0x7fff) {
 return NGX_ERROR;
 }
 
-#endif
-
 return (time_t) time;
 }
diff -r 1059f59c4403 -r a2892701d91e src/os/win32/ngx_win32_config.h
--- a/src/os/win32/ngx_win32_config.h
+++ b/src/os/win32/ngx_win32_config.h
@@ -200,7 +200,6 @@ typedef int sig_atomic_t
 #define NGX_SIZE_T_LEN  (sizeof("-9223372036854775808") - 1)
 #define NGX_MAX_SIZE_T_VALUE9223372036854775807
 #define NGX_TIME_T_LEN  (sizeof("-9223372036854775808") - 1)
-#define NGX_TIME_T_SIZE 8
 #define NGX_MAX_TIME_T_VALUE9223372036854775807
 
 #else
@@ -209,7 +208,6 @@ typedef int sig_atomic_t
 #define NGX_SIZE_T_LEN  (sizeof("-2147483648") - 1)
 #define NGX_MAX_SIZE_T_VALUE2147483647
 #define NGX_TIME_T_LEN  (sizeof("-2147483648") - 1)
-#define NGX_TIME_T_SIZE 4
 #define NGX_MAX_TIME_T_VALUE2147483647
 
 #endif

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH 1 of 2] Core: remove unused NGX_SIG_ATOMIC_T_SIZE

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064809 25200
#  Mon Jun 27 15:00:09 2016 -0700
# Node ID 1059f59c44039020843ced5bca39f165c322bacb
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Core: remove unused NGX_SIG_ATOMIC_T_SIZE.

Unused since 9c2f3ed7a247 (0.3.3).

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 1059f59c4403 auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -602,8 +602,6 @@ ngx_type="uint32_t"; ngx_types="u_int32_
 ngx_type="uint64_t"; ngx_types="u_int64_t"; . auto/types/typedef
 
 ngx_type="sig_atomic_t"; ngx_types="int"; . auto/types/typedef
-. auto/types/sizeof
-ngx_param=NGX_SIG_ATOMIC_T_SIZE; ngx_value=$ngx_size; . auto/types/value
 
 ngx_type="socklen_t"; ngx_types="int"; . auto/types/typedef
 
diff -r d452cb27639f -r 1059f59c4403 src/core/ngx_module.h
--- a/src/core/ngx_module.h
+++ b/src/core/ngx_module.h
@@ -20,7 +20,6 @@
 
 #define NGX_MODULE_SIGNATURE_0\
 ngx_value(NGX_PTR_SIZE) ","   \
-ngx_value(NGX_SIG_ATOMIC_T_SIZE) ","  \
 ngx_value(NGX_TIME_T_SIZE) ","
 
 #if (NGX_HAVE_KQUEUE)
diff -r d452cb27639f -r 1059f59c4403 src/os/win32/ngx_win32_config.h
--- a/src/os/win32/ngx_win32_config.h
+++ b/src/os/win32/ngx_win32_config.h
@@ -217,7 +217,6 @@ typedef int sig_atomic_t
 
 #define NGX_OFF_T_LEN   (sizeof("-9223372036854775807") - 1)
 #define NGX_MAX_OFF_T_VALUE 9223372036854775807
-#define NGX_SIG_ATOMIC_T_SIZE   4
 
 
 #define NGX_HAVE_LITTLE_ENDIAN  1

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[shuxinyang]

It's "trailer support" for the web serving part of NGINX, just not proxying.


  - the "get" in "ngx_http_chunked_get_trailers" is sort of misleading.
The "get" here actually
means "generate". I thought you are looking for a existing buffer.

That function name got changed a few times, since I cannot find one
that I would be 100% happy with... Any suggestions?
I hope you don't call me "make fuss about nothing":-). Being an 
impatient code reader,
I usually take a glimpse the code by reading comment and/or function, 
and imagine

what it tries to do, and stitch them together into a big picture.

the verb "get" did confuse me yesterday and this morning when I took a 
quick look.

I would say "create" or "generate" (or something else) would be better.


Anyway, naming is not big deal, maybe I (and other impatient code 
reader) need change:-)






   Now go back to the long list of trailer support,  I believe it needs to
cover at least:
 1) generate trailer headers and sent to downstream/visitor as you just
did
 2) reverse proxy propagate trailer headers from upstream, which needs
 2.0 parse the incoming trailer header, both considering the body is
buffered and not buffered,
 2.1. make the incoming trailer accessible via variable after content
phase,
 2.2. if response body is is not buffered, combine incoming trailer
header with the generated headers.
 2.3. convert incoming trailer to regular header if response body is
buffered

3|4|..|n) other features.

I think 2.x is much harder than 1). I only implement 1) and 2.0) and
2.1). While implement 2.1), I left some
room for 2.2 and 2.3 for the future. Now that you have plan for 2.x as your
email suggests, wouldn't it
be nice to submit these code first, and then go ahead with the code of 1). I
believe to support 2.2 or 2.3,
your existing code in chunk module needs lots of change.

I don't see how anything you listed in 2.x would require modifications
to the code I submitted... Actually, everything you listed should be
handled in upstream and/or proxy modules, not chunking module, and it
could easily use the API (r->headers_out.trailers) I want to add in
this commit.


How do you manage to tackle this scenario without changing your existing 
code:


backend server responses with trailer "lol = 123", and you define 
the same trailer,
"lol = $haha" in *.conf. You have two options as to how to combine them: 
either override the
one from origin, and override the one from your *.conf. It seems to me 
that the

chunk-module is again a best place for such change.

Best Regards
Shuxin



Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel


___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Shuxin,

>  I took some time to read your code, I believe I fully understand your
> code at this moment.
> My implementation is slightly differently from yours, and we have different
> use-cases.

Thanks!

>  Here is my $0.02 value of comment to your code (cosmetic wise):
>  - the verb "support" in "trailer support" in too general. The
> trailer-support in my mind include
>a long list of features (see bellow)

It's "trailer support" for the web serving part of NGINX, just not proxying.

>  - the "get" in "ngx_http_chunked_get_trailers" is sort of misleading.
> The "get" here actually
>means "generate". I thought you are looking for a existing buffer.

That function name got changed a few times, since I cannot find one
that I would be 100% happy with... Any suggestions?

>   Now go back to the long list of trailer support,  I believe it needs to
> cover at least:
> 1) generate trailer headers and sent to downstream/visitor as you just
> did
> 2) reverse proxy propagate trailer headers from upstream, which needs
> 2.0 parse the incoming trailer header, both considering the body is
> buffered and not buffered,
> 2.1. make the incoming trailer accessible via variable after content
> phase,
> 2.2. if response body is is not buffered, combine incoming trailer
> header with the generated headers.
> 2.3. convert incoming trailer to regular header if response body is
> buffered
>
>3|4|..|n) other features.
>
>I think 2.x is much harder than 1). I only implement 1) and 2.0) and
> 2.1). While implement 2.1), I left some
> room for 2.2 and 2.3 for the future. Now that you have plan for 2.x as your
> email suggests, wouldn't it
> be nice to submit these code first, and then go ahead with the code of 1). I
> believe to support 2.2 or 2.3,
> your existing code in chunk module needs lots of change.

I don't see how anything you listed in 2.x would require modifications
to the code I submitted... Actually, everything you listed should be
handled in upstream and/or proxy modules, not chunking module, and it
could easily use the API (r->headers_out.trailers) I want to add in
this commit.

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Core: remove unused NGX_INVALID_ARRAY_INDEX

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064807 25200
#  Mon Jun 27 15:00:07 2016 -0700
# Node ID 8666abaeb43294edd5b93852bad2a42a27dd651b
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Core: remove unused NGX_INVALID_ARRAY_INDEX.

Unused since ae4744c28620 (0.7.51).

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 8666abaeb432 src/core/ngx_config.h
--- a/src/core/ngx_config.h
+++ b/src/core/ngx_config.h
@@ -105,10 +105,6 @@ typedef intptr_tngx_flag_t;
 #define ngx_abort   abort
 
 
-/* TODO: platform specific: array[NGX_INVALID_ARRAY_INDEX] must cause SIGSEGV 
*/
-#define NGX_INVALID_ARRAY_INDEX 0x8000
-
-
 /* TODO: auto_conf: ngx_inline   inline __inline __inline__ */
 #ifndef ngx_inline
 #define ngx_inline  inline

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: fix build with -Werror=old-style-definition

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064805 25200
#  Mon Jun 27 15:00:05 2016 -0700
# Node ID 3ba6126630ceec0767e70b88be1a004d82e2c27e
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: fix build with -Werror=old-style-definition.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 3ba6126630ce auto/cc/sunc
--- a/auto/cc/sunc
+++ b/auto/cc/sunc
@@ -20,7 +20,10 @@ have=NGX_COMPILER value="\"Sun C $NGX_SU
 
 cat << END > $NGX_AUTOTEST.c
 
-int main() { printf("%d", __SUNPRO_C); }
+int main(void) {
+printf("%d", __SUNPRO_C);
+return 0;
+}
 
 END
 
diff -r d452cb27639f -r 3ba6126630ce auto/endianness
--- a/auto/endianness
+++ b/auto/endianness
@@ -15,7 +15,7 @@ END
 
 cat << END > $NGX_AUTOTEST.c
 
-int main() {
+int main(void) {
 int i = 0x11223344;
 char *p;
 
diff -r d452cb27639f -r 3ba6126630ce auto/feature
--- a/auto/feature
+++ b/auto/feature
@@ -31,7 +31,7 @@ cat << END > $NGX_AUTOTEST.c
 $NGX_INCLUDE_UNISTD_H
 $ngx_feature_incs
 
-int main() {
+int main(void) {
 $ngx_feature_test;
 return 0;
 }
diff -r d452cb27639f -r 3ba6126630ce auto/include
--- a/auto/include
+++ b/auto/include
@@ -20,7 +20,7 @@ cat << END > $NGX_AUTOTEST.c
 $NGX_INCLUDE_SYS_PARAM_H
 #include <$ngx_include>
 
-int main() {
+int main(void) {
 return 0;
 }
 
diff -r d452cb27639f -r 3ba6126630ce auto/types/sizeof
--- a/auto/types/sizeof
+++ b/auto/types/sizeof
@@ -25,7 +25,7 @@ cat << END > $NGX_AUTOTEST.c
 $NGX_INCLUDE_INTTYPES_H
 $NGX_INCLUDE_AUTO_CONFIG_H
 
-int main() {
+int main(void) {
 printf("%d", (int) sizeof($ngx_type));
 return 0;
 }
diff -r d452cb27639f -r 3ba6126630ce auto/types/typedef
--- a/auto/types/typedef
+++ b/auto/types/typedef
@@ -27,7 +27,7 @@ do
 #include 
 $NGX_INCLUDE_INTTYPES_H
 
-int main() {
+int main(void) {
 $ngx_try i = 0;
 return (int) i;
 }
diff -r d452cb27639f -r 3ba6126630ce auto/types/uintptr_t
--- a/auto/types/uintptr_t
+++ b/auto/types/uintptr_t
@@ -19,7 +19,7 @@ cat << END > $NGX_AUTOTEST.c
 #include 
 $NGX_INTTYPES_H
 
-int main() {
+int main(void) {
 uintptr_t i = 0;
 return (int) i;
 }

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: stop polluting NGX_ namespace

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064806 25200
#  Mon Jun 27 15:00:06 2016 -0700
# Node ID 388cf446fe903cfdf0d13740ab3489cc14a3f377
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: stop polluting NGX_ namespace.

While there, fix the only test that used alternative variable name.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 388cf446fe90 auto/include
--- a/auto/include
+++ b/auto/include
@@ -45,9 +45,6 @@ if [ -x $NGX_AUTOTEST ]; then
 
 eval "NGX_INCLUDE_$ngx_name='#include <$ngx_include>'"
 
-#STUB
-eval "NGX_$ngx_name='#include <$ngx_include>'"
-
 else
 echo " not found"
 
diff -r d452cb27639f -r 388cf446fe90 auto/types/uintptr_t
--- a/auto/types/uintptr_t
+++ b/auto/types/uintptr_t
@@ -17,7 +17,7 @@ found=no
 cat << END > $NGX_AUTOTEST.c
 
 #include 
-$NGX_INTTYPES_H
+$NGX_INCLUDE_INTTYPES_H
 
 int main() {
 uintptr_t i = 0;

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Core: remove unused ngx_tm_zone

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064808 25200
#  Mon Jun 27 15:00:08 2016 -0700
# Node ID 890dc5e6a88c49a9d724cc7da1d0eb20fcc70768
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Core: remove unused ngx_tm_zone.

Unused since 9c2f3ed7a247 (0.3.3).

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 890dc5e6a88c src/os/unix/ngx_time.h
--- a/src/os/unix/ngx_time.h
+++ b/src/os/unix/ngx_time.h
@@ -38,7 +38,6 @@ typedef struct tm ngx_tm_t;
 
 #if (NGX_HAVE_GMTOFF)
 #define ngx_tm_gmtoff tm_gmtoff
-#define ngx_tm_zone   tm_zone
 #endif
 
 

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: fix build with -Werror=nonnull

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064804 25200
#  Mon Jun 27 15:00:04 2016 -0700
# Node ID 2c14d7fb1d96c3a1bfb7e22383bef895287bf7d7
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: fix build with -Werror=nonnull.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r 2c14d7fb1d96 auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -260,7 +260,8 @@ ngx_feature_run=no
 ngx_feature_incs="#include "
 ngx_feature_path=
 ngx_feature_libs=
-ngx_feature_test="dlopen(NULL, RTLD_NOW | RTLD_GLOBAL); dlsym(NULL, NULL)"
+ngx_feature_test="dlopen(\"/dev/null\", RTLD_NOW | RTLD_GLOBAL);
+  dlsym(NULL, \"dummy\")"
 . auto/feature
 
 

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: style

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064801 25200
#  Mon Jun 27 15:00:01 2016 -0700
# Node ID d183012fa3d130b8de922d1c8eafd77ae94f8a51
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: style.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r d183012fa3d1 auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -264,7 +264,7 @@ ngx_feature_test="dlopen(NULL, RTLD_NOW 
 . auto/feature
 
 
-if [ $ngx_found != yes ]; then
+if [ $ngx_found = no ]; then
 
 ngx_feature="dlopen() in libdl"
 ngx_feature_libs="-ldl"
@@ -287,7 +287,7 @@ ngx_feature_test="sched_yield()"
 . auto/feature
 
 
-if [ $ngx_found != yes ]; then
+if [ $ngx_found = no ]; then
 
 ngx_feature="sched_yield() in librt"
 ngx_feature_libs="-lrt"

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: fix build with -Werror=unused-value

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064802 25200
#  Mon Jun 27 15:00:02 2016 -0700
# Node ID f5ece83dbcc4c46bcda51511e4fbf8fb90aa9432
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: fix build with -Werror=unused-value.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r f5ece83dbcc4 auto/cc/conf
--- a/auto/cc/conf
+++ b/auto/cc/conf
@@ -231,7 +231,7 @@ if [ "$NGX_PLATFORM" != win32 ]; then
 ngx_feature_incs=
 ngx_feature_path=
 ngx_feature_libs=
-ngx_feature_test="__builtin_bswap64(0)"
+ngx_feature_test="if (__builtin_bswap64(0)) return 1"
 . auto/feature
 
 

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[PATCH] Configure: fix build with -Werror=unused-but-set-variable

[Piotr Sikora]

# HG changeset patch
# User Piotr Sikora 
# Date 1467064803 25200
#  Mon Jun 27 15:00:03 2016 -0700
# Node ID ad603262a99df74951b05ce30c81ebc381694162
# Parent  d452cb27639f714bc43b7f3ede417e3e7f8efdd6
Configure: fix build with -Werror=unused-but-set-variable.

Signed-off-by: Piotr Sikora 

diff -r d452cb27639f -r ad603262a99d auto/os/linux
--- a/auto/os/linux
+++ b/auto/os/linux
@@ -44,6 +44,7 @@ ngx_feature_test="int efd = 0;
   struct epoll_event ee;
   ee.events = EPOLLIN|EPOLLOUT|EPOLLET;
   ee.data.ptr = NULL;
+  (void) ee;
   efd = epoll_create(100);
   if (efd == -1) return 1;"
 . auto/feature
diff -r d452cb27639f -r ad603262a99d auto/unix
--- a/auto/unix
+++ b/auto/unix
@@ -644,7 +644,8 @@ if [ $NGX_IPV6 = YES ]; then
 ngx_feature_path=
 ngx_feature_libs=
 ngx_feature_test="struct sockaddr_in6  sin6;
-  sin6.sin6_family = AF_INET6;"
+  sin6.sin6_family = AF_INET6;
+  (void) sin6"
 . auto/feature
 fi
 

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[shuxinyang]

Hi, Piotr:

 I took some time to read your code, I believe I fully understand 
your code at this moment.
My implementation is slightly differently from yours, and we have 
different use-cases.


 Here is my $0.02 value of comment to your code (cosmetic wise):
 - the verb "support" in "trailer support" in too general. The 
trailer-support in my mind include

   a long list of features (see bellow)

 - the "get" in "ngx_http_chunked_get_trailers" is sort of 
misleading. The "get" here actually

   means "generate". I thought you are looking for a existing buffer.

  Now go back to the long list of trailer support,  I believe it needs 
to cover at least:
1) generate trailer headers and sent to downstream/visitor as you 
just did

2) reverse proxy propagate trailer headers from upstream, which needs
2.0 parse the incoming trailer header, both considering the 
body is buffered and not buffered,
2.1. make the incoming trailer accessible via variable after 
content phase,
2.2. if response body is is not buffered, combine incoming 
trailer header with the generated headers.
2.3. convert incoming trailer to regular header if response 
body is buffered


   3|4|..|n) other features.

   I think 2.x is much harder than 1). I only implement 1) and 2.0) and 
2.1). While implement 2.1), I left some
room for 2.2 and 2.3 for the future. Now that you have plan for 2.x as 
your email suggests, wouldn't it
be nice to submit these code first, and then go ahead with the code of 
1). I believe to support 2.2 or 2.3,

your existing code in chunk module needs lots of change.

Thanks
Shuxin


On 06/27/2016 12:14 PM, Piotr Sikora wrote:

Hey Shuxin,


   As far as I can understand, your change is just to add trailer headers
(not including the part that paring incoming
trailer header from upstream, or merge the incoming trailer and generated
trailer). If that is correct, you just need
to add "trailer: hdr1,hdr2...  hdrn" to the out-headers.

Did you look at both patches I've sent?
http://mailman.nginx.org/pipermail/nginx-devel/2016-June/008429.html
http://mailman.nginx.org/pipermail/nginx-devel/2016-June/008430.html

Because they cover much more than just adding "Trailer" header.


TE is for something
else as Maxim pointed out,
and adding this header can be done in chunked-filter-module as well.

"TE" is a _request_ header, so I don't see how adding it to response
is relevant here.

And yes, "TE" header could be parsed in chunked filter, but it's IMHO
wrong place to do it, since you need to parse this header in HTTP/2
requests as well.


   My previous implementation of generating trailer header is completely done
in chunk-module.  Later on, I change
my mind, and add a standalone module along with minor change to configure
script.

Does you implementation support trailers in HTTP/2 as well?

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel


___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Shuxin,

>   As far as I can understand, your change is just to add trailer headers
> (not including the part that paring incoming
> trailer header from upstream, or merge the incoming trailer and generated
> trailer). If that is correct, you just need
> to add "trailer: hdr1,hdr2...  hdrn" to the out-headers.

Did you look at both patches I've sent?
http://mailman.nginx.org/pipermail/nginx-devel/2016-June/008429.html
http://mailman.nginx.org/pipermail/nginx-devel/2016-June/008430.html

Because they cover much more than just adding "Trailer" header.

> TE is for something
> else as Maxim pointed out,
> and adding this header can be done in chunked-filter-module as well.

"TE" is a _request_ header, so I don't see how adding it to response
is relevant here.

And yes, "TE" header could be parsed in chunked filter, but it's IMHO
wrong place to do it, since you need to parse this header in HTTP/2
requests as well.

>   My previous implementation of generating trailer header is completely done
> in chunk-module.  Later on, I change
> my mind, and add a standalone module along with minor change to configure
> script.

Does you implementation support trailers in HTTP/2 as well?

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Maxim,

> Last time I checked gRPC wasn't able to talk HTTP/1.1, and
> therefore wasn't able to work with nginx at all.  So no real-world
> use for now, right?

Official clients & servers support only HTTP/2, but gRPC protocol can
be layered on top of HTTP/1.1 with trailers, so it's up to the
implementation to offer gRPC-over-HTTP/1.1 support.

As for HTTP/2 trailers, the code I submitted is already used to send
gRPC-over-HTTP/2, so it's quite real-world use case.

> I disagree here.  "TE: trailers" doesn't mean that client asked
> for trailers, it instead indicates that client supports trailers.
> Quoting RFC 7230:
>
>The "TE" header field in a request indicates what transfer codings,
>besides chunked, the client is willing to accept in response, and
>whether or not the client is willing to accept trailer fields in a
>chunked transfer coding.
>
> Using chunked for all clients who send "TE: trailers" looks like a
> bad idea for me, it will hurt at least some real-world clients.

In theory, you're right...

In practice, I'm not aware of any generic-purpose client sending "TE:
trailers" header (i.e. browsers don't send it, even though at least
some support trailers), and it's used only by clients that want to
receive trailers.

> At least in case of proxy, trailers are expected to appear if and
> only if protocol used to talk to the upstream server supports
> them.  That is, it's only expected to happen when talking to a
> backend via HTTP/1.1, and the response uses chunked encoding.

NGINX can add them with "add_trailer", which works even with HTTP/1.0
backends... But point taken.

Would adding r->trailers_emit (or r->expect_trailers, whichever you
prefer) make you happy?

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[shuxinyang]

Hi, Piotr and Maxim:

> to Maxim's question about "does trailer has real-world use" first.

At least we do, some info is available only after the entire body is 
sent. Trailer is a viable and convenient
solution for that matter, albeit it is not the only solution for it.  I 
cannot "leak" more info as I don't know if
I'm allowed say more about it. The bottom line is we did use trailer 
header in some situations.


To Piotr:

  > parsing of "TE" header is done in 
  As far as I can understand, your change is just to add trailer 
headers (not including the part that paring incoming
trailer header from upstream, or merge the incoming trailer and 
generated trailer). If that is correct, you just need
to add "trailer: hdr1,hdr2...  hdrn" to the out-headers. TE is for 
something else as Maxim pointed out,

and adding this header can be done in chunked-filter-module as well.

  My previous implementation of generating trailer header is completely 
done in chunk-module.  Later on, I change
my mind, and add a standalone module along with minor change to 
configure script.


Thanks
Shuxin



On 06/27/2016 10:13 AM, Piotr Sikora wrote:

Hey Shuxin,


I'm wondering why not just change the ngx_http_chunked_filter_module.c?
or add a module inserted right after the chunked-filter-module?

Hmm...? I'm confused by your comment.

This patch modifies 3 files:
- parsing of "TE" header is done in ngx_http_request.c,
- HTTP/1.1 trailers are handled in ngx_http_chunked_filter_module.c,
- HTTP/2 trailers are handled in ngx_http_v2_filter_module.c.

Are you suggesting that HTTP/2 trailers should be handled in
ngx_http_chunked_filter_module.c?

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel


___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Maxim Dounin]

Hello!

On Mon, Jun 27, 2016 at 07:37:31AM -0700, Piotr Sikora wrote:

> > What's the goal?  Any real-world use for this?
> 
> For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
> transport protocol.

Last time I checked gRPC wasn't able to talk HTTP/1.1, and 
therefore wasn't able to work with nginx at all.  So no real-world 
use for now, right?

> > As far as I understand the patch, this will cause chunked encoding
> > to be used for all responses to a client which supports trailers.
> > This certainly looks like a bad idea.
> 
> It will force chunked encoding in responses to HTTP/1.1 requests with
> "TE: trailers", i.e. only when HTTP/1.1 client explicitly asked for
> trailers.

I disagree here.  "TE: trailers" doesn't mean that client asked 
for trailers, it instead indicates that client supports trailers.  
Quoting RFC 7230:

   The "TE" header field in a request indicates what transfer codings,
   besides chunked, the client is willing to accept in response, and
   whether or not the client is willing to accept trailer fields in a
   chunked transfer coding.

Using chunked for all clients who send "TE: trailers" looks like a 
bad idea for me, it will hurt at least some real-world clients.

> Since, at this point (i.e. while processing headers), we don't know
> whether there will be any trailers after response body (because proxy*
> and/or 3rd-party modules might add them later), forcing chunked
> encoding for all clients that asked for trailers is the most
> reasonable thing we can do.
> 
> Alternatively, we could add an indicator (i.e. r->trailers_emit) that
> proxy* and/or 3rd-party modules could set in case they expect to emit
> trailers, but to be honest, I feel that it would be just set to 1
> (unless we want to whitelist which trailers are passed down from
> upstream).

At least in case of proxy, trailers are expected to appear if and 
only if protocol used to talk to the upstream server supports 
them.  That is, it's only expected to happen when talking to a 
backend via HTTP/1.1, and the response uses chunked encoding.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Shuxin,

>I'm wondering why not just change the ngx_http_chunked_filter_module.c?
> or add a module inserted right after the chunked-filter-module?

Hmm...? I'm confused by your comment.

This patch modifies 3 files:
- parsing of "TE" header is done in ngx_http_request.c,
- HTTP/1.1 trailers are handled in ngx_http_chunked_filter_module.c,
- HTTP/2 trailers are handled in ngx_http_v2_filter_module.c.

Are you suggesting that HTTP/2 trailers should be handled in
ngx_http_chunked_filter_module.c?

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[shuxinyang]

Hi, Piotr:

   I'm wondering why not just change the ngx_http_chunked_filter_module.c?
or add a module inserted right after the chunked-filter-module?

Shuxin

On 06/27/2016 07:37 AM, Piotr Sikora wrote:

Hey Maxim,


What's the goal?  Any real-world use for this?




On 06/27/2016 06:45 AM, Maxim Dounin wrote:

Hello!

On Sun, Jun 26, 2016 at 04:13:15PM -0700, Piotr Sikora wrote:


# HG changeset patch
# User Piotr Sikora 
# Date 1466735480 25200
#  Thu Jun 23 19:31:20 2016 -0700
# Node ID a96187a9806536ab2a8bf3fa7f7b659cf5d3ff13
# Parent  6f69e3c0f780e29bca752fc1f938f4a459a1ec59
HTTP: add support for trailers in HTTP responses.

Example:

ngx_table_elt_t  *h;

h = ngx_list_push(>headers_out.trailers);
if (h == NULL) {
return NGX_ERROR;
}

ngx_str_set(>key, "Fun");
ngx_str_set(>value, "with trailers");

For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
transport protocol.


As far as I understand the patch, this will cause chunked encoding
to be used for all responses to a client which supports trailers.
This certainly looks like a bad idea.

It will force chunked encoding in responses to HTTP/1.1 requests with
"TE: trailers", i.e. only when HTTP/1.1 client explicitly asked for
trailers.

Since, at this point (i.e. while processing headers), we don't know
whether there will be any trailers after response body (because proxy*
and/or 3rd-party modules might add them later), forcing chunked
encoding for all clients that asked for trailers is the most
reasonable thing we can do.

Alternatively, we could add an indicator (i.e. r->trailers_emit) that
proxy* and/or 3rd-party modules could set in case they expect to emit
trailers, but to be honest, I feel that it would be just set to 1
(unless we want to whitelist which trailers are passed down from
upstream).

* I'm going to work on proxy support for trailers at some point in
future, if this gets merged.

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel


___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Part of debug log in reply instead of reply if nginx runs under debugger.

[Andrey Kulikov]

Hi Maxim,

Thanks for a fast reply!

Indeed, I didn't mean to reload configuration. After instructing gdb not to
forward SIGHUP to the process being debugged, everything start to work like
a charm.
Thanks for help!

--
WBR,
Andrey

On 27 June 2016 at 16:34, Maxim Dounin  wrote:

> Hello!
>
> On Mon, Jun 27, 2016 at 12:30:19PM +0300, Andrey Kulikov wrote:
>
> > I stuck in rather strange situation: if I run nginx under debugger, and
> > request zero-length file it gives me correct reply on first connection.
> But
> > on second connection it reply it output part of debug log (what supposed
> to
> > be written to debug log, but wasn't).
> > At the same time if nginx runs normally (without debugger attached) -
> > everything works as it should.
> >
> > Is is normal situation when nginx runs under debugger?
>
> No, it's not.  Though it looks like you are using 'master_process
> off' and reloading the configuration:
>
> [...]
>
> > master_process off;
>
> [...]
>
> > 2016/06/27 12:24:30 [notice] 32736#0: signal 1 (SIGHUP) received,
> reconfiguring
>
> This can cause various unexpected effects.  If you didn't mean to
> do a reload - check your debugger documentation if it's
> responsible for this.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[nginx] Style.

[Roman Arutyunyan]

details:   http://hg.nginx.org/nginx/rev/d452cb27639f
branches:  
changeset: 6601:d452cb27639f
user:  Roman Arutyunyan 
date:  Mon Jun 27 18:42:29 2016 +0300
description:
Style.

diffstat:

 src/stream/ngx_stream_limit_conn_module.c |  20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diffs (30 lines):

diff -r 6f69e3c0f780 -r d452cb27639f src/stream/ngx_stream_limit_conn_module.c
--- a/src/stream/ngx_stream_limit_conn_module.c Wed Jun 22 13:47:54 2016 -0700
+++ b/src/stream/ngx_stream_limit_conn_module.c Mon Jun 27 18:42:29 2016 +0300
@@ -105,16 +105,16 @@ static ngx_stream_module_t  ngx_stream_l
 
 ngx_module_t  ngx_stream_limit_conn_module = {
 NGX_MODULE_V1,
-_stream_limit_conn_module_ctx,   /* module context */
-ngx_stream_limit_conn_commands,  /* module directives */
-NGX_STREAM_MODULE,   /* module type */
-NULL,/* init master */
-NULL,/* init module */
-NULL,/* init process */
-NULL,/* init thread */
-NULL,/* exit thread */
-NULL,/* exit process */
-NULL,/* exit master */
+_stream_limit_conn_module_ctx, /* module context */
+ngx_stream_limit_conn_commands,/* module directives */
+NGX_STREAM_MODULE, /* module type */
+NULL,  /* init master */
+NULL,  /* init module */
+NULL,  /* init process */
+NULL,  /* init thread */
+NULL,  /* exit thread */
+NULL,  /* exit process */
+NULL,  /* exit master */
 NGX_MODULE_V1_PADDING
 };
 

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Piotr Sikora]

Hey Maxim,

> What's the goal?  Any real-world use for this?

For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
transport protocol.

> As far as I understand the patch, this will cause chunked encoding
> to be used for all responses to a client which supports trailers.
> This certainly looks like a bad idea.

It will force chunked encoding in responses to HTTP/1.1 requests with
"TE: trailers", i.e. only when HTTP/1.1 client explicitly asked for
trailers.

Since, at this point (i.e. while processing headers), we don't know
whether there will be any trailers after response body (because proxy*
and/or 3rd-party modules might add them later), forcing chunked
encoding for all clients that asked for trailers is the most
reasonable thing we can do.

Alternatively, we could add an indicator (i.e. r->trailers_emit) that
proxy* and/or 3rd-party modules could set in case they expect to emit
trailers, but to be honest, I feel that it would be just set to 1
(unless we want to whitelist which trailers are passed down from
upstream).

* I'm going to work on proxy support for trailers at some point in
future, if this gets merged.

Best regards,
Piotr Sikora

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

[Maxim Dounin]

Hello!

On Sun, Jun 26, 2016 at 04:13:15PM -0700, Piotr Sikora wrote:

> # HG changeset patch
> # User Piotr Sikora 
> # Date 1466735480 25200
> #  Thu Jun 23 19:31:20 2016 -0700
> # Node ID a96187a9806536ab2a8bf3fa7f7b659cf5d3ff13
> # Parent  6f69e3c0f780e29bca752fc1f938f4a459a1ec59
> HTTP: add support for trailers in HTTP responses.
> 
> Example:
> 
>ngx_table_elt_t  *h;
> 
>h = ngx_list_push(>headers_out.trailers);
>if (h == NULL) {
>return NGX_ERROR;
>}
> 
>ngx_str_set(>key, "Fun");
>ngx_str_set(>value, "with trailers");
>h->hash = ngx_hash_key_lc(h->key.data, h->key.len);
> 
> The code above adds "Fun: with trailers" trailer to the response to
> the request with "TE: trailers" header (which indicates support for
> trailers).
> 
> Note that trailers MUST be added before last buffer of the response
> (last_buf = 1) reaches chunked or v2 output filters, otherwise they
> are going to be ignored.
> 
> Signed-off-by: Piotr Sikora 

What's the goal?  Any real-world use for this?

> 
> diff -r 6f69e3c0f780 -r a96187a98065 
> src/http/modules/ngx_http_chunked_filter_module.c
> --- a/src/http/modules/ngx_http_chunked_filter_module.c
> +++ b/src/http/modules/ngx_http_chunked_filter_module.c
> @@ -17,6 +17,7 @@ typedef struct {
>  
>  
>  static ngx_int_t ngx_http_chunked_filter_init(ngx_conf_t *cf);
> +static ngx_chain_t *ngx_http_chunked_get_trailers(ngx_http_request_t *r);
>  
>  
>  static ngx_http_module_t  ngx_http_chunked_filter_module_ctx = {
> @@ -69,28 +70,31 @@ ngx_http_chunked_header_filter(ngx_http_
>  return ngx_http_next_header_filter(r);
>  }
>  
> -if (r->headers_out.content_length_n == -1) {
> +clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
> +
> +if (clcf->chunked_transfer_encoding && r->trailers_ok) {
> +ngx_http_clear_content_length(r);
> +r->chunked = 1;

As far as I understand the patch, this will cause chunked encoding 
to be used for all responses to a client which supports trailers.  
This certainly looks like a bad idea.

[...]

-- 
Maxim Dounin
http://nginx.org/

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

how can i get nginx lib

[Pankaj Chaudhary]

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Part of debug log in reply instead of reply if nginx runs under debugger.

[Andrey Kulikov]

Hello,

I stuck in rather strange situation: if I run nginx under debugger, and
request zero-length file it gives me correct reply on first connection. But
on second connection it reply it output part of debug log (what supposed to
be written to debug log, but wasn't).
At the same time if nginx runs normally (without debugger attached) -
everything works as it should.

Is is normal situation when nginx runs under debugger?

I run everything on Debian 8.5

# uname -a
Linux ng18 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
GNU/Linux

# nginx -V
nginx version: nginx/1.10.1
built by gcc 4.9.2 (Debian 4.9.2-10)
configure arguments: --with-debug


My nginx.conf file:
===
worker_processes  1;
daemon on;
master_process off;
error_log
/root/devel/ngx_module/url-rewrite-nginx-module/t/servroot/logs/error.log
debug;
pid
/root/devel/ngx_module/url-rewrite-nginx-module/t/servroot/logs/nginx.pid;

http {
access_log
/root/devel/ngx_module/url-rewrite-nginx-module/t/servroot/logs/access.log;

default_type text/plain;
keepalive_timeout  68;

server {
listen  1984;
server_name 'localhost';

client_max_body_size 30M;
default_type text/html;
client_body_buffer_size 1;
client_header_buffer_size 1;
proxy_buffer_size 1;
chunked_transfer_encoding off;
location /t {
root
/root/devel/ngx_module/url-rewrite-nginx-module/t/servroot/html;
}

location / {
root
/root/devel/ngx_module/url-rewrite-nginx-module/t/servroot/html;
index index.html index.htm;
}
}
}

events {
accept_mutex off;

worker_connections  64;
}

===

Debug log:
===
2016/06/27 12:24:28 [debug] 32736#0: bind() 0.0.0.0:1984 #6
2016/06/27 12:24:28 [notice] 32736#0: using the "epoll" event method
2016/06/27 12:24:28 [notice] 32736#0: nginx/1.10.1
2016/06/27 12:24:28 [notice] 32736#0: built by gcc 4.9.2 (Debian 4.9.2-10)
2016/06/27 12:24:28 [notice] 32736#0: OS: Linux 3.16.0-4-amd64
2016/06/27 12:24:28 [notice] 32736#0: getrlimit(RLIMIT_NOFILE): 65536:65536
2016/06/27 12:24:30 [notice] 32736#0: signal 1 (SIGHUP) received,
reconfiguring
2016/06/27 12:24:30 [debug] 32743#0: write: 7, 7FFFE060, 6, 0
2016/06/27 12:24:30 [debug] 32743#0: notify eventfd: 7
2016/06/27 12:24:30 [debug] 32743#0: malloc: 006E3340:6144
2016/06/27 12:24:30 [debug] 32743#0: malloc: 006DA310:13824
2016/06/27 12:24:30 [debug] 32743#0: malloc: 006E4B50:6144
2016/06/27 12:24:30 [debug] 32743#0: malloc: 006F5600:6144
2016/06/27 12:24:30 [debug] 32743#0: epoll add event: fd:6 op:1 ev:2001
2016/06/27 12:24:30 [debug] 32743#0: worker cycle
2016/06/27 12:24:30 [debug] 32743#0: epoll timer: -1
2016/06/27 12:24:45 [debug] 32743#0: epoll: fd:6 ev:0001 d:006DA310
2016/06/27 12:24:45 [debug] 32743#0: accept on 0.0.0.0:1984, ready: 0
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 006E6360:512
@16
2016/06/27 12:24:45 [debug] 32743#0: *1 accept: 127.0.0.1:34417 fd:8
2016/06/27 12:24:45 [debug] 32743#0: *1 event timer add: 8:
6:1467019545151
2016/06/27 12:24:45 [debug] 32743#0: *1 reusable connection: 1
2016/06/27 12:24:45 [debug] 32743#0: *1 epoll add event: fd:8 op:1
ev:80002001
2016/06/27 12:24:45 [debug] 32743#0: timer delta: 16289
2016/06/27 12:24:45 [notice] 32743#0: reconfiguring
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 006F6E10:16384
@16
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 006FAE20:16384
@16
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006FEE30:4096
2016/06/27 12:24:45 [debug] 32743#0: read: 9, 006FEE30, 985, 0
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006FFE40:4280
2016/06/27 12:24:45 [debug] 32743#0: malloc: 00700F00:4280
2016/06/27 12:24:45 [debug] 32743#0: malloc: 00701FC0:4280
2016/06/27 12:24:45 [debug] 32743#0: malloc: 00703080:4280
2016/06/27 12:24:45 [debug] 32743#0: malloc: 00704140:4280
2016/06/27 12:24:45 [debug] 32743#0: malloc: 00705200:4280
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 007062C0:16384
@16
2016/06/27 12:24:45 [debug] 32743#0: malloc: 0070A2D0:4096
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 0070B2E0:16384
@16
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006DD920:2048
2016/06/27 12:24:45 [debug] 32743#0: add cleanup: 0070E000
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006D5730:408
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006D58D0:96
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006DD920:1024
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006DD920:1024
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006DD920:1024
2016/06/27 12:24:45 [debug] 32743#0: malloc: 006DD920:1024
2016/06/27 12:24:45 [debug] 32743#0: posix_memalign: 0070F2F0:16384
@16