Nginx-1.3.14

Server NGINX
1

Changes with nginx 1.3.14 05 Mar
2013

*) Feature: $connections_active, $connections_reading, and
   $connections_writing variables in the

ngx_http_stub_status_module.

*) Feature: support of WebSocket connections in the
   ngx_http_uwsgi_module and ngx_http_scgi_module.

*) Bugfix: in virtual servers handling with SNI.

*) Bugfix: new sessions were not always stored if the

“ssl_session_cache
shared” directive was used and there was no free space in shared
memory.
Thanks to Piotr S…

*) Bugfix: multiple X-Forwarded-For headers were handled

incorrectly.
Thanks to Neal Poole for sponsoring this work.

*) Bugfix: in the ngx_http_mp4_module.
   Thanks to Gernot Vormayr.

–
Maxim D.
http://nginx.org/en/donation.html

2

Hello Nginx U.s,

Now available: Nginx 1.3.14 For Windows Nginx 1.3.14 for Windows – Kevin Worthington (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.

Announcements are also available via my Twitter stream (
http://twitter.com/kworthington), if you prefer to receive updates that
way.

Thank you,
Kevin

Kevin W.
kworthington @ (gmail] [dot} {com)

http://twitter.com/kworthington

3

On 13 March 2013 14:15, AJ Weber [email protected] wrote:

Is there a way to leave my default caching enabled, but tell nginx to NOT
cache zero-byte results? If the correct content is available in the cache,
I want it returned without going to the back end, but in my case (at least),
a zero-byte result for a status=200 is not valid.

It looks to me like
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_no_cache
is what you need to use.
If the backend is returning a Content-Length header, you could refer
to that. If not, you may have to get creative in assembling a map{}
variable.

FWIW, a 200 with an empty body is, (I believe) invalid. It should be a
204. If your backend is misbehaving, you might like to fix it before
mitigating the problem inside your reverse-proxy. Remember: broken
gets fixed, but shitty lives forever …

Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

4

On 3/13/2013 10:40 AM, Jonathan M. wrote:

It looks to me like
Module ngx_http_proxy_module
is what you need to use.
If the backend is returning a Content-Length header, you could refer
to that. If not, you may have to get creative in assembling a map{}
variable.
I looked at that, but it appears that it only tests for the existence of
the variable/header. Content-Length should be there all the time.

FWIW, a 200 with an empty body is, (I believe) invalid. It should be a
204. If your backend is misbehaving, you might like to fix it before
mitigating the problem inside your reverse-proxy. Remember: broken
gets fixed, but shitty lives forever …

I tend to agree with you here. Sometimes you can’t open-up the
application code very easily…but it’s a very fair and valid point.
I’ll look into it.

Thanks for the reply,
AJ

5

I have a case where a user requires authorization to retrieve content.
Ngnix correctly returns the tomcat’s 401, and then the user attempts
authentication.

However, if the user fails to authenticate, tomcat returns a 200 but
zero bytes returned. This comes through nginx as a cache-miss,
status=200, 0 bytes returned.

Unfortunately, if the user tries again, even if he/she is successful,
the 200 result is cached for my 10min cache setting for
200-results…thus, even a correct login will not return the content for
at least 10min due to the cached, zero-byte page.

Is there a way to leave my default caching enabled, but tell nginx to
NOT cache zero-byte results? If the correct content is available in the
cache, I want it returned without going to the back end, but in my case
(at least), a zero-byte result for a status=200 is not valid.

Thanks for any tips or tricks!
-AJ

6

On 13 March 2013 15:02, AJ Weber [email protected] wrote:

variable.

I looked at that, but it appears that it only tests for the existence of the
variable/header. Content-Length should be there all the time.

The docs I linked to have this to say: “If at least one value of the
string parameters is not empty and is not equal to “0” then the
response will not be saved”

So if content-length is always present (and sometimes “0”) I would try
this:

map $upstream_http_content_length $map_upstream_cache_buster {
default 0;
0 1;
}
server {
[…]
proxy_no_cache $map_upstream_cache_buster;
}

Or something like that; you get the idea.

Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html