Ik krijg de volgende foutmelding op mijn Chrome-console:
GET http://localhost/grunt/vendor/angular/angular.js net::ERR_CONTENT_LENGTH_MISMATCH
Dit gebeurt alleen wanneer gelijktijdige verzoeken naar nginx worden gestuurd, b.v. wanneer de browsercache leeg is en de hele app wordt geladen. Het laden van de bovenstaande bron als een enkel verzoek is gelukt.
Hier zijn de headers van deze verzoeken, gekopieerd uit Chrome:
Remote Address:127.0.0.1:80
Request URL:http://localhost/grunt/vendor/angular/angular.js
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,de;q=0.6,pl;q=0.4,es;q=0.2,he;q=0.2,gl;q=0.2
Cache-Control:no-cache
Connection:keep-alive
Cookie:gs_u_GSN-265185-D=1783247335:2567:5000:1377697930719
Host:localhost
Pragma:no-cache
Referer:http://localhost/grunt/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.122 Safari/537.36
Response Headersview source
Accept-Ranges:bytes
Cache-Control:public, max-age=0
Connection:keep-alive
Content-Length:873444
Content-Type:application/javascript
Date:Tue, 23 Sep 2014 11:08:19 GMT
ETag:"873444-1411465226000"
Last-Modified:Tue, 23 Sep 2014 09:40:26 GMT
Server:nginx/1.6.0
de werkelijke grootte van het bestand:
$ ll vendor/angular/angular.js
-rw-rw-r-- 1 xxxx staff 873444 Aug 30 07:21 vendor/angular/angular.js
Zoals je kunt zien zijn Content-Lengthen de werkelijke grootte van het bestand hetzelfde, dus dat is raar
En de nginx-configuratie voor deze proxy:
location /grunt/ {
proxy_pass http://localhost:9000/;
}
Enig idee?
Bedankt
EDIT: meer informatie gevonden in het foutenlogboek:
2014/09/23 13:08:19 [crit] 15435#0: *8 open() "/usr/local/var/run/nginx/proxy_temp/1/00/0000000001" failed (13: Permission denied) while reading upstream, client: 127.0.0.1, server: localhost, request: "GET /grunt/vendor/angular/angular.js HTTP/1.1", upstream: "http://127.0.0.1:9000/vendor/angular/angular.js", host: "localhost", referrer: "http://localhost/grunt/"
Antwoord 1, autoriteit 100%
Het toevoegen van de volgende regel aan de nginx-configuratie was het enige dat de net::ERR_CONTENT_LENGTH_MISMATCH-fout voor mij oploste:
proxy_buffering off;
Antwoord 2, autoriteit 74%
Het lijkt erop dat nginx onder druk probeerde angular.jsuit zijn cache te halen en dit niet kon vanwege toestemmingsproblemen. Dit is wat dit probleem heeft opgelost:
root@amac-2:/usr/local/var/run/nginx $ chown -R _www:admin proxy_temp
_www:adminkan in jouw geval anders zijn, afhankelijk van welke gebruiker het nginx-proces bezit. Zie meer informatie over ServerFault:
https://serverfault.com/questions/534497/why -do-nginx-process-run-with-user-nobody
Antwoord 3, autoriteit 56%
Ik heb al het bovenstaande geprobeerd en kreeg het nog steeds niet werkend. Zelfs na gebruik te hebben gemaakt van chmod 777. Het enige dat het voor mij oplostewas om caching volledig uit te schakelen:
proxy_max_temp_file_size 0;
Hoewel het geen oplossing is en niet goed is voor productiegebruik, was dit oké voor mij, aangezien ik nginx alleen gebruik als onderdeel van een lokale ontwikkelingsopstelling.
Antwoord 4, autoriteit 32%
Voor mij waren deze twee instellingen de oplossing:
In het bestand:
/etc/nginx/nginx.conf
Toevoegen:
proxy_max_temp_file_size 0;
proxy_buffering off;
Tussen de regels client_max_body_size 128M;en server_names_hash_bucket_size 256;:
http {
client_max_body_size 128M;
proxy_max_temp_file_size 0;
proxy_buffering off;
server_names_hash_bucket_size 256;
Antwoord 5, autoriteit 16%
ps aux | grep "nginx: worker process"
na het uitvoeren van bovenstaande opdracht zie je de gebruiker waardoor nginx draait
bijv.
www-data 25356 0.0 0.0 68576 4800 ? S 12:45 0:00 nginx: worker process
www-data 25357 0.0 0.0 68912 5060 ? S 12:45 0:00 nginx: worker process
nu moet je onderstaande opdracht uitvoeren om toestemming te geven
chown -R www-data:www-data /var/lib/nginx/
Hoop dat het werkt
Antwoord 6, autoriteit 5%
Voor ons bleek de vrij kleine root van onze server (bijv. /) vol te zijn.
Het had bergen logs en bestanden van gebruikers in /home. Het verplaatsen van al die rommel naar een andere aangekoppelde schijf loste dingen op.
Ik wilde het alleen delen, omdat dit een andere oorzaak van het probleem kan zijn.
Antwoord 7, autoriteit 5%
Als iemand in het verleden nginx als een andere gebruiker heeft uitgevoerd, kan het eigendom van de cachemap worden verdraaid. ik heb
/var/cache/nginx# LANG=C ls -l proxy_temp/
total 40
drwx------ 18 nginx nginx 4096 Jul 14 2016 0
drwx------ 19 nginx nginx 4096 Jul 14 2016 1
drwx------ 19 nginx nginx 4096 Jul 14 2016 2
drwx------ 19 nginx nginx 4096 Jul 14 2016 3
drwx------ 19 nginx nginx 4096 Jul 14 2016 4
drwx------ 19 nginx nginx 4096 Jul 14 2016 5
drwx------ 19 nginx nginx 4096 Jul 14 2016 6
drwx------ 18 nginx nginx 4096 Jul 14 2016 7
drwx------ 18 nginx nginx 4096 Jul 14 2016 8
drwx------ 18 nginx nginx 4096 Jul 14 2016 9
terwijl nginx draaide als www-data. Dus de oplossing is om het eigendom van de cachedirectory van nginx te veranderen in de gebruiker waar nginx onder draait. In het onderhavige geval
/var/cache/nginx# chown -R www-data:www-data *
of, nog eenvoudiger
# rm -r /var/cache/nginx/*
Antwoord 8, autoriteit 2%
Wat voor mij werkte, was om het proxy_temp_path te wijzigen in een map met lees-/schrijfrechten (777)
location / {
proxy_temp_path /data/tmp;
}
Antwoord 9, autoriteit 2%
Ik had hetzelfde probleem.
Het vergroten van de ruimte van Directoryof Mapwaar nginx is geïnstalleerd, loste het probleem op.
Antwoord 10
Toen ik de bovengenoemde oplossing probeerde, werd het probleem niet opgelost. Ik heb ook de toestemming om op de locatie te schrijven gewijzigd, maar het werkte niet. Toen realiseerde ik me dat ik daar iets verkeerd deed. Op de locatie om het bestand op te slaan, had ik zoiets als
“/storage” + bestandsnaam + “.csv”
. Ik was aan het testen in de Windows-omgeving en het werkte prima. Maar toen we de applicatie later naar de Linux-omgeving verhuisden, werkte deze niet meer. Dus later moest ik het veranderen in
“./storage” + bestandsnaam + “.csv”
en het begon normaal te werken.
Antwoord 11
Voor mij was de oplossing:
sudo chown -R nginx:nginx /var/cache/nginx/fastcgi_temp/
Antwoord 12
Voor iedereen die HAProxy als proxy gebruikt en exact dezelfde symptomen kreeg, loste het verhogen van de time-outwaarden het probleem voor mij op:
time-out verbinding 5000
time-outclient 50000
time-outserver 50000
Antwoord 13
Het enige dat me hielp waren de volgende instellingen in het nginx-site .conf-bestand:
proxy_read_timeout 720s;
proxy_connect_timeout 720s;
proxy_send_timeout 720s;
Antwoord 14
Bij mij had ik dezelfde fout, behalve op een
andere map /var/lib/nginx/.
Ik heb de eigenaar veranderd in nginx door
chown -R nginx:nginx /var/lib/nginx/. Dat werkte niet.
Vervolgens heb ik gecontroleerd wie de eigenaar was van het nginx worker processdoor
ps aux| grep nginx
En het draaide als nginx, maar toen ik door het bestand nginx.conf keek; Ik ontdekte dat de gebruiker nginx was, maar deze had geen groep. Dus ik heb nginx toegevoegd aan de gebruiker nginx; het is zo geworden
user nginx nginx
Nu heb ik het systeem opnieuw opgestart en het probleem was verholpen. Ik denk dat ik gewoon
. had kunnen gebruiken
chown -R nginx /var/lib/nginx/
Dat had misschien ook gewerkt. Dus als iemand met dit probleem wordt geconfronteerd; ga eerst naar var/log/nginxen
controleer waar de toestemmingsfout is opgetreden.