Nginx not showing xml upload


(Timmmmyboy) #1

I’m trying to help someone who we host a Discourse install for get a sitemap setup and he’s following the instructions at Creating and Submitting XML Sitemaps to Google, Bing & Yandex but when he uploaded the xml file it just shows a white screen. I’m sure this is due to me configuring Nginx wrong (I have multiple discourse installs and nginx sitting on top routing requests) but it seems like all images and other uploads show fine. Is it a mime-type issue of some kind? Anything I need to add to the nginx config for it to display the xml file? Here’s the URL: http://foros.consultoria-sap.com/uploads/default/original/1X/a653bb5c037cd47c0717c07b65eaaf286220ce77.xml


(Matt Palmer) #2

Interesting… nginx is returning an empty page for a 404 error. It isn’t a media type error, and without seeing exactly what your nginx config looks like, it’s hard to say whether the error might be there or not. Could you post it here for examination?


(Timmmmyboy) #3

Sure thing, we add a line like this one for each Discourse install:

server {
    listen 80;
    # change this
    server_name foros.consultoria-sap.com;
    client_max_body_size 100M;
    location / {
    proxy_pass http://unix:/var/discourse/shared/consultoria/nginx.http.sock:;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

The shared folder does indeed hold the xml file and all other images appear so I’m not sure why it doesn’t seem to like that particular file type. Just in case the main nginx.conf file is useful I"m pasting that below as well:

user www-data;
worker_processes 4;
pid /run/nginx.pid;

events {
worker_connections 768;
# multi_accept on;
}

http {

##
# Basic Settings
##

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;

# server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

##
# nginx-naxsi config
##
# Uncomment it if you installed nginx-naxsi
##

#include /etc/nginx/naxsi_core.rules;

##
# nginx-passenger config
##
# Uncomment it if you installed nginx-passenger
##

#passenger_root /usr;
#passenger_ruby /usr/bin/ruby;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}


#mail {
#	# See sample authentication script at:
#	# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#	# auth_http localhost/auth.php;
#	# pop3_capabilities "TOP" "USER";
#	# imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#	server {
#		listen     localhost:110;
#		protocol   pop3;
#		proxy      on;
#	}
# 
#	server {
#		listen     localhost:143;
#		protocol   imap;
#		proxy      on;
#	}
#}

(Matt Palmer) #4

Well, it doesn’t look like nginx is at fault – in fact, it doesn’t serve static assets at all, but passes all requests through to Unicorn (or whatever app server you’ve got). That means that the problem is going to be in Discourse itself, or the middleware stack on top. Are there any customisations you’ve applied, or plugins installed, above and beyond a basic install?


(Timmmmyboy) #5

Standard Docker install with these 3 plugins enabled: