I would like NGINX send the content-type application/xml
for all response of a location:
My configuration is base on the documentation http://wiki.nginx.org/HttpCoreModule#types :
server {
server_name my_name
listen 8088;
keepalive_timeout 5;
location / {
proxy_pass http://myhost;
types { }
default_type application/xml
}
}
But the server always send as content-type "text/xml".
Any idea?
Related
I have the following NGINX config
events {}
http {
access_log /dev/stdout;
error_log /dev/stderr;
resolver 1.1.1.1 1.0.0.1 valid=5s ipv6=off; # CloudFlare DNS resolver
upstream myupstream {
server xyz.appspot.com:443;
}
server {
server_name www. mywebsite.com;
listen 80;
set $myupstream "xyz.appspot.com:443";
location ^~ /mypath/ {
proxy_pass https://myupstream/theirpath/; # <-------- Case A - proxy_pass via UPSTREAM
proxy_pass https://$myupstream/theirpath/; # <-------- Case B - proxy_pass via VARIABLE
proxy_set_header Host "$myupstream";
}
}
}
# TEST_URL: http://www.mywebsite.com/mypath/framework.js
# DESTINATION_URL: https://xyz.appspot.com:443/theirpath/framework.js
The problem occurs in the proxy_pass lines
When I use Case A ✅ ...
... proxy_pass via UPSTREAM... the TEST_URL returns correct header Content-Type: application/javascript as expected
When I use Case B ❌ ...
... proxy_pass via VARIABLE... the TEST_URL returns incorrect header Content-Type: text/html.
This results in faulty rendering by the browser.
How can I ensure "Case B" returns correctly like "Case A" does?
I ensured that the DESTINATION_URL is correctly returning Content-Type: application/javascript every time.
Site is hosted on a Ubuntu 18 server
Managed by runcloud.io
PHP 7.4
runcloud's nginx default config.
We have a webgl build deployed on our staging server, and unable to get it to load without throwing console errors:
You can reduce your startup time if you configure your web server to host .unityweb files using gzip compression.
wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
falling back to ArrayBuffer instantiation
I have create the following nginx config file:
location ~ .(wasm)$ {
add_header Content-Encoding gzip;
add_header Content-Type application/wasm;
}
location ~ .(unityweb)$ {
add_header Content-Encoding gzip;
add_header Content-Type application/octet-stream;
}
location ~ .(data.unityweb)$ {
add_header Content-Encoding gzip;
add_header Content-Type application/octet-stream;
}
location ~ .(wasm.framework.unityweb)$ {
add_header Content-Encoding gzip;
add_header Content-Type application/octet-stream;
}
include /etc/nginx-rc/mime.types;
types {
application/wasm wasm;
}
default_type application/octet-stream;
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types application/wasm application/octet-stream text/plain text/css text/xml application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;
I managed to host a Unity/WelGL app on a nginx server changing parameters of my Unity "Project Settings":
In "Player" tab, open "Publishing Settings":
Compression Format: Gzip
Decompression Fallback: ON
Found the solution on the Unity WebGL documentation. This is avoiding the error message.
I did not had to change my nginx configuration files.
I'm using X-Accel to serve protected content, using X-Accel-Redirect.
Is it possible to serve only a part of the file? for example, bytes range 0-x, or first 5 minutes of a video (my final goal)
It's important to do that on the server-side, so the client will not have access to the rest of the file.
Currently this is how I send the whole file:
X-Accel-Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: application/octet-stream
Content-Length: {file_size}
Content-Disposition: attachment; filename="myfile.mp4"
Accept-Ranges: bytes
X-Accel-Buffering: yes
X-Accel-Redirect: /protected/myfile.mp4
Nginx conf:
location /protected {
internal;
alias /dir/of/protected/files/;
if_modified_since off;
output_buffers 2 1m;
open_file_cache max=50000 inactive=10m;
open_file_cache_valid 15m;
open_file_cache_min_uses 1;
open_file_cache_errors off;
}
The massive hack would be to use nginx to proxy to itself with a Range header that would limit the request to a range of bytes
something like this (not tested so this probably wont work, but the idea should work):
{
... snip config ...
server {
listen 80 default_server;
listen [::]:80 default_server;
root /html;
index index.html;
location / {
proxy_pass http://localhost/content;
add_header Range btyes=0,100000;
}
location /content {
try_files $uri $uri/ =404;
}
}
}
I haven't tested Slice and X-Accel together. If each file can have a different limit defined by the backend you might configure Slice in the location and send the limit with the X-Accel-Redirect URL as below:
X-Accel-Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: application/octet-stream
Content-Length: {file_size}
Content-Disposition: attachment; filename="myfile.mp4"
Accept-Ranges: bytes
X-Accel-Buffering: yes
X-Accel-Redirect: /protected/myfile.mp4?s=0&e=$PHP_VAR
Nginx.conf
location /protected {
slice; # enable slicing
slice_start_arg s;
slice_end_arg e;
internal;
alias /dir/of/protected/files/;
if_modified_since off;
output_buffers 2 1m;
open_file_cache max=50000 inactive=10m;
open_file_cache_valid 15m;
open_file_cache_min_uses 1;
open_file_cache_errors off;
}
A global file limit
You would need to redirect the original request including the Slice parameters to truncate the file being served.
Nginx conf:
location /sample {
slice; # enable slicing
slice_start_arg s;
slice_end_arg e;
internal;
alias /dir/of/protected/files/;
if_modified_since off;
output_buffers 2 1m;
open_file_cache max=50000 inactive=10m;
open_file_cache_valid 15m;
open_file_cache_min_uses 1;
open_file_cache_errors off;
}
location /protected {
rewrite ^ /sample&s=0&e=1024; # replace for the desired file limit in bytes
}
If the rewrite directive above doesn't work, I suggest the following option using proxy_pass.
location /protected {
set $file_limit 1024 # replace for the desired file limit in bytes
set $delimiter "";
if ($is_args) {
set $delimiter "&";
}
set $args $args${delimiter}s=0&e=$file_limit;
proxy_pass $scheme://127.0.0.1/sample;
}
I have setup webserver(Nginx).
and I have deploy applications(charaset:Shift-Jis).
After deploy, accessed to applications But,There is not charset in Nginx returned response "Context-Type" header.
Could you teach me Nginx settings it.
I tried the under but it was useless.
Settings
# nginx.conf
server {
location / {
proxy_pass http://myapp.com:8080/;
charset Shift-Jis;
}
}
Response
# for example (CSS)
・・・
real)content-type: text/css
hope)content-type: text/css; charset=UTF-8
・・・
Best regards.
this is work to me.
charset utf-8;
charset_types *;
set charset_types value to (*)
You are passing the request to a proxy. In this case Headers and Charset are set by the proxy. Set the proper encoding at your Proxy Application. You can override existing charset with: override_charset on;
charset utf-8;
override_charset on;
if you want to set the source charset too:
source_charset koi8-r;
I use this config in nginx.conf.
http {
map $sent_http_content_type $charset {
default '';
~^text/ utf-8;
application/javascript utf-8;
application/rss+xml utf-8;
application/json utf-8;
application/geo+json utf-8;
}
charset $charset;
charset_types *;
...
}
How to overwrite default Content-Type in nginx? Currently when I request 01.dae file, there's
Content-Type: application/octet-stream;
And I want it to be
Content-Type: application/xml;
I tried something like
location ~* \.dae$ {
types { };
default_type application/xml;
}
and
location ~* \.dae$ {
add_header Content-Type application/xml;
}
but nothing works.
In case you have no file extension:
location ~ something {
default_type application/xml;
}
Nginx docs for default_type
In case you are setting up let's encrypt certificate with a client which creates http server: How to use golang lego let's encrypt client behind nginx?
You can edit /etc/nginx/mime.types and add it
types {
application/xml dae;
}
I haven't found the the exact string application/xml in my mime.types so I suppose you can directly include it inside your server block, in the server scope or something.
location ~* \.dae$ {
types { } default_type "application/xml; charset=utf-8";
}
Add "the application/xml dae;" to your server scope or location scope.
Or add it into the mime.type.
Both of them work for me.