ERR_CONTENT_LENGTH_MISMATCH sur nginx et proxy sur google Chrome lors du chargement de gros fichiers

J'obtiens le message d'erreur suivant sur ma console chromée:

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

Cela n'arrive que lorsqu'un de requêtes simultanées sont tournés vers nginx par exemple, lorsque les navigateurs cache est vide et l'ensemble de l'application des charges. Chargement de la ressource ci-dessus comme un seul des demandes réussit.

Ici sont les en-têtes de cette demande, copié à partir de 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 la taille réelle du fichier:

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

Comme vous pouvez le voir Content-Length et de la taille réelle du fichier sont les mêmes, donc c'est bizarre

Et de configuration de nginx pour ce proxy:

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

Des idées?

Grâce

EDIT: trouvé plus d'info sur le journal des erreurs:

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

InformationsquelleAutor amit | 2014-09-23

35

Il semble que, sous la pression, nginx essayé de tirer angular.js de son cache et ne pouvait pas en raison de problèmes d'autorisation. Voici ce que résolu ce problème:
```
root@amac-2:/usr/local/var/run/nginx $ chown -R _www:admin proxy_temp
```
_www:admin peut être différent dans votre cas, en fonction de l'utilisateur qui possède le processus de nginx. Voir plus d'informations sur ServerFault:

https://serverfault.com/questions/534497/why-do-nginx-process-run-with-user-nobody
- Merci pour l'astuce, j'ai couru avec mon HomeBrew nginx après la mise à niveau à El Capitan
- Je suis content qu'il est toujours utile!
- Dans le cas où quelqu'un est toujours en cours d'exécution dans ce problème - vous pourriez avoir besoin de vérifier que l'utilisateur sous lequel nginx est en cours d'exécution. Dans mon cas, le dossier a été avec les autorisations appropriées et à la propriété, mais simplement de nginx était en cours d'exécution en vertu de l' nobody.nobody.
- Pourriez-vous poster la façon de résoudre ce problème dans Ubuntu 14.04 LTS ?
- la solution ci-dessus devrait fonctionner pour tout type de Linux, notamment Ubuntu bien sûr. Voir tftd s 'commentaire ici. Assurez-vous que tous les fichiers de l'appropriation du sens et il doit tous les travaux
- je ne comprends pas ce que c'est que _www:admin proxy_temp moyens
- C'était la clé pour obtenir de nginx et browserSync de travailler ensemble pour servir un projet AngularJS. Si vous avez installé nginx via homebrew et toutes les valeurs par défaut sur mac OSX, il devrait être sudo chown -R nobody:admin /usr/local/var/run/nginx/proxy_temp. A mon avis, ce problème a été créé par le passage à l'exécution de nginx via launchctl en tant que root au lieu de $UTILISATEUR.
- Merci, votre réponse a été utile pour moi quand j'ai eu une erreur similaire. Sur CentOs, le proxy_temp répertoire se trouve ici: /var/cache/nginx/proxy_temp/ j'ai juste supprimé le contenu de ce répertoire et mon problème a été résolu.
- Dans mon cas, je chown à mon compte d'utilisateur. Vous pouvez vérifier avec ps aux | grep nginx pour voir qui est en cours d'exécution de nginx.
InformationsquelleAutor amit
24

J'ai essayé tous les ci-dessus et encore ne pouvait pas le faire fonctionner. Même après avoir eu recours à chmod 777. La seule chose qui résolu pour moi a été de désactiver la mise en cache:

proxy_max_temp_file_size 0;

Bien que n'étant pas un fix et pas bon pour une utilisation en production, c'est OK pour moi depuis que je suis seulement en utilisant nginx dans le cadre d'un développement local de l'installation.

InformationsquelleAutor djskinner
13

Ajoutant la ligne suivante à la config nginx était la seule chose qui fixe le net::ERR_CONTENT_LENGTH_MISMATCH erreur pour moi:
```
proxy_buffering off;
```
- Devrait avoir essayé cette première... Semblait faire l'affaire 🙂
InformationsquelleAutor Miguel Mota
10

Pour moi, le remède était ces deux paramètres:

Dans le fichier:
/etc/nginx/nginx.conf

Ajouter:
```
proxy_max_temp_file_size 0;
proxy_buffering off;
```
Entre les lignes client_max_body_size 128M; et 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;
```
InformationsquelleAutor algenib
4
```
**ps aux | grep "nginx: worker process"**
```
après l'exécution de la commande ci-dessus, vous verrez l'utilisateur à travers lequel nginx est en cours d'exécution

par exemple.
```
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
```
maintenant, vous devez exécuter la commande ci-dessous pour donner l'autorisation
```
**chown -R www-data:www-data /var/lib/nginx/**
```
Espère que cela va fonctionner

InformationsquelleAutor Niyaz Ahamad
1

Ce qui a fonctionné pour moi a été de changer le proxy_temp_path à un dossier avec des autorisations de lecture/écriture (777)
```
location /{
    proxy_temp_path /data/tmp;
}
```
- Le changement des permissions à 777 est dangereux et vous ne devriez pas le faire dans n'importe quel serveur est ouvert à l'internet!
InformationsquelleAutor Chanrith
1

Pour nous, il s'est avéré que notre serveur est plutôt petite racine (ie. /) est complet.

Il avait des montagnes de journaux et les fichiers de l'utilisateur dans /home. Déplacement de tous les trucs que par un autre lecteur monté résolu choses.

Voulais juste partager ce qui peut être une autre cause du problème.
- Boom. Si vous travaillez dans le panneau de vérifier cela. Cheers Andy.
InformationsquelleAutor AndrewWhalan
0

Quand j'ai essayé de ladite solution, il n'a pas de résoudre le problème. J'ai aussi changé la permission d'écrire sur l'emplacement mais il ne fonctionne pas. Puis j'ai réalisé que j'ai fait quelque chose de mal là-dedans. Dans l'emplacement pour stocker le fichier, j'ai eu quelque chose comme

"/stockage" + nomfichier + ".csv"

. J'ai été le tester sur l'environnement Windows et il a été génial de travailler. Mais plus tard, quand nous avons déménagé l'application à l'environnement Linux il a cessé de travailler. Plus tard, j'ai dû changer de

"./de stockage" + nomfichier + ".csv"

et il a commencé à travailler normalement.

InformationsquelleAutor Sandip Subedi

Pour moi, la solution a été:

sudo chown -R nginx:nginx /var/cache/nginx/fastcgi_temp/

InformationsquelleAutor Bert

Vous devez vous connecter pour publier un commentaire.