WN - Korrupta zip-filer

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Korrupta zip-filer (https://www.wn.se/forum/showthread.php?t=6160)

Hej,

Ursäkta att jag inte har skrivit på länge, men det har varit så stressigt ett tag nu. Blir bättre till våren får man hoppas.

En orsak till stressen är att jag fortfarande har problem med det jag skrev om i denna tråd...
http://www.webmasternetwork.se/index.php?a...t=4919&hl=&s=wn
...dvs. att zip-filer som laddas ned från min server ofta inte går att öppna för att de har blivit "corrupta". Kunderna blir inte glada, kan jag ju säga. Jag har bytt server och externt nätverk och satt upp allt från scratch, men det hjälpte inte.

Efter omfattande efterforskningar vet jag följande:

- Zip-filerna i sig är OK, men vid ca 70% av nedladdningarna blir de skadade.

- Felet verkar i stort sett bara uppstå med krypterade länkar, dvs. när PHP skickar en länk av denna typ:
http://www.mydomain.com/portal/auth.php?cl...76HRk6&file=286

- En vanlig länk av denna typ...
http://www.mydomain.com/fil.zip
...ger sällan detta fel. Faktiskt så sällan att det kanske kan ha helt andra orsaker, som kundens internetförbindelse etc.. Men jag kan ju inte ha filerna liggande helt öppet på det viset.

- Error 416 (Requested Range Not Satisfiable) som jag tog upp i den andra tråden har inget med detta att göra.

- Det är inte hårdvarufel, eller problem med det externa nätverket.

- PHP-scriptet som genererar länkarna är OK, för vi har testat det på ett annat ställe (hos samma webbhotell) och där uppkommer inte detta fel.

Slutsats: Det måste alltså vara något med mjukvaran i själva servern. Troligen PHP (version 4.0.6) eller Apache (har Linux som OS). Jag är lite inne på att det kan ha något med redirect att göra, eftersom felet nästan bara uppstår med de länkarna.

Det här är extremt frustrerande och jag hoppas verkligen att nån har en idé om var jag ska fortsätta leta eller vad jag ska prova. Som det är nu kan jag inte åka nånstans mer än över dagen, för jag måste ständigt hjälpa kunder som har problem med sina filer.

~ Helena

En sak som jag glömde nämna:

Precis alla filer som blir skadade får samma typ av fel; alla '00h' bytes blir utbytta mot '5C30h'! Filen blir alltså några bytes större än den ska vara.

~ Helena

Det verkar som att jag äntligen har lyckats lösa detta otroligt frustrerande problem! Tänkte jag skulle skriva här vad vi gjorde, ifall nån får samma problem senare.

Efter mycket om och men lyckades vi lista ut att felet uppstod när PHP skickar ut filerna. Det verkar som att när servern var högt belastad blandade den ibland ihop zip- och gif-filer. Något med MIME-typer, alltså.

Lösning:

Vi la in följande i php.ini:

Kod:

zend.zel_compatibility_mode = Off;

zlib.output_compression = Off;

max_input_time = 60;

default_mimetype = "text/html";

Redan det gav en enorm förbättring, men vid ett tillfälle (kan ha berott på något annat) fick vi trasiga filer igen, så vi bytte ut...

Kod:

$fp=fopen("$filevault/$filename","r");

print fread($fp,filesize("$filevault/$filename"));

fclose($fp);

...i själva PHP-scriptet till:

Kod:

$fp=fopen("$filevault/$filename","rb");

fpassthru($fp);

fclose($fp);

Sedan dess har jag inte lyckats åstadkomma en enda korrupt nedladdning. Det verkar även funka bra för kunderna. Yay! :) Det här är överlägset det jobbigaste problemet jag har haft sen jag startade hemsidan 1997, så det är minst sagt skönt att det är löst.

Måste bara tillägga att det är så jädra skönt när man löser ett problem som man har blivit irriterad av en längre tid!

Har verkligen full förståelse för din frustration :D

Tack, ja visst är det? Ibland har jag haft lust att ge upp, eller att slå sönder nåt.., men sen vaknar envisheten igen och det är bara att fortsätta att prova det ena efter det andra.

Om ett par dar, när jag kan känna mig 100% säker på att det verkligen är fixat, då blir det att gå ut och festa. :)

Jättekul att det löste sig tillslut! Och bra för nästa som får detta egendomliga problem att det nu finns en sida på nätet med en eventuell lösning.

Thomas

Citat:

Originally posted by Helena@Mar 8 2005, 12:11
Vi la in följande i php.ini:

Kod:

zend.zel_compatibility_mode = Off; zlib.output_compression = Off; max_input_time = 60; default_mimetype = "text/html";

Redan det gav en enorm förbättring, men vid ett tillfälle (kan ha berott på något annat) fick vi trasiga filer igen, så vi bytte ut...

Kod:

$fp=fopen("$filevault/$filename","r"); print fread($fp,filesize("$filevault/$filename")); fclose($fp);

...i själva PHP-scriptet till:

Kod:

$fp=fopen("$filevault/$filename","rb"); fpassthru($fp); fclose($fp);

Mycket bättre att skriva koden på det nya sättet. Men du kan göra det något snabbare och enklare med readfile().

Du behöver ju inte stänga av zlib.output_compression på hela servern bara för att du inte vill ha igång det i det där PHP-scriptet som krånglade. Använd ini_set() istället. Se sedan till att skicka rätt mime-typ med HTTP-huvudet "Content-type". Ex: Header("Content-type: application/zip"). Huvudet "Content-Length" kan ju vara bra att sätta också. Min apache 1.3 sätter också huvudet "Accept-Ranges: bytes" på zip-filer. Vet dock inte vad den gör.

Skönt att det löste sig, det är så underbart när man inte lyckas lösa problemen, det är som en sten faller från kroppen - när dom väl löser sig! :)

Citat:

Ursprungligen postat av Thomas

Jättekul att det löste sig tillslut Och bra för nästa som får detta egendomliga problem att det nu finns en sida på nätet med en eventuell lösning.
Thomas

Jo, det är ju lite mycket text och en del visade sig vara irelevant, men jag tänkte att det kan vara bra att den får ligga kvar ifall nån Googlar på detta ämne.

Det som har gjort det så svårt att komma fram till lösningen är att det har funnits två olika orsaker som har gett samma fel. På den första servern blev det interna nätverket skadat och gav slumpvis korrupta nedladdningar. När det sen fortsatte även på den nya servern hamnade vi på villospår (vi tog för givet att felorsaken var samma på båda servrarna) och det var därför det tog sån tid.

Citat:

Ursprungligen postat av kullervo

Mycket bättre att skriva koden på det nya sättet. Men du kan göra det något snabbare och enklare med readfile().
Du behöver ju inte stänga av zlib.output_compression på hela servern bara för att du inte vill ha igång det i det där PHP-scriptet som krånglade. Använd ini_set() istället. Se sedan till att skicka rätt mime-typ med HTTP-huvudet Content-type. Ex: Header(Content-type: application/zip). Huvudet Content-Length kan ju vara bra att sätta också. Min apache 1.3 sätter också huvudet Accept-Ranges: bytes på zip-filer. Vet dock inte vad den gör.

Tack för tipset! Jag ska kolla upp det. Det låter vettigt.

~ Helena