Ik ben een eenvoudige jQuery-speelplaatssite aan het maken. Ik krijg Error: net::ERR_CONTENT_LENGTH_MISMATCHgebeurt bij het laden van de pagina en de achtergrondafbeeldingen worden niet op de pagina geladen.
De afbeelding in kwestie is 300 kb en verandert ook dynamisch. Ik neem aan dat dit iets te maken heeft met bestandsgroottes, maar ik weet niet precies wat.
HTML oorspronkelijk gebruikt:
<p style="margin:0px; padding:0px;">
<img id="background" src="/bg1.jpg" style='width:100%;' border="0" alt="Null">
</p>
javascript / jquery gebruikt om de achtergrond te wijzigen:
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";
};
}
Antwoord 1, autoriteit 100%
Ik krijg Error: net::ERR_CONTENT_LENGTH_MISMATCH
Bekijk uw serverlogboeken om te bepalen wat het echte probleem is.
Voor mij lag het probleem ergens tussen nginx en bestandsrechten:
tail -f /usr/local/var/log/nginx/error.logof voernginx -tuit om uw conf-locatie te bepalen, waar u een aangepast logpad.- vernieuw het item in uw browser, bijvoorbeeld
http://localhost:3000/assets/jquery/jquery.js
Misschien ziet u iets als dit in de logboeken:
“/usr/local/var/run/nginx/proxy_temp/9/04/0000000049” mislukt (13:
Toestemming geweigerd) tijdens het lezen van upstream voor bestand xyz
Zo heb ik het opgelost:
sudo nginx -s stop
sudo rm -rf /usr/local/var/run/nginx/*
sudo nginx
Antwoord 2, autoriteit 12%
Samenvatting
Hier is een meer gedetailleerde uitleg van wat er in mijn geval is gebeurd. Het geselecteerde antwoord hier heeft me geholpen mijn probleem op te lossen en dit is eigenlijk een meer gedetailleerde versie van het geselecteerde antwoord over het hoe en waarom!
Nginx-machtigingen uitleggen
Je kunt nginxuitvoeren als een nobody-gebruiker en dat is de gangbare praktijk in de meeste voorbeeldconfiguraties. U vindt deze regel bovenaan uw configuratie:
user nobody;
Er wordt echter gesuggereerd dat voor uw web-apps statische inhoud, zoals css-, js- en afbeeldingsbestanden nginx-toegang toestaan en verzilveren door uw web-app te omzeilen
container. Dit is het deel van je configuratie waar het staat:
location ^~ /static {
alias /path/to/your/static/folder/;
autoindex on;
expires max;
}
Dit is de map waar nginxtoegang toe moet hebben.
Aan de andere kant is er een nginxspeciale map waar in het geval van het bovenstaande antwoord zich bevond in:
/usr/local/var/run/nginx/
In mijn geval (CentOS) was het in:
/var/lib/nginx/
Hoe kan het mis gaan?
In beide gevallen kun je nginxbreken:
1- Nginx draait als niemand, maar heeft niet de juiste toegang tot je statische map.
2- Nginx draait als niemand maar dan als root om toegang te krijgen tot je statische map.
Oplossing
De beste oplossing in mijn geval was om de toestemming van de speciale nginx-map te wijzigen zodat deze overeenkomt met mijn statische map. En voer vervolgens nginx uit met als gebruiker met de juiste toegang tot beide.
Antwoord 3, autoriteit 3%
Als je nginx + proxyserver gebruikt, probeer dan:
proxy_buffering off;
Meer info: https://docs.nginx .com/nginx/admin-guide/web-server/reverse-proxy/
Antwoord 4, autoriteit 2%
In mijn geval gebruikte ik nodemon server.jsin een next.js(server-side rendered) app. Door terug te schakelen naar node server.js, is de fout verdwenen.
Antwoord 5, autoriteit 2%
Mijn team zag dit in een enkel javascript-bestand dat we aan het serveren waren. Elk ander bestand werkte prima. Oorspronkelijk zagen we net::ERR_HTTP2_PROTOCOL_ERROR. We zijn overgestapt van http2terug naar http1.1en vervolgens net::ERR_INCOMPLETE_CHUNKED_ENCODINGof ERR_CONTENT_LENGTH_MISMATCH. Uiteindelijk ontdekten we dat er een bedrijfsfilter (Trustwave) was die ten onrechte een “infoleak” detecteerde (we vermoeden dat het iets in ons bestand/bestandsnaam heeft gedetecteerd dat lijkt op een burgerservicenummer). Door bedrijven dit filter te laten aanpassen, zijn onze problemen opgelost.
Antwoord 6
Ik had dezelfde fout bij het bouwen van een rails-app. Ik heb een afbeelding vervangen door een andere afbeelding en heb de bestandsnaam niet gewijzigd, waardoor de bovenstaande fout ontstond. Door simpelweg de bestandsnaam te wijzigen, verdween het probleem.
Antwoord 7
Een ander geval waarin deze fout bij mij opdook: toen ik probeerde een bestand te downloaden van een knooppuntserver met Angular 7, moest ik in plaats daarvan omleiden met window.location.href = <node_server_url>van de gebruikelijke httpClient.get<any>(<node_server_url>).
Antwoord 8
Hier is een andere manier om dit probleem op te lossen:
http://derekneely.com/2009/ 06/nginx-failed-13-permission-denied-while-reading-upstream/
OPMERKING: vanuit veiligheidsoogpunt ben ik het niet eens met de link waar de auteur voorstelt om 777 permissies te geven aan de mappen. Geef het minimumniveau dat nodig is om de klus te klaren (in dit geval zou 700 goed moeten zijn, je zou zelfs kunnen verlagen, hoewel ik dat nog niet heb geprobeerd).