એક છબી કેમ નિષ્ફળ જાય છે જ્યારે પૃષ્ઠનો બાકીનો ભાગ લોડ થાય છે
ત્રણ શરતો નેટવર્ક ખામીને અવરોધિત વિનંતી અને રેન્ડરિંગ ભૂલથી અલગ પાડે છે. માર્ગ બદલતા પહેલાં બ્રાઉઝરે પસંદ કરેલું URL શોધો.
પૃષ્ઠ લોડ થાય છે, લખાણ રેન્ડર થાય છે, અને એક છબી તૂટેલા ચિહ્ન તરીકે રહે છે. પ્રથમ પ્રતિક્રિયા ટ્યુનેલને દોષ આપવાની હોય છે, કારણ કે ટ્યુનેલ જ તે વસ્તુ છે જે બદલાઈ છે. તે પહેલાં શોધો કે બ્રાઉઝરે તે છબી માટે ખરેખર કયું URL માંગ્યું હતું, કારણ કે પૃષ્ઠનું URL અને છબીનું URL બે અલગ પુરાવા છે. મોટાભાગની ખોવાયેલી છબીની ફરિયાદો એવા હોસ્ટ પર પહોંચે છે જેને ક્યારેય કાર્યક્ષમ વિનંતી મળી નથી, અને તે જવાબ માટે નેટવર્ક પેનલ પર એક નજર પૂરતી છે.
ક્યાં જોવું તે ત્રણ શરતો નક્કી કરે છે
પ્રથમ શરત એ છે કે છબી પૃષ્ઠ જેવા જ હોસ્ટ પરથી આવે છે કે નહીં. અલગ છબી હોસ્ટને પોતાનું નામ-નિરાકરણ, પોતાનું જોડાણ અને પોતાની TLS ઓળખ જોઈએ, તેથી લોડ થતું પૃષ્ઠ તેના વિશે કંઈ કહેતું નથી.
બીજી એ છે કે બ્રાઉઝરે વિનંતી મોકલતા પહેલાં તેને અવરોધી હતી કે નહીં. મિશ્ર સામગ્રી, સામગ્રી સુરક્ષા નીતિ અને રેફરર નિયમો સામાન્ય સર્વર પ્રતિભાવ વગર છબીને રોકી શકે છે, તેથી યાદીમાં કોઈ નિષ્ફળ વિનંતી દેખાતી નથી.
ત્રીજી એ છે કે ડિલિવરી સફળ થઈ અને રેન્ડરિંગ નિષ્ફળ ગયું, એવો કિસ્સો જેમાં બાઇટ્સ આવે છે અને છબી તોય દેખાતી નથી. આ ત્રણ શરતોના ત્રણ અલગ માલિકો છે, અને ફક્ત પ્રથમ જ નેટવર્કનો પ્રશ્ન છે.
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
બ્રાઉઝરે ખરેખર પસંદ કરેલું સંસાધન શોધો
પૃષ્ઠના સ્રોતમાં તમે જે URL જુઓ છો તે ઘણી વાર માંગવામાં આવેલું URL હોતું નથી. સ્રોત-સમૂહો, picture તત્વો અને CSS પૃષ્ઠભૂમિ બ્રાઉઝરને વ્યૂપોર્ટની પહોળાઈ, પિક્સેલ ઘનતા કે ફોર્મેટ સમર્થનના આધારે બીજું સંસાધન પસંદ કરવા દે છે. આળસુ લોડ થતી છબી પૃષ્ઠ ચોક્કસ સ્થિતિમાં ન પહોંચે ત્યાં સુધી બિલકુલ માંગવામાં ન પણ આવે.
તત્વ અને વિનંતી સાથે મળીને તપાસો, અને સમસ્યા જણાવતી વખતે વિનંતી સાથે ઇનિશિયેટર રાખો. MDNનું છબી-તત્વ સંદર્ભ સ્રોત પસંદગી, લોડિંગ વર્તન અને રેફરર નિયંત્રણો એક જ જગ્યાએ આવરી લે છે, જે નિષ્ફળ URL કઈ વિશેષતાએ પસંદ કર્યું તે જણાવવા પૂરતું છે.
હોસ્ટનું નામ, સ્થિતિ, કોઈપણ રીડાયરેક્ટ શૃંખલા અને પ્રતિભાવનો સામગ્રી પ્રકાર નોંધો. સાઇન-ઇન પૃષ્ઠ પાછું આપતો 200 પ્રતિભાવ વપરાયોગ્ય છબી નથી, અને HTML ભૂલ પૃષ્ઠ પરનું રીડાયરેક્ટ તૂટેલી ફાઇલ જેવું જ દેખાય છે, જ્યાં સુધી તમે પ્રકાર વાંચો નહીં.
નેટવર્ક પહેલાં સ્થિતિ વાંચો
સમયસમાપ્તિ, નકારાયેલી વિનંતી અને ડીકોડિંગ ભૂલને અલગ આગળના પગલાં જોઈએ, અને સ્થિતિ કોડ જ તેમને અલગ પાડે છે. સમયસમાપ્તિ નામ-નિરાકરણ, માર્ગ કે જવાબ ન આપતા હોસ્ટ તરફ ઇશારો કરે છે. નકારાયેલી વિનંતી નીતિ કે અધિકૃતિ સ્તર તરફ ઇશારો કરે છે. ડીકોડિંગ ભૂલ બાઇટ્સ કે ફોર્મેટ તરફ ઇશારો કરે છે.
જો વિનંતી બિલકુલ ન દેખાય, તો નેટવર્ક જોવાનું બંધ કરો અને માર્કઅપ જુઓ. સૌથી સામાન્ય કારણ એ છે કે સ્રોત-સમૂહમાંની એવી નોંધ જે બ્રાઉઝરે પસંદ કરી હતી અને જે હવે સર્વર પર નથી, અને તેના પછી એવું તત્વ જેને કોઈ સ્ક્રિપ્ટે ક્યારેય દૃશ્યમાન બનાવ્યું નહીં.
ફક્ત આ ભેદ જ આ પ્રકારની ફરિયાદોમાં મોટાભાગનો વ્યર્થ પ્રયાસ અટકાવે છે.
જ્યારે બ્રાઉઝર તેને અવરોધે છે, ત્યારે વાંચવા માટે કોઈ પ્રતિભાવ હોતો નથી
મિશ્ર સામગ્રી એ ક્લાસિક કિસ્સો છે: સાદા HTTP પર છબી માંગતું HTTPS પૃષ્ઠ વિનંતીને નિષ્ફળને બદલે અવરોધિત મેળવે છે, અને કન્સોલ કારણ નોંધે છે. સામગ્રી સુરક્ષા નીતિ પણ એ જ આકાર આપે છે, સંદેશમાં અવરોધિત નિર્દેશનું નામ હોય છે. હેડર દૂર કરતી રેફરર નીતિ પણ હોટલિંક-સુરક્ષિત હોસ્ટને છબીને બદલે પ્લેસહોલ્ડર પાછું આપવા મજબૂર કરી શકે છે.
નેટવર્ક માર્ગને સ્પર્શતા પહેલાં નોંધાયેલું કારણ વાંચો, કારણ કે માર્ગ બદલાવાથી આ અવરોધો સુધરતા નથી. ક્રોસ-ઓરિજિન પરવાનગીઓ ઉમેરવી પણ ઉકેલ નથી: બીજા હોસ્ટની છબી દર્શાવવી અને કેનવાસમાં તેના પિક્સેલ વાંચવા એ અલગ ક્રિયાઓ છે, અને ફક્ત બીજીને જ લોકો ચોંટાડતા હેડરોની જરૂર પડે છે.
તમે સંચાલન કરો છો તેવી સાઇટ માટે, સંસાધનનું URL, પ્રતિભાવ કે નીતિ તેના માલિક પાસે સુધારો અને અધિકૃતિ તથા રેફરરની જરૂરિયાતો અકબંધ રાખો. તમે નિયંત્રણ ન કરો છો તેવી સાઇટ માટે, પૃષ્ઠ અને વિનંતીના પુરાવા તેની સહાય ચેનલને મોકલો, ખાનગી કે સમાપ્ત થતી સંસાધન કડીઓ ફરી પ્રકાશિત કરવાને બદલે.
પુરાવા બદલ્યા વગર માર્ગોની તુલના કરો
જો તમે ખરેખર ઍક્સેસ માર્ગ ચકાસવા માંગો, તો બાકીનું બધું સ્થિર રાખો: એ જ પૃષ્ઠ, એ જ ખાતું, એ જ પસંદ કરેલી છબી, એક માન્ય માર્ગ બદલાયેલો. રેન્ડર થયેલા પરિણામને બદલે વિનંતીની નોંધોની સાથોસાથ તુલના કરો, કારણ કે રેન્ડર થયેલું પરિણામ કહે છે કે છબી દેખાઈ કે નહીં, કેમ નહીં.
નવા માર્ગ પર લોડ થતી છબી સાબિત કરતી નથી કે તે માર્ગ અધિકૃત છે, અને તૂટેલી રહેતી છબી સાબિત કરતી નથી કે ટ્યુનેલ દોષિત છે. જો છબી દૂર કરવામાં આવી હોય અથવા ઍક્સેસ જાણી જોઈને મર્યાદિત હોય, તો પ્રમાણપત્ર તપાસ બંધ કરવાને બદલે કે બીજાની સુરક્ષિત સામગ્રીની નકલ કરવાને બદલે સમર્થિત વિકલ્પ વાપરો.
કામનો ક્રમ: પસંદ કરેલું URL ઓળખો, તેની સ્થિતિ અને પ્રકાર વાંચો, નોંધાયેલું અવરોધ કારણ છે કે નહીં તે તપાસો, પછી એક વખતે એક માર્ગ ફેરફારની તુલના કરો.