Because currently only Chrome and Opera supports WebP, I was wondering if I could target those two particular browsers and redirect them to fetch another version of my website so I can help optimize my site downloading speed more faster?
Thanks.
I solved this problem like this:
Check if the client advertises "image/webp" in Accept header
If WebP is supported, check if the local WebP file is on disk, and
serve it
If server is configured as proxy, append a "WebP: true" header and
forward to backend
Append "Vary: Accept" if a WebP asset is served
in Nginx:
location / {
if ($http_accept ~* "webp") { set $webp "true"; }
# Use $webp variable to add correct image.
}
In my case, I use thumbor software to convert images.
https://github.com/globocom/thumbor
pip install thumbor
My conf:
upstream thumbor {
server 127.0.0.1:9990;
server 127.0.0.1:9991;
server 127.0.0.1:9992;
server 127.0.0.1:9993;
server 127.0.0.1:9994;
}
location / {
if ($http_accept ~* "webp") {
set $webp "T";
}
if ($uri ~* "(jpg|jpeg)$") {
set $webp "${webp}T";
}
proxy_cache_key $host$request_uri$webp;
if ($webp = "TT") {
rewrite ^(.*)$ "/unsafe/smart/filters:format(webp)/exemple.com$uri" break;
proxy_pass http://thumbor;
add_header Content-Disposition "inline; filename=image.webp";
}
if ($webp != "TT") {
proxy_pass http://exemple.com;
}
}
For a while now, thumbor supports automatic webp conversion:
https://github.com/thumbor/thumbor/wiki/Configuration#auto_webp
You'll still have to configure the load balancer to pass the webp accepts header, but other than that, thumbor will take care of everything for you.
Hope that helps!
Related
In image #1, as you can see, I am getting a valid ES response on firing a GET request. However, if I try doing the same things through the NGINX reverse proxy that I have created and hit myip/elasticsearch, it returns me the error (image #2). Can someone help me with this?
server {
listen 80;
server_name myip;
location /elasticsearch/ {
proxy_pass http://127.0.0.1:9200;
}
location /kibana/ {
proxy_pass http://127.0.0.1:5601;
}
}
The right way is to specify both of those slashes. Slash after 127.0.0.1:9000 is essential, without it your request /elasticsearch/some/route would be passed as-is while with that slash it would be passed as /some/route. In nginx terms it means that you specified an URI after the backend name. That is, an URI prefix specified in a location directive (/elasticsearch/) stripped from an original URI (we having some/route at this stage) and an URI specified after the backend name (/) prepended to it resulting in / + some/route = /some/route. You can specify any path in a proxy_pass directive, for example, with proxy_pass http://127.0.0.1:9200/prefix/ that request would be passed to the backend as /prefix/some/route. Now if you understand all being said, you can see that specifying location /elasticsearch { ... } instead of location /elasticsearch/ { ... } would give you //some/route instead of /some/route. I'm not sure it is exactly the cause of your problem however configurations like
location /elasticsearch/ {
proxy_pass http://127.0.0.1:9200/;
}
are more correct.
Now may I ask you what you get with exactly this configuration in response to curl -i http://localhost:9200/ and curl -i http://localhost/? I want to see all the headers (of cause except those containing private information).
The problem is the path. Nginx is passing it unmodified.
Add a slash at the proxy_pass urls.
server {
listen 80;
server_name myip;
location /elasticsearch/ {
proxy_pass http://127.0.0.1:9200/;
}
location /kibana/ {
proxy_pass http://127.0.0.1:5601/;
}
}
From the documentation:
Note that in the first example above, the address of the proxied server is followed by a URI, /link/. If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the /some/path/page.html URI will be proxied to http://www.example.com/link/page.html. If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).
I have a web2py configuration, operating on top of nginx, which is producing a 404 error when browser caching is implemented for certain static files. The problem is described here, and I'm now asking this question within a web2py context, because that may be relevant to the issue, or because there may be some web2py-specific workaround or solution.
nginx.conf looks like this:
worker_processes 3;
events {
worker_connections 1024;
}
http {
access_log [/...];
error_log [/...] crit;
include mime.types;
sendfile on;
server {
server_name [...] [...];
return 301 [...] $request_uri;
}
server {
listen 127.0.0.1:[...];
root [/...];
location / {
include uwsgi_params;
uwsgi_pass [.../uwsgi.sock];
}
}
}
Adding the following line either before or after the "location" clause above causes the server to stop serving the static files, which match the pattern in question:
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 1d;
}
It was suggested in the previous thread that this may be a uwsgi issue, although it's possible that the problem is caused by other issues. How can I implement browser caching, without causing the "404" issue?
It seems to me that you are serving only dynamic content. Also, nginx selects a location block to process a request, and it needs to be complete.
In your case, the uwsgi configuration from the location / block needs to be replicated across any new dynamic locations you may add. For example:
server {
...
include uwsgi_params;
location / {
uwsgi_pass [.../uwsgi.sock];
}
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 1d;
uwsgi_pass [.../uwsgi.sock];
}
}
You can probably move the include statement into the outer block and allow its statements to be inherited (assuming it only contains uwsgi_param statements).
I want to load balance my website with nginx.
The load balancing in nginx wiki is proxy, so the actual file being downloaded from the frontend server. (http://wiki.nginx.org/LoadBalanceExample)
This is how I need the balancing:
user request file:
http:// site.com/image1.jpg
nginx redirect user to one of the servers (with Location header):
http:// s1.site.com/image1.jpg
http:// s1.site.com/image1.jpg
http:// s3.site.com/image1.jpg
Is this possible with nginx?
http {
split_clients "${remote_addr}" $server_id {
33.3% 1;
33.3% 2;
33.4% 3;
}
server {
location ~* \.(gif|jpg|jpeg)$ {
return 301 "${scheme}://s${server_id}.site.com${request_uri}";
}
}
I'm using Joomla in combination with Nginx, and I'm currently trying to achieve some URL rewriting for a website that has several langages supported (italian, french, chinese, and deutch)
The urls have the country code after the domain name, like so :
http://www.example.com/fr/test/test.html
or
http://www.example.com/de/test/test.html
I'm looking to rewrite the urls so the country code is part of the subdomain :
so
http://www.example.com/fr/test/test.html
becomes
http://fr.example.com/test/test.html
Is there a way to achieve this with Nginx or should I look into a third party extension for Joomla (not my favorite choice).
Thanks !!
Update :
I wasn't clear enough : I wanted the redirection from the rewrited URL to be transparent. Here is what I came up with, thanks to VBart help :
server {
server_name ~^(?<lang>.+)\.example\.com$;
location / {
rewrite /(.*)$ /$lang/$1 break;
proxy_pass http://www.example.com;
proxy_redirect http://www.example.com http://$lang.example.com/$request_uri;
}
}
Now, is there a way for Nginx to modify links on the fly in the served content ? ie: I want all the link in the generated page to look like http://fr... instead of http://.../fr/... ?
server {
server_name ~^(?<lang>.+)\.example\.com$;
...
}
server {
server_name www.example.com;
rewrite ^/(?<lang>[a-z]+)(?<rest>.+)$ http://$lang.example.com$rest? permanent;
}
opposite example:
server {
server_name ~^(?<lang>.+)\.example\.com$;
return 301 http://www.example.com/$lang$request_uri;
}
server {
server_name www.example.com;
...
}
I need to do a rewrite with nginx from /blah/.../3275 to /id/3275 if the second file exists, otherwise I want to hand it off to apache. Here is my (feeble) attempt
(...) represents irrelevant stuff
if ($request_filename ~^/.../([0-9]+)/$) {
if (-d /id/$1) {
rewrite ^/.../[0-9]+/([0-9]+)/$ /id/$1;
}
}
Does anyone have any ideas
Best to do this with internal rewrites:
set $original_uri $uri;
location /blah/irrelevant_stuff {
error_page 404 = #apache;
rewrite ^/blah/irrelevant_stuff/([0-9]+)$ /id/$1;
}
location #apache {
proxy_pass http://upstream$original_uri;
}
The above answer from wulong I couldn't get to work for some reason but I did get it to work by using
if (!-e $request_filename) {
proxy_pass http://apache$original_uri;
break;
}
rather than the error_page directive. Same idea basically