I have found an interesting problem.
I am trying to serve some gzipped files without the sources using NGINX's gzip_static module (I know the downsides to this). This means you can have gzipped files on the server that will be served with transfer-encoding: gzip. For example, if there's a file /foo.html.gz, a request for /foo.html will be served the compressed file with content-encoding: text/html.
While this usually works it turns out that when looking for index files in a directory the gzipped versions are not considered.
GET /index.html
200
GET /
403
I was wondering if anyone knows how to fix this. I tried setting index.html.gz as in index file but it is served as a gzip file rather then a gzip encoded html file.
This clearly won't work this way.
This is a part of the module source:
if (r->uri.data[r->uri.len - 1] == '/') {
return NGX_DECLINED;
}
So if the uri ends in slash, it does not even look for the gzipped version.
But, you probably could hack around using rewrite.
(This is a guess, I have not tested it)
rewrite ^(.*)/$ $1/index.html;
Edit: To make it work with autoindex (guess) you can try using this instead of rewrite:
location ~ /$ {
try_files ${uri}/index.html $uri;
}
It probably is better overall than using rewrite. But you need to try ...
You can prepare your precompressed files then serve it.
Below it's prepared by PHP and served without checking if the client supports gzip.
// PHP prepare the precompressed gzip file
file_put_contents('/var/www/static/gzip/script-name.js.gz', gzencode($s, 9));
// where $s is the string containing your file to pre-compress
// NginX serve the precompressed gzip file
location ~ "^/precompressed/(.+)\.js$" {
root /var/www;
expires 262144;
add_header Content-Encoding gzip;
default_type application/javascript;
try_files /static/gzip/$1.js.gz =404;
}
# Browser request a file - transfert 113,90 Kb (uncompressed size 358,68 Kb)
GET http://inc.ovh/precompressed/script-name.js
# Response from the server
Accept-Ranges bytes
Cache-Control max-age=262144
Connection keep-alive
Content-Encoding gzip
Content-Length 113540
Content-Type application/javascript; charset=utf-8
ETag "63f00fd5-1bb84"
Server NginX
Related
I have a question about serving gzipped static files from nginx. I did gzip -k style.min.css to produce style.min.css.gz and I uploaded it to the server in the static-root directory. My location block is an exact match and looks like this:
location =/style.min.css {
root /home/ubuntu/.../static-root/;
gzip_static on;
expires 100d;
add_header Cache-Control "public";
access_log off;
}
Will nginx just serve up the style.min.css.gz in place of the style.min.css automagically, or do I have to tweak that location block so that the gzipped version is served?
Given the exact match at that location block this test does 404
$ curl -I https://example.com/style.css.gz -H "Accept-Encoding: gzip"
HTTP/1.1 404 Not Found
Is the compressed version still getting served up or do I need to tweak the location block to something like this so that the .gz file gets served?
location ~ /(style.min.css.*) {...
Update ... I can confirm that a gzipped version of a static css file is returned. So it seems to happen automatically. I don't know if the gzip on; in the server section or the gzip_static on; takes care of it but it is working.
$ curl -H "Accept-Encoding: gzip" -I https://example.com/bsmin.css
HTTP/1.1 200 OK
Cache-Control: max-age=7673705, public
Cache-control: no-cache="set-cookie"
Content-Encoding: gzip
From the official documentation https://docs.nginx.com/nginx/admin-guide/web-server/compression/ under Sending Compressed Files
to service a request for /path/to/file, NGINX tries to find and send the file /path/to/file.gz. If the file doesn’t exist, or the client does not support gzip, NGINX sends the uncompressed version of the file.
Note that the gzip_static directive does not enable on-the-fly compression. It merely uses a file compressed beforehand by any compression tool. To compress content (and not only static content) at runtime, use the gzip directive.
I have create a new stack where Nginx server act as a reverse proxy between a CDN server and the browser, and the Nginx server supposed to resolve SSIs of all the HTML files from the CDN.
The issue is Nginx server resolves only Content-type:text/html type files not application/octet-stream (even though all of them are actual .html files despite the content-type, it is a glitch on our company's CDN)
location /path/ {
ssi on;
add_header Content-Type text/html;
proxy_pass https://example-cdn.com/path/;
}
Is there a way to force Nginx to resolve any file as long as the extension is .html despite the Content-type header in the CDN response?
I created a secondary server in the same config, rewriting the Content-Type based on the extension and consuming the content for the primary nginx server from there.
Secondary server in the same config
# Mapping
map $uri $custom_content_type {
default "application/octet-stream";
~(.*.json)$ "application/json";
~(.*.html)$ "text/html";
~(.*.pdf)$ "application/pdf";
}
server {
listen 8090;
server_name localhost;
location /path/ {
proxy_hide_header Content-Type;
add_header Content-Type $custom_content_type;
proxy_pass https://example-cdn.com/path/;
}
}
Primary server
location /path/ {
proxy_pass http://localhost:8090/path/;
}
still open for a more efficient solution.
Inside /var/www/storage/ folder located only mp3 files. What I want to do is, to make every request to those files to end up with download rather than playing in browser.
My current config looks like this, I can't figure out what is wrong.
server {
charset utf-8;
client_max_body_size 128M;
listen 80; ## listen for ipv4
server_name dl.domain.com;
root /var/www/storage/;
location / {
add_header Content-Disposition: "$request_filename";
}
}
Your initial configuration is almost correct, all you are forgetting is the "attachment":
add_header Content-Disposition "attachment; filename=$request_filename";
It's also recommended that you do the application/octet-stream as suggested by raven428. However I believe you will get the "save as" in most UAs without adjusting the Content-Type.
Per RFC 2616 sec19.5.1 :
If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.
browser decision to play or download depends on content-type header. if you want to force browser download file instead of play, your webserver should return Content-Type: application/octet-stream for mp3 files:
location ~ /mp3folder/.+\.mp3$ {
types {
application/octet-stream;
}
}
I'm using nginx as my server and want to serve some static files, mostly code files, such as .py .java files. but when I do this, nginx directly make the browser download the files as visit
http://localhost:8001/test.py
I know that should be Conten-Type , but I've already configured. below is part of sample nginx config file.
default_type text/plain;
server {
listen 8001;
server_name localhost;
location / {
add_header Content-Type text/plain;
root /path/to/files/;
}
}
so, how to make the browser directly display the file instead of download? Just use nginx static serve or need add some configs?
thx a lot.
ok, I know how to do that.just forgot to do that :(
just add the config
autoindex on;
to server or location section in nginx.
that's waht I want.
I have a stylesheet gzip compressed on disk and would like to serve it via nginx. It's named file.css.xgz and it should have
Content-Type: text/css
Content-Compression: gzip
So I added this to mime.types:
text/css css css.xgz;
And this to my server configuration:
location ~* \.xgz$ {
add_header Content-Encoding gzip;
}
Server is restarted for sure, but the content-type is still application/octet-stream (Content-Encoding is set as expected).
Try just "xgz" in the mime type in place of "css.xgz"