Hello,
I'm running into an issue where a proxied location with a regular
expression match does not correctly update the cache when using
proxy_cache_background_update. The update request to the backend seems
to be missing the captured parameters from the regex. I've created a
small test case that d
Hello Nginx users,
Now available: Nginx 1.14.2 for Windows
https://kevinworthington.com/nginxwin1142 (32-bit and 64-bit versions)
These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Officially supported native Windows binaries are at
nginx.org.
Announce
Changes with nginx 1.14.204 Dec 2018
*) Bugfix: nginx could not be built by gcc 8.1.
*) Bugfix: nginx could not be built on Fedora 28 Linux.
*) Bugfix: in handling of client addresses when using unix domain listen
sockets to work with da
Hello!
On Tue, Dec 04, 2018 at 07:09:48AM -0500, hpuac wrote:
> > http://mailman.nginx.org/pipermail/nginx/2012-September/035338.html
>
> Thank you for the quick answer!
> Would it make sense to add that information to the documentation?
> https://nginx.org/en/docs/http/ngx_http_gzip_module.html
Hey!
> http://mailman.nginx.org/pipermail/nginx/2012-September/035338.html
Thank you for the quick answer!
Would it make sense to add that information to the documentation?
https://nginx.org/en/docs/http/ngx_http_gzip_module.html
You named some examples why not to compress 206, 304, 400, 500, bu
Hello!
On Tue, Dec 04, 2018 at 05:56:00AM -0500, hpuac wrote:
> I noticed that the ngx_http_gzip_module is not compressing the response body
> if the HTTP response status code is 202 (Accepted).
> After having a look at the code, it looks like the filter is only active if
> the status code is 200
Hey nginx team,
I noticed that the ngx_http_gzip_module is not compressing the response body
if the HTTP response status code is 202 (Accepted).
After having a look at the code, it looks like the filter is only active if
the status code is 200, 403 or 404.
(
https://trac.nginx.org/nginx/browser/ng
