回复：Fixed gzip_disable_degradation defined without NGX_HTTP_DEGRADATION (broken by 3b522d7a5b34).

[杜叶飞(淮叶)]

OK, I I have another question about this. 'NGX_MODULE_SIGNATURE_27' should be with NGX_HTTP_GZIP as the following patch ?
# HG changeset patch
# User BullerDu <yefei.dyf at alibaba-inc.com>
# Date 1670204057 -28800
# Mon Dec 05 09:34:17 2022 +0800
# Branch bugfix_dynamic_module
# Node ID 5e63c3cf514e64a5f6499b66613d4935bd026d5f
# Parent 0b360747c74e3fa7e439e0684a8cf1da2d14d8f6
Modules compatibility: degradation signature must be with NGX_HTTP_GZIP(Introduced by 3b522d7a5b34).
diff -r 0b360747c74e -r 5e63c3cf514e src/core/ngx_module.h
--- a/src/core/ngx_module.h Thu Nov 24 23:08:30 2022 +0400
+++ b/src/core/ngx_module.h Mon Dec 05 09:34:17 2022 +0800
@@ -149,12 +149,12 @@
 #if (NGX_HTTP_GZIP)
 #define NGX_MODULE_SIGNATURE_26 "1"
+#define NGX_MODULE_SIGNATURE_27 "1"
 #else
 #define NGX_MODULE_SIGNATURE_26 "0"
+#define NGX_MODULE_SIGNATURE_27 "0"
 #endif
-#define NGX_MODULE_SIGNATURE_27 "1"
-
 #if (NGX_HTTP_X_FORWARDED_FOR)
 #define NGX_MODULE_SIGNATURE_28 "1"
 #else
------------------------------------------------------------------
发件人：Maxim Dounin <mdounin at mdounin.ru>
发送时间：2022年12月5日(星期一) 04:13
收件人：nginx-devel <nginx-devel at nginx.org>
主　题：Re: Fixed gzip_disable_degradation defined without NGX_HTTP_DEGRADATION (broken by 3b522d7a5b34).
Hello!
On Sat, Dec 03, 2022 at 11:16:44PM +0800, 杜叶飞(淮叶) via nginx-devel wrote:
> I think gzip_disable_degradation needs NGX_HTTP_DEGRADATION in order to be consistent with where used. 
> details: https://hg.nginx.org/nginx/rev/3b522d7a5b34 <https://hg.nginx.org/nginx/rev/3b522d7a5b34 >
The revision you've linked explains why this "#if" is not really 
needed even if we are concerned about saving these two bits in the 
location configuration structure (and we aren't really concerned 
anyway).
Further, the patch you've suggested breaks binary compatibility 
between nginx builds with and without the degradation module 
without restoring appropriate flag in the binary signature. This 
is clearly incorrect behaviour which can result in segmentation 
faults or other unexpected behaviour if modules compiled with 
different assumptions are loaded into nginx.
-- 
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list -- nginx-devel at nginx.org
To unsubscribe send an email to nginx-devel-leave at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20221205/6f771044/attachment.htm>