ejemplos - Javascript-ERR_CONTENT_LENGTH_MISMATCH
jquery selector (5)
Estoy haciendo un sitio básico de juegos para jquery. Recibo un error: net::ERR_CONTENT_LENGTH_MISMATCH ocurre en la carga de la página y las imágenes de fondo no se cargan en la página.
La imagen en cuestión es de 300 kb y también está cambiando dinámicamente. Supongo que esto tiene algo que ver con el tamaño de los archivos, pero realmente no sé qué.
HTML utilizado originalmente:
<p style="margin:0px; padding:0px;">
<img id="background" src="/bg1.jpg" style=''width:100%;'' border="0" alt="Null">
</p>
javascript / jquery usado para cambiar el fondo:
var changebg = function() {
if (myscore % 20 == 0) {
level++;
document.getElementById("level").innerHTML = "Level: " + level;
$("#level").fadeIn(1500, function(){$("#level").hide()})
backgroundindex++;
if (backgroundindex > 6) {
backgroundindex == Math.floor((Math.random()*6)+1)};
document.getElementById("background").src="/bg"+backgroundindex+".jpg";
};
}
Recibo un error: net :: ERR_CONTENT_LENGTH_MISMATCH
Eche un vistazo a los registros de su servidor para determinar cuál es el problema real.
Para mí, el problema estaba en algún lugar entre nginx y permisos de archivos:
-
tail -f /usr/local/var/log/nginx/error.logo ejecutarnginx -tpara determinar su ubicación de conf, donde podría especificar una ruta de registro personalizada. - actualice el activo en su navegador, por ejemplo,
http://localhost:3000/assets/jquery/jquery.js
Puede ver algo como esto en los registros:
"/ usr / local / var / run / nginx / proxy_temp / 9/04/0000000049" failed (13: Permiso denegado) mientras se lee en sentido ascendente para el archivo xyz
Heres cómo lo arreglé:
sudo nginx -s stop
sudo rm -rf /usr/local/var/run/nginx/*
sudo nginx
Resumen
Aquí hay una explicación más detallada de lo que sucedió en mi caso. La respuesta seleccionada aquí me ayudó a resolver mi problema y esta es básicamente una versión más detallada de la respuesta seleccionada sobre cómo y por qué.
Explicando los permisos de Nginx
Puede ejecutar nginx como usuario nobody y esa es la práctica común en la mayoría de las configuraciones de muestra. Encontrarás esta línea en la parte superior de tu configuración:
user nobody;
Sin embargo, se sugiere que los contenidos estáticos de las aplicaciones web, como css, js y archivos de imagen, permitan el acceso a nginx y lo transfieran a través de su aplicación web.
envase. Esta es la parte de tu configuración donde dice:
location ^~ /static {
alias /path/to/your/static/folder/;
autoindex on;
expires max;
}
Esta es la carpeta a la que nginx necesita tener acceso.
Por otro lado, hay una carpeta dedicada nginx donde en el caso de la respuesta anterior estaba en:
/usr/local/var/run/nginx/
En mi caso (CentOS) fue en:
/var/lib/nginx/
¿Cómo pueden las cosas ir mal?
En cualquiera de estos casos puedes romper nginx :
1- Nginx se ejecuta como nadie, pero no tiene el acceso correcto a su carpeta estática.
2- Nginx se ejecuta como nobody pero luego se ejecuta como root para obtener acceso a su carpeta estática.
Solución
La mejor solución en mi caso fue cambiar el permiso de la carpeta dedicada de nginx para que coincida con mi carpeta estática. Y luego ejecute nginx con como usuario con el acceso correcto a ambos.
Aquí hay otra forma de resolver este problema: http://derekneely.com/2009/06/nginx-failed-13-permission-denied-while-reading-upstream/
NOTA: desde un punto de vista de seguridad, no estoy de acuerdo con el enlace donde el autor sugiere dar 777 permisos a las carpetas. Proporcione el nivel mínimo necesario para realizar el trabajo (en este caso, 700 debería estar bien, incluso podría bajar, aunque aún no lo intenté).
En mi caso, estaba usando nodemon server.js en una aplicación next.js (del lado del servidor). Al volver al node server.js , el error desapareció.
Tuve el mismo error al construir una aplicación de rieles. Reemplacé una imagen con una imagen diferente y no cambié el nombre del archivo, que arrojó el error anterior. Simplemente cambiar el nombre del archivo hizo que el problema desapareciera.