When I switched from Apache to Nginx, I didn’t notice an issue I
introduced in my website. Static files are displayed into the browser
instead of being downloaded. It’s the case for PDF files and more
surprising Zip files. How comes? Did I forget some kind of
configuration?
On Wed, Jun 09, 2010 at 04:40:05PM +0200, Axel wrote:
Hi guys,
When I switched from Apache to Nginx, I didn’t notice an issue I introduced in my website. Static files are displayed into the browser instead of being downloaded. It’s the case for PDF files and more surprising Zip files. How comes? Did I forget some kind of configuration?
Do you have this or similar line in configuration:
I tried to review all my configuration. I do not understand why PDF
files are returned inline to the browser. Images, videos and flash files
are properly sent, why not pdt and zip?
has anyone the same issue?
I tried to review all my configuration. I do not understand why PDF files are returned inline to the browser. Images, videos and flash files are properly sent, why not pdt and zip?
has anyone the same issue?
You have it in debug log, in part where nginx test location. Because
nginx test all you location that you have in your config, the uri with
pdf file is captured by / location and proxed to fastcgi. With Igor
suggestion, pdf will be added to static content location. But I will
suggest, to properly configured the location that are responsible for
capturing php file, because you will have a problem with all different
types of files, that you don’t put in that static location. like doc,
xls, odt … whatever.
On Wed, Jun 09, 2010 at 08:06:35PM +0200, Axel wrote:
I tried to review all my configuration. I do not understand why PDF files are returned inline to the browser. Images, videos and flash files are properly sent, why not pdt and zip?
has anyone the same issue?
thanks for your answers. The thing is that I use a framework (Kohana)
with rewrite rules. With your system Grzegorz, an URL like XXXX (rewritten by the framework in
video.php?id=1) will not be parsed as PHP, will it? I found and adapted
this server configuration for Kohana. Obviously it doesn’t work
properly.
I also tried to have a very simple / location (like yours), a .php
location and a kohana location. But this http://www.xxxx.com/ (with auto
index to index.php) doesn’t work either. When U browse this URL, the
index.php is downloaded instead of being parsed.
thanks for your help. Actually I wrote my entire configuration file
again from scratch. It works very well now: http://pastebin.com/pCL2dy9Z
I’ll post this configuration somewhere for Kohana users because it’s
been was a pain to get it work.
Static files are now sent straight from Nginx, not fastcgi and mime
types are working fine !!!
On Thu, Jun 10, 2010 at 12:22:04PM +0200, Axel wrote:
thanks for your help. Actually I wrote my entire configuration file again from scratch. It works very well now: http://pastebin.com/pCL2dy9Z
I’ll post this configuration somewhere for Kohana users because it’s been was a pain to get it work.
This is wrong configuration.
All these
set $server_type prod;
set $medias_path /var/www/xxxx/medias;
…
are not macros, but run-time directives. They will run every request.
It’s much better to set them in place:
location @kohana
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
include hom_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
FOR PHP FILES NOT HANDLED BY KOHANA
location ~* .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
include hom_params;
}
Nearly everything works at this stage EXCEPT:
when I browse an URL like “XXXX”, this file
(share.php) does not exist in the document root therefore this URL
should be handled by @kohana.
As an answer, I get a “No input file specified”. I’m pretty sure the
.php location is taking over @kohana. I tried to add a break in @kohana
but no success.
On Thu, Jun 10, 2010 at 03:09:34PM +0200, Axel wrote:
HANDLES THE REWRITTEN URLS TO KOHANA CONTROLLER
location ~* .php$ {
when I browse an URL like “XXXX”, this file (share.php) does not exist in the document root therefore this URL should be handled by @kohana.
As an answer, I get a “No input file specified”. I’m pretty sure the .php location is taking over @kohana. I tried to add a break in @kohana but no success.
    # HANDLES THE REWRITTEN URLS TO KOHANA CONTROLLER
    location ~* .php$ {
when I browse an URL like “XXXX”, this file (share.php) does not exist in the document root therefore this URL should be handled by @kohana.
As an answer, I get a “No input file specified”. I’m pretty sure the .php location is taking over @kohana. I tried to add a break in @kohana but no success.