Nginx-0.7.48

Server NGINX
1

Changes with nginx 0.7.48 06 Apr
2009

*) Feature: the "proxy_cache_key" directive.

*) Bugfix: now nginx takes into account the "X-Accel-Expires",
   "Expires", and "Cache-Control" header lines in a backend

response.

*) Bugfix: now nginx caches responses for the GET requests only.

*) Bugfix: the "fastcgi_cache_key" directive was not inherited.

*) Bugfix: the $arg_... variables did not work with SSI subrequests.
   Thanks to Maxim D..

*) Bugfix: nginx could not be built with uclibc library.
   Thanks to Timothy R..

*) Bugfix: nginx could not be built on OpenBSD; the bug had
   appeared in 0.7.46.
2

2009/4/6 Igor S. [email protected]:

  *) Bugfix: now nginx takes into account the “X-Accel-Expires”,
   “Expires”, and “Cache-Control” header lines in a backend response.

It wasn’t doing this before?

I had code like this (PHP) - was the Cache-Control being ignored? (I
think all headers should be allowed to pass arbitrarily on
X-Accel-Redirect … no reason to block headers anytime anything is
being proxied unless it conflicts with the actual proxying process -
people will eventually request them anyway :))

header(‘Cache-Control: no-cache, no-store’);
header(‘Content-Type: application/octet-stream’);
header(‘Content-Transfer-Encoding: binary’);
header(‘Content-Length: ’ . filesize($f_location));
header(‘Content-Disposition: attachment;
filename="’.basename($file_name).’"');
header(‘X-Accel-Redirect: /foo/protected/’ . basename($file_name));

Do I need to change something in this so it works (I’ll upgrade to
0.7.50 also)

3

Hello!

On Mon, Apr 06, 2009 at 09:40:12AM -0700, Michael S. wrote:

2009/4/6 Igor S. [email protected]:

š š*) Bugfix: now nginx takes into account the “X-Accel-Expires”,
š š š “Expires”, and “Cache-Control” header lines in a backend response.

It wasn’t doing this before?

It should be read ‘now proxy cache takes into account…’. This
change is about proxy_cache, not about stripping headers.

I had code like this (PHP) - was the Cache-Control being ignored? (I
think all headers should be allowed to pass arbitrarily on
X-Accel-Redirect … no reason to block headers anytime anything is
being proxied unless it conflicts with the actual proxying process -
people will eventually request them anyway :))

header(‘Cache-Control: no-cache, no-store’);
header(‘Content-Type: application/octet-stream’);
header(‘Content-Transfer-Encoding: binary’);
header('Content-Length: ’ . filesize($f_location));

NOTE: passing Content-Length which doesn’t match actual message
length is really bad idea. This works now as nginx doesn’t use
persistent connections to backends, but likely break things as
soon as persistent connections support will be introduced. And it’s
not needed anyway (nginx will use actual file length instead).

header(‘Content-Disposition: attachment; filename="’.basename($file_name).‘"’);
header(‘X-Accel-Redirect: /foo/protected/’ . basename($file_name));

Do I need to change something in this so it works (I’ll upgrade to 0.7.50 also)

X-Accel-Redirect takes the following headers from original
response:

Content-Type, Set-Cookie, Content-Disposition, Cache-Control,
Expires, Accept-Ranges

If you want to pass something else, you may use something like
this:

location /foo/protected/ {
    add_header  P3P  $upstream_http_p3p;
    ...
}

Maxim D.

4

2009/4/6 Maxim D. [email protected]:

Hello!

header(‘Content-Transfer-Encoding: binary’);

This is being ignored, according to your statement below, right?

NOTE: passing Content-Length which doesn’t match actual message
length is really bad idea. Â This works now as nginx doesn’t use
persistent connections to backends, but likely break things as
soon as persistent connections support will be introduced. Â And it’s
not needed anyway (nginx will use actual file length instead).

The file length has always been right filesize() has been correct.
Unless nginx is actually calculating itself and I can ignore passing
that (?)

If you want to pass something else, you may use something like
this:

  location /foo/protected/ {
    add_header  P3P  $upstream_http_p3p;
    …
  }

well the idea was to decouple the application logic from the webserver
as much as possible :slight_smile:

5

Hello!

On Mon, Apr 06, 2009 at 01:48:17PM -0700, Michael S. wrote:

2009/4/6 Maxim D. [email protected]:

Hello!

header(‘Content-Transfer-Encoding: binary’);

This is being ignored, according to your statement below, right?

Yes. And actually HTTP doesn’t use Content-Transfer-Encoding
(see RFC2616, “9.4.5 No Content-Transfer-Encoding”).

NOTE: passing Content-Length which doesn’t match actual message
length is really bad idea. šThis works now as nginx doesn’t use
persistent connections to backends, but likely break things as
soon as persistent connections support will be introduced. šAnd it’s
not needed anyway (nginx will use actual file length instead).

The file length has always been right filesize() has been correct.

The problem is that it’s not correct for message where you pass
X-Accel-Redirect header to nginx. This message has no body, and
passing wrong Content-Length may be harmfull (it’s not fatal now
as nginx only uses HTTP/1.0 for backend connections, but things
change).

Unless nginx is actually calculating itself and I can ignore passing
that (?)

Yes, nginx always uses Content-Length of actual reply returned by
uri in X-Accel-Redirect (i.e. actual file length).

If you want to pass something else, you may use something like
this:

š šlocation /foo/protected/ {
š š š šadd_header šP3P š$upstream_http_p3p;
š š š š…
š š}

well the idea was to decouple the application logic from the webserver
as much as possible :slight_smile:

Maxim D.