2014-09-23 15 views
23

Dostaję następujący błąd na mojej konsoli chrome:ERR_CONTENT_LENGTH_MISMATCH na nginx i pełnomocnika w Chrome podczas ładowania dużych plików

GET http://localhost/grunt/vendor/angular/angular.js net::ERR_CONTENT_LENGTH_MISMATCH 

Dzieje się tak tylko przy jednoczesnym wnioski są kręcone w kierunku np nginx kiedy pamięć podręczna przeglądarek jest pusta i ładuje się cała aplikacja. Ładowanie powyższego zasobu jako pojedynczych żądań zakończy się pomyślnie.

Oto nagłówki do tej prośby, kopiowane z 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 

prawdziwy rozmiar pliku:

$ ll vendor/angular/angular.js 
-rw-rw-r-- 1 xxxx staff 873444 Aug 30 07:21 vendor/angular/angular.js 

Jak widać Content-Length a prawdziwa wielkość pliku są to samo, więc to jest dziwne

Konfiguracja nginx do tego proxy:

location /grunt/ { 
    proxy_pass http://localhost:9000/; 
} 

Wszelkie pomysły?

Dzięki

EDIT: znaleziono więcej informacji na temat dziennika błędów:

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/" 

Odpowiedz

32

Wydaje się, że pod presją, nginx próbował ciągnąć angular.js z pamięci podręcznej i nie mógł z powodu problemów uprawnień. Oto, co rozwiązuje ten problem:

[email protected]:/usr/local/var/run/nginx $ chown -R _www:admin proxy_temp 

_www:admin może być różny w zależności od przypadku, który użytkownik jest właścicielem procesu Nginx. Zobacz więcej informacji na ServerFault:

https://serverfault.com/questions/534497/why-do-nginx-process-run-with-user-nobody

+2

Dzięki za podpowiedź, wpadłem na to z moim HomeBrew nginx po aktualizacji do El Capitan –

+0

Cieszę się, że nadal jest pomocne! – amit

+2

Na wypadek, gdyby ktoś nadal borykał się z tym problemem - możesz potrzebować podwójnego sprawdzenia użytkownika, pod którym działa 'nginx'. W moim przypadku folder był z odpowiednimi uprawnieniami i własnością, ale po prostu nginx działał pod 'nobody.nobody'. – tftd

19

Próbowałem wszystkie powyższe i wciąż nie może zmusić go do pracy. Nawet po odwołaniu do chmod 777. Jedyną rzeczą, która rozwiązany to dla mnie było całkowicie wyłączyć buforowanie:

proxy_max_temp_file_size 0;

Chociaż nie kropce i nie jest dobre do użytku produkcyjnego to było OK dla mnie, ponieważ jestem tylko przy użyciu nginx jako część lokalna konfiguracja programistyczna.

0

Po wypróbowaniu wspomnianego rozwiązania problemu nie rozwiązano. Zmieniłem też pozwolenie na pisanie na miejscu, ale to nie zadziałało. Wtedy zdałem sobie sprawę, że zrobiłem coś złego. W miejscu, aby zapisać plik, miałem coś podobnego

"/ przechowywanie" + fileName + ".csv"

. Testowałem w środowisku Windows i działało świetnie. Ale później, kiedy przenieśliśmy aplikację do środowiska Linux, przestało działać. Więc później musiałem go zmienić na

"./storage" + fileName + ".CSV”

i zaczął pracować normalnie.

1

Co pracował dla mnie było zmienić proxy_temp_path do folderu z uprawnieniami do odczytu/zapisu (777)

location/{ 
    proxy_temp_path /data/tmp; 
} 
+0

Zmiana uprawnień na 777 jest niebezpieczna i nie powinieneś tego robić na żadnym serwerze otwartym na internet! – amit

1

dodając następującą linię do config nginx była jedyną rzeczą, która stała się błąd net::ERR_CONTENT_LENGTH_MISMATCH dla mnie:

proxy_buffering off; 
0

dla nas tu Przekonaliśmy się, że nasz niewielki root serwera (np. /) był pełny.

Miał góry dzienników i plików od użytkowników w/home. Przeniesienie tego całego okrucha na inny zamontowany dysk rozwiązało sprawy.

Po prostu chciałem udostępnić, ponieważ może to być inna przyczyna problemu.