Un CDN a eliminat GZIP și a produs mojibake în numele fișierelor și aplicarea antetului setului de caractere care a remediat descărcările corupte

Atunci când site-urile web la scară largă se bazează pe infrastructura globală pentru a furniza conținut în mod fiabil și eficient, rețelele de difuzare a conținutului (CDN) joacă un rol esențial. Dincolo de simpla stocare în cache a activelor mai aproape de utilizatori, CDN-urile ajută și la comprimarea fișierelor, la accelerarea descărcărilor și la îmbunătățirea experienței utilizatorului. Cu toate acestea, în anumite condiții, pot introduce din neatenție noi probleme. Un astfel de incident a implicat comprimarea GZIP și seturi de caractere manipulate incorect, ducând la descărcări corupte și mojibake (text deformat) în numele fișierelor - un fenomen care a provocat dezvoltatorii și operatorii deopotrivă.

TL;DR: O configurare greșită într-un serviciu CDN a dus la eliminarea antetelor de compresie GZIP din fișierele descărcabile și la înțelegerea greșită a codificării de caractere a numelor fișierelor. Acest lucru a dus la descărcări cu nume de fișiere corupte sau ilizibile (mojibake). Problema a fost rezolvată în cele din urmă prin forțarea setului charset corect în antetele HTTP, asigurându-se că atât codarea numelui de fișier, cât și conținutul au fost interpretate corect de către browser. Acest caz evidențiază importanța coerenței în codificarea conținutului, în special atunci când se utilizează CDN-uri care pot modifica anteturile HTTP.

Ce a mers greșit: gestionarea greșită a compresiei

În centrul problemei a fost gestionarea inadecvată de către CDN a antetului Content-Encoding . Serverul de origine a comprimat corect fișierele folosind GZIP și le-a etichetat cu următorul antet:

 Content-Encoding: gzip

Cu toate acestea, CDN-ul – menit să optimizeze livrarea – a decis să elimine acest antet și să difuzeze conținutul ca și cum ar fi necomprimat. Acest lucru a funcționat bine pentru browserele care se așteptau la fișiere brute precum CSS sau JavaScript, dar când utilizatorii au încercat să descarce fișiere precum CSV-uri, PDF-uri sau arhive ZIP, au primit descărcări corupte. Dezarhivând astfel de fișiere fie a eșuat complet, fie a produs date care păreau de necitit sau incomplete.

Dincolo de corupția binară, a apărut o problemă și mai misterioasă: unele nume de fișiere au apărut distorsionate cu simboluri ciudate, în special atunci când au fost descărcate folosind browsere precum Chrome sau Firefox. Acest fenomen este cunoscut sub numele de mojibake și apare atunci când un program interpretează o secvență de octeți folosind o codificare neintenționată a caracterelor.

Confuzie în codificarea caracterelor

Mojibake în numele fișierelor descărcate apare de obicei atunci când:

• Numele fișierului conține caractere non-ASCII (cum ar fi litere accentuate sau scripturi asiatice)
• Browserul nu știe ce set de caractere să folosească
• Antetele Content-Disposition sau Content-Type nu au declarații adecvate de set de caractere

Browserul, ghicind greșit, încearcă să interpreteze numele fișierului utilizând o codificare implicită sau de rezervă, cum ar fi ISO-8859-1, ceea ce duce la farfurie în locul caracterelor lizibile. Acest lucru afectează de obicei utilizatorii care descarcă fișiere cu nume de fișiere în limbi precum japoneză, rusă sau germană, unde caracterele speciale sunt predominante.

Inițial, dezvoltatorii au setat anteturi adecvate de pe serverul de aplicații, cum ar fi:

 Content-Type: application/octet-stream; charset=utf-8 Content-Disposition: attachment; filename="resume.pdf"

Dar, încă o dată, CDN-ul a modificat aceste anteturi prin eliminarea sau înlocuirea lor, ducând la descărcări fără indiciu de set de caractere. Acest lucru a declanșat un comportament incorect al browserului, deoarece numele fișierului a fost interpretat cu o codificare greșită.

Remedierea: aplicarea setului de caractere în anteturile HTTP

După multă depanare și urmărire a jurnalelor, dezvoltatorii au confirmat că:

