Hello,
I understand that this isn't strictly a question about Nginx
development, but it does relate to it in some way.
Let's consider a scenario where you have a private fork of Nginx based
on nginx.org, which has been kept relatively in sync with the upstream
source. Now, suppose you want to cha
Hello!
[...]
thank you for the response.
> Parsing cache validity time from cached responses is used at least
> when sending revalidated responses (NGX_HTTP_CACHE_REVALIDATED).
>
> For cached responses with other cache statuses
> (NGX_HTTP_CACHE_HIT, NGX_HTTP_CACHE_STALE) this probably can be
>
Hello,
I would like to understand the rationale for updating
r->cache->valid_sec (and other fields in r->cache) in
ngx_http_upstream_process_cache_control().
It appears that ngx_http_upstream_process_cache_control() can be
called (via ngx_http_proxy_process_header()) in two scenarios: when
sendin
[..]
> >
> > https://mailman.nginx.org/pipermail/nginx-devel/2018-December/011710.html
>
> thank you! it seems the original post mentioned this exact issue. it
> also seems that the patch was removed. i am curious if it would be
> possible to restore the patch.
please never mind, i'm blind, sorry
hello,
> > it seems that the proxy_cache_lock directive operates only for cache
> > misses (new content). while this behavior is documented, i am curious
> > about the reasoning behind it. there are scenarios where
> > proxy_cache_lock could be very beneficial for content revalidation.
> > what ar
hello!
it seems that the proxy_cache_lock directive operates only for cache
misses (new content). while this behavior is documented, i am curious
about the reasoning behind it. there are scenarios where
proxy_cache_lock could be very beneficial for content revalidation.
what are the community's th
hello!
[...]
> Looking more into it while writing tests and docs, I tend to think
> that just "max_headers" would be enough, similarly to
> "ignore_invalid_headers" and "underscores_in_headers".
>
> Mostly identical patch below (s/max_client_headers/max_headers/),
> as well as tests and docs. I'
er size limits (client_header_buffer_size and
> large_client_header_buffers), the additional limit on the number of headers
> might be beneficial to better protect backend servers.
>
> Requested by Maksim Yevmenkin.
this looks good to me. thank you!
max
--
nginx-devel mailing list
nginx-devel@freenginx.org
https://freenginx.org/mailman/listinfo/nginx-devel
Hello,
> > Could the community share their thoughts on introducing a directive to
> > cap the number of HTTP request headers? While we currently have the
> > ability to limit client HTTP request buffer size, having more specific
> > control over the number of headers could be advantageous.
>
> I p
Hello!
Could the community share their thoughts on introducing a directive to
cap the number of HTTP request headers? While we currently have the
ability to limit client HTTP request buffer size, having more specific
control over the number of headers could be advantageous.
Thanks,
max
--
nginx-
> Disabled handling of headers without a colon.
>
> Starting with nginx 0.1.29 (509:9b8c906f6e63), header names not followed
> by a colon and a value were allowed. Such headers were interpreted as
> headers with an empty value. With this change, such headers are
> uncondition
hello,
it appears that nginx would happily accept http header without colon
(:) in the header name. the patch below tries to address this.
thanks
max
==
--- a/ports/netflix/nginx/files/nginx/src/http/ngx_http_parse.c
+++ b/ports/netflix/nginx/files/nginx/src/http/ngx_http_parse.c
@@ -941,14 +94
12 matches
Mail list logo