ബാക്കി പേജ് ലോഡ് ആകുമ്പോൾ ഒരു ചിത്രം മാത്രം പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
മൂന്ന് വ്യവസ്ഥകൾ നെറ്റ്‌വർക്ക് തകരാറിനെ തടഞ്ഞ അഭ്യർത്ഥനയിൽ നിന്നും റെൻഡറിംഗ് പിശകിൽ നിന്നും വേർതിരിക്കുന്നു. വഴി മാറ്റുന്നതിന് മുമ്പ് ബ്രൗസർ തിരഞ്ഞെടുത്ത 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 പേജിന് അഭ്യർത്ഥന പരാജയത്തിന് പകരം തടയപ്പെടുന്നു, കൺസോൾ കാരണം രേഖപ്പെടുത്തുന്നു. ഉള്ളടക്ക സുരക്ഷാ നയവും അതേ രൂപം നൽകുന്നു, തടഞ്ഞ നിർദ്ദേശം സന്ദേശത്തിൽ പേരിടുന്നു. ഹെഡർ നീക്കം ചെയ്യുന്ന റഫറർ നയം ഹോട്ട്ലിങ്ക് സംരക്ഷിത ഹോസ്റ്റിനെ ചിത്രത്തിന് പകരം പ്ലേസ്ഹോൾഡർ തിരികെ നൽകാൻ നിർബന്ധിച്ചേക്കാം.
നെറ്റ്‌വർക്ക് വഴി സ്പർശിക്കുന്നതിന് മുമ്പ് രേഖപ്പെടുത്തിയ കാരണം വായിക്കുക, കാരണം വഴി മാറുമ്പോൾ ഈ തടയലുകൾ മെച്ചപ്പെടുന്നില്ല. ക്രോസ്-ഒറിജിൻ അനുമതികൾ ചേർക്കുന്നതും പരിഹാരമല്ല: മറ്റൊരു ഹോസ്റ്റിൽ നിന്നുള്ള ചിത്രം കാണിക്കുന്നതും അതിന്റെ പിക്സലുകൾ canvas-ൽ വായിക്കുന്നതും വ്യത്യസ്ത പ്രവർത്തനങ്ങളാണ്, രണ്ടാമത്തേതിന് മാത്രമാണ് ആളുകൾ ഒട്ടിക്കുന്ന ഹെഡറുകൾ വേണ്ടത്.
നിങ്ങൾ നിർവഹിക്കുന്ന സൈറ്റിന്, ഉറവിടത്തിന്റെ URL, പ്രതികരണം അല്ലെങ്കിൽ നയം അതിന്റെ ഉടമയിൽ ശരിയാക്കി അംഗീകാര, റഫറർ ആവശ്യകതകൾ അതേപടി നിലനിർത്തുക. നിങ്ങൾ നിയന്ത്രിക്കാത്ത സൈറ്റിന്, സ്വകാര്യമോ കാലഹരണപ്പെടുന്നതോ ആയ ഉറവിട ലിങ്കുകൾ വീണ്ടും പ്രസിദ്ധീകരിക്കുന്നതിന് പകരം പേജും അഭ്യർത്ഥന തെളിവുകളും അതിന്റെ പിന്തുണാ ചാനലിലേക്ക് അയയ്ക്കുക.
തെളിവുകൾ മാറ്റാതെ വഴികൾ താരതമ്യം ചെയ്യുക
പ്രവേശന വഴി ശരിക്കും പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ബാക്കിയെല്ലാം സ്ഥിരമായി നിർത്തുക: അതേ പേജ്, അതേ അക്കൗണ്ട്, അതേ തിരഞ്ഞെടുത്ത ചിത്രം, അനുവദിച്ച ഒരു വഴി മാറ്റിയത്. റെൻഡർ ചെയ്ത ഫലത്തിന് പകരം അഭ്യർത്ഥന എൻട്രികൾ അരികിൽ അരികിൽ താരതമ്യം ചെയ്യുക, കാരണം റെൻഡർ ചെയ്ത ഫലം ചിത്രം കാണിച്ചോ എന്ന് പറയുന്നു, എന്തുകൊണ്ടെന്നല്ല.
പുതിയ വഴിയിൽ ലോഡ് ആകുന്ന ചിത്രം ആ വഴി അംഗീകൃതമാണെന്ന് തെളിയിക്കുന്നില്ല, പൊട്ടിയതായി തുടരുന്ന ചിത്രം ടണലാണ് കുറ്റക്കാരനെന്ന് തെളിയിക്കുന്നില്ല. ചിത്രം നീക്കം ചെയ്തിട്ടുണ്ടെങ്കിൽ അല്ലെങ്കിൽ പ്രവേശനം ബോധപൂർവം പരിമിതപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ, സർട്ടിഫിക്കറ്റ് പരിശോധനകൾ ഓഫ് ചെയ്യുന്നതിനോ മറ്റൊരാളുടെ സംരക്ഷിത വസ്തു പകർത്തുന്നതിനോ പകരം പിന്തുണയുള്ള ബദൽ ഉപയോഗിക്കുക.
ജോലിയുടെ ക്രമം: തിരഞ്ഞെടുത്ത URL തിരിച്ചറിയുക, അതിന്റെ സ്റ്റാറ്റസും തരവും വായിക്കുക, രേഖപ്പെടുത്തിയ തടയൽ കാരണമുണ്ടോ എന്ന് പരിശോധിക്കുക, തുടർന്ന് ഒരു സമയം ഒരു വഴി മാറ്റം താരതമ്യം ചെയ്യുക.