nginx-0.7.48

[Maxim Dounin]

Hello!

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

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

> >> 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;
> >        ...
> >    }
> 
> well the idea was to decouple the application logic from the webserver
> as much as possible :)

Maxim Dounin