Forum: NGINX nginx-0.7.48

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-04-06 12:33
(Received via mailing list)
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 Dounin.

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

    *) Bugfix: nginx could not be built on OpenBSD; the bug had
       appeared in 0.7.46.
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-04-06 18:54
(Received via mailing list)
2009/4/6 Igor Sysoev <is@rambler-co.ru>:

>    *) 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)
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-04-06 20:30
(Received via mailing list)
Hello!

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

> 2009/4/6 Igor Sysoev <is@rambler-co.ru>:
>
> > š š*) 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 Dounin
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-04-06 23:00
(Received via mailing list)
2009/4/6 Maxim Dounin <mdounin@mdounin.ru>:
> 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 :)
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-04-07 01:45
(Received via mailing list)
Hello!

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

> 2009/4/6 Maxim Dounin <mdounin@mdounin.ru>:
> > 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 :)

Maxim Dounin
This topic is locked and can not be replied to.