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

[杜叶飞(淮叶)]

OK, I get it. Thanks for your answer.
------------------------------------------------------------------
发件人：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/97f1a1ff/attachment.htm>