Caching-Location verhindert Socket.io.js

Scrayos · 9. September 2015

Hallo,

ich bin an ein für mich nicht ersichtliches Problem gestoßen. Ich weiß, dass dieses Problem wohl nicht unmittelbar mit nodePush zusammenhängt - ich hoffe aber, dass mir unter Umständen einer der kompetenten Nutzer hier weiterhelfen kann, denn ich hatte nodePush aber auf einem anderen Server unter gleicher Konfiguration problemlos laufen, weshalb bei mir eine gewisse Ratlosigkeit eintritt. Ich habe beide meiner Caching-Anweisungen auskommentiert (Zeile 34 - 41), da diese mit nodePush kollidieren. Sobald ich sie auskommentiere, erhalte ich beim Aufruf der socket.io/socket.io.js-Datei eine 404-Response. Der Grund hierfür ist für mich nicht klar ersichtlich, ich gehe stark von einem eigenen Fehler aus. Denkbar für mich ist, dass dieser 404-Fehler auftritt, da der Caching-Block zur Interpretation genommen wird, und der /socket.io/-Block eben nicht. So würde sich auch die Tatsache erklären, dass https://www.justchunks.net/socket.io/ bei jeder Konfiguration erreichbar bleibt.

Ich möchte prinzipiell nicht die Zeit der hier anwesenden Nutzer verschwenden, fand aber für diesen spezifischen Fall leider auch nach intensiver Recherche keine Abhilfe - Vermutlich aufgrund des mangelnden Verständnisses des Durchlaufs eines Aufrufs von nginx.

Code

server {
        listen 443 ssl spdy;
        root /var/www;
        index index.php index.html;
        try_files $uri $uri/ @rewrite;
        server_name www.justchunks.net;


        ssl on;
        ssl_certificate /etc/ssl/certs/www-justchunks-net.crt;
        ssl_certificate_key /etc/ssl/private/www-justchunks-net.key;
        ssl_dhparam /etc/ssl/private/dhparams.pem;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:50m;
        ssl_session_timeout 30m;
        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/ssl/private/comodo.pem;


        add_header Alternate-Protocol  443:npn-spdy/2;
        add_header Strict-Transport-Security max-age=31536000;
        add_header X-Frame-Options DENY;


        location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            try_files $fastcgi_script_name =404;
            fastcgi_index   index.php;
            fastcgi_pass    unix:/var/run/php5-fpm.sock;
            include         fastcgi_params;
        }




        #location ~* \.(?:manifest|appcache|html|xml|json)$ {
        #    expires -1;
        #}


        #location ~* \.(?:jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|eot|mp4|ogg|ogv|webm|js|css|rss|atom)$ {
        #    expires 1w;
        #    add_header Cache-Control "public";
        #}




        location /socket.io/ {
        		proxy_pass http://unix:/var/www/wcf/acp/be.bastelstu.wcf.nodePush/tmp/outbound.sock;
        		proxy_http_version 1.1;
        		proxy_hide_header X-Powered-By;
                        proxy_set_header Host $host;
                        proxy_set_header X-Real-IP $remote_addr;
        		proxy_set_header X-Forwarded-For $remote_addr;
        		proxy_set_header Upgrade $http_upgrade;
        		proxy_set_header Connection "upgrade";
        }


        location @rewrite {
            rewrite ^/(wcf/|forum/|bugtracker/|wiki/|shop/|panel/|/)?([^/]+)/?([^/]+)?/? /$1/index.php?$2/$3 last;
        }


        rewrite /page/home / permanent;
    }

Alles anzeigen

Vielen Dank im Voraus,
Scrayos

**Tim** · 9. September 2015

Hallo,

Klassischer „RTFM“-Fehler: http://nginx.org/en/docs/http/request_processing.html

Das Problem ist, dass Regex-Locations grundsätzlich Priorität vor nicht-Regex-Locations haben. Entweder du lässt das Shotgun-mäßige-Caching einfach raus (was ich empfehle, der Browser überprüft dann nur noch, ob sich die Datei geändert hat, was mit SPDY ohnehin schnell genug ist), oder du packst eine location / außen um deine generischen Regeln und packst sie unter eine location /socket.io, weil die nicht-Regex-Locations von oben nach unten verarbeitet werden.

Nachfolgend findest du meine Konfiguration (welche schon bereit für NodePush 2 ist):

Code

server {
	listen 443 ssl spdy;
	listen [::]:443 ssl spdy;

	include /etc/nginx/ssl-common.conf;
	ssl_certificate /etc/nginx/ssl/be.bastelstu.tims.crt;

	server_name tims.bastelstu.be;
	include /etc/nginx/common.conf;

	access_log /var/log/nginx/be/bastelstu/tims/access.log;
	error_log /var/log/nginx/be/bastelstu/tims/error.log;

	root /srv/www/be/bastelstu/tims;
	index index.php;

	rewrite ^(.*/)index\.php/([^?]*)$ $1index.php?$2 permanent;
	rewrite ^(.*/)index\.php/(.*)(\?(.*))$ $1index.php?$2&$4 permanent;


	location ~ (index|wcf/acp/dereferrer|wcf/font/getFont)\.php(/.*$|$) {
		include /etc/nginx/php-common.conf;
		fastcgi_read_timeout 120s;
		fastcgi_pass unix:/var/run/php5-bastelstube.sock;
	}

	location ~ (?U)\.php(/.*$|$) {
		return 403;
	}

	location ~ ^/wcf/(acp/be\.bastelstu\.wcf\.nodePush/|attachments|tmp|cache|log|language|style/.*\.less) {
		return 403;
	}


	location ~ ^/([a-z]+/)?(templates|lib) {
		return 403;
	}

	location /wcf/images/avatars/gravatars/ {

	}

	location /wcf/images/avatars/ {
		expires max;
	}


	location /deliver/ {
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $host;
		proxy_pass http://127.0.0.1:9100;
        }

	location /socket.io/ {
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $host;
		proxy_pass http://127.0.0.1:9100;
		proxy_http_version 1.1;
		proxy_hide_header X-Powered-By;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
        }
}

Alles anzeigen

Ansonsten: Sehr schöne Konfiguration, ich habe für den nginx schon viel schlimmes gesehen! Ich empfehle aber noch einige generische Dinge in den conf.d-Ordner auszulagern (wenn du Debian verwendest). Die SSL-Konfiguration findet sich bei mir auch in einer Extra-Datei, damit man sie leicht wiederverwenden kann.

Scrayos · 9. September 2015

Vielen Dank für die schnelle Rückmeldung und die Hilfe, obwohl es ja nichts mit dem Produkt als solches zu tun hat!

Ich habe nun einfach die Caching-Blöcke entfernt und meine Blöcke durch deine IPv6-listen-Anweisungen ergänzt, die kannte ich nämlich noch nicht

Bislang habe ich keine externen Configs gehabt, da ich nur drei Server-Blöcke habe, welche alle zum selben Projekt gehören und eben für http, https ohne www und den standard https-www-block kaum dinge mehrfach verwenden musste. Habe nun aber ssl ausgelagert, da ich dies zumindest zwei mal verwende