• Fișierele nu au fost corupte la serverul de origine.
• Descărcările au avut succes prin curl și acces direct IP.
• Problema a apărut numai când a fost difuzată prin CDN.

Prin urmare, soluția potrivită a fost dublă:

1. Forțați CDN-ul să păstreze anteturile Content-Encoding , astfel încât browserele să primească și să decomprimați corect conținutul GZIP.
2. Setați charset explicit atât pe Content-Type , cât și în anteturile Content-Disposition pentru a garanta decodarea corespunzătoare a numelor de fișiere internaționale.

Configurația finală a antetului de lucru arăta astfel:

 Content-Type: application/octet-stream; charset=utf-8 Content-Disposition: attachment; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf Content-Encoding: gzip

Utilizarea numelui de filename* cu sintaxa de codificare URL UTF-8'' asigură că browserele interpretează numele fișierului conform RFC 5987. Acest lucru este acceptat în special în browserele moderne, aliniind comportamentul pe mai multe platforme.

De ce CDN-urile modifică anteturile

CDN-urile urmăresc adesea să optimizeze performanța, să reducă redundanța și să standardizeze răspunsurile. În acest scop, ei pot:

• Eliminați sau înlocuiți directivele de compresie
• Normalizați tipurile de conținut
• Eliminați anteturile care nu trec filtre de securitate sau reguli de stocare în cache

Cu toate acestea, aceste optimizări se pot produce înapoi atunci când anulează parametrii setați cu atenție, esențiali pentru redarea conținutului sau descărcarea fișierelor. În acest incident, eșecul CDN-ului de a păstra Content-Encoding și charset s-a dovedit a fi dăunător atât utilizării, cât și internaționalizării.

Lecții învățate

Această problemă servește ca un memento valoros pentru dezvoltatorii care lucrează în medii distribuite:

• Testați întotdeauna livrarea de conținut de la capăt la capăt. Fișierele care funcționează pe serverul dvs. se pot comporta diferit în spatele unui CDN.
• Fii explicit în anteturi. Nu presupuneți nimic despre comportamentele implicite - declarați întotdeauna tipul de conținut, codificarea și setul de caractere.
• Controlați comportamentul CDN prin configurare. Majoritatea CDN-urilor permit înlocuiri sau reguli pentru păstrarea antetelor. Folosiți-le.
• Verificați comportamentul de descărcare în mai multe browsere și localități. Bug-urile de internaționalizare apar adesea doar în aceste condiții.

FAQ

Ce este mojibake?

Mojibake este un termen folosit pentru a descrie afișarea deformată sau incorectă a caracterelor cauzată de nepotrivirile de codificare a caracterelor. Apare adesea atunci când software-ul interpretează greșit codificarea caracterelor folosită pentru stocarea sau trimiterea datelor text.

Cum afectează gzip descărcările de fișiere?

Când este utilizat corect, GZIP comprimă fișierele pentru a reduce timpul de descărcare. Cu toate acestea, dacă un fișier este servit ca comprimat GZIP fără a avea antetul corespunzător Content-Encoding: gzip , este posibil ca browserele să nu îl decomprima, ceea ce duce la descărcări corupte sau ilizibile.

De ce ar fi un CDN strip antete precum Content-Encoding sau charset?

CDN-urile prioritizează performanța și securitatea. Procedând astfel, adesea normalizează anteturile sau aplică politici care elimină informațiile potențial nesigure sau inutile. Acest lucru poate elimina din neatenție metadatele critice necesare pentru gestionarea corectă a conținutului.

Care este modalitatea corectă de a specifica nume de fișiere non-ASCII pentru descărcări?

Utilizați antetul Content-Disposition cu atributul filename* folosind codificarea UTF-8 și formatul cu escape procentual, așa cum este specificat în RFC 5987. De exemplu:

Content-Disposition: attachment; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf

Cum pot dezvoltatorii să evite astfel de probleme în viitor?

Aceștia ar trebui să efectueze teste prin stratul CDN, să specifice antetele în mod explicit și să utilizeze configurațiile CDN care păstrează sau trec prin toate metadatele necesare. În plus, păstrarea documentației despre modul în care CDN-urile modifică traficul este esențială în timpul fazelor de depanare.