സൗജന്യ HTTP സ്റ്റാറ്റസ് കോഡുകൾ റഫറൻസ്

Expect: 100-continue ഉള്ള അഭ്യർത്ഥനകൾക്കാണ് ഉപയോഗിക്കുന്നത്. ക്ലയന്റ് അയക്കുന്നതിന് മുമ്പ് ബോഡി സ്വീകരിക്കാൻ തയ്യാറാണെന്ന് സെർവർ അംഗീകരിക്കുന്നു. ആധുനിക വെബ് ആപ്പുകളിൽ അപൂർവ്വമായി മാത്രം കാണുന്നു.

WebSocket അപ്ഗ്രേഡുകൾക്കാണ് ഏറ്റവും സാധാരണയായി ഉപയോഗിക്കുന്നത് — ക്ലയന്റ് Upgrade: websocket ആവശ്യപ്പെടുന്നു, സെർവർ 101 ഉപയോഗിച്ച് മാറാൻ പ്രതികരിക്കുന്നു.

ദൈർഘ്യമേറിയ പ്രവർത്തനങ്ങളിൽ ക്ലയന്റ് ടൈംഔട്ടുകൾ തടയാൻ അയക്കുന്ന ഒരു WebDAV ഇടക്കാല പ്രതികരണം. നിർത്തലാക്കി — ആധുനിക സെർവറുകൾ ഇത് അയക്കരുത്.

അന്തിമ പ്രതികരണം തയ്യാറാക്കുന്നതിനിടെ സെർവറുകൾക്ക് Link ഹെഡറുകൾ (preload/preconnect) അയക്കാൻ അനുവദിക്കുന്നു, അതിനാൽ ബ്രൗസറുകൾക്ക് പ്രധാന ആസ്തികൾ നേരത്തെ ലഭ്യമാക്കാൻ തുടങ്ങാം.

സ്റ്റാൻഡേർഡ് വിജയ പ്രതികരണം. അർത്ഥം HTTP രീതിയെ ആശ്രയിച്ചിരിക്കുന്നു: GET → റിസോഴ്സ് തിരികെ നൽകി, POST/PUT → പ്രവർത്തനം പൂർത്തിയായി.

POST-ന് ശേഷം സാധാരണം. പുതിയ റിസോഴ്സിന്റെ URL ചൂണ്ടിക്കാണിക്കുന്ന ഒരു Location ഹെഡർ പ്രതികരണത്തിൽ ഉൾപ്പെടുത്തണം.

അസിൻക്രണസ് പ്രവർത്തനങ്ങൾക്ക് — സെർവർ ജോലി ക്യൂ ചെയ്യുന്നു. ക്ലയന്റ് ഒരു സ്റ്റാറ്റസ് എൻഡ്‌പോയിന്റ് പോൾ ചെയ്യണം അല്ലെങ്കിൽ പിന്നീട് പരിശോധിക്കണം.

അഭ്യർത്ഥന വിജയിച്ചു, പക്ഷേ ഒരു ഇന്റർമീഡിയറി (കാഷിംഗ് അല്ലെങ്കിൽ ട്രാൻസ്ഫോർമിംഗ് പ്രോക്സി പോലുള്ളത്) ഒറിജിൻ സെർവറിൽ നിന്നുള്ള പേലോഡ് മാറ്റി — ഉദാഹരണത്തിന്, ചിത്രങ്ങൾ വീണ്ടും കംപ്രസ് ചെയ്തുകൊണ്ട്. പ്രായോഗികമായി അപൂർവ്വം.

ബോഡി തിരികെ നൽകേണ്ടതില്ലാത്ത DELETE പ്രവർത്തനങ്ങൾക്കോ PUT അപ്ഡേറ്റുകൾക്കോ ആണ് പലപ്പോഴും ഉപയോഗിക്കുന്നത്. ക്ലയന്റ് നിലവിലെ പേജിൽ നിന്ന് മാറരുത്.

204 പോലെ, ബോഡി ഒന്നും തിരികെ നൽകുന്നില്ല — എന്നാൽ അഭ്യർത്ഥന സൃഷ്ടിച്ച ഫോമോ വ്യൂവോ പുനഃസജ്ജമാക്കാൻ ക്ലയന്റിനോട് അധികമായി പറയുന്നു (ഉദാ. അടുത്ത എൻട്രിക്കായി ഫോം ഫീൽഡുകൾ മായ്ക്കുക).

ഒരു Range അഭ്യർത്ഥനയോടുള്ള പ്രതികരണം. തടസ്സപ്പെട്ട ഡൗൺലോഡുകൾ പുനരാരംഭിക്കാനോ വലിയ ഫയലുകൾ സ്ട്രീം ചെയ്യാനോ വീഡിയോ പ്ലേയറുകളും ഡൗൺലോഡ് മാനേജറുകളും ഇത് ഉപയോഗിക്കുന്നു.

WebDAV: ഒരു XML ബോഡി പല ഉപ-പ്രവർത്തനങ്ങളുടെയും ഫലം സ്വതന്ത്രമായി റിപ്പോർട്ട് ചെയ്യുന്നു — ഉദാ. ചില ഇനങ്ങൾ വിജയിക്കുകയും മറ്റുള്ളവ പരാജയപ്പെടുകയും ചെയ്യുന്ന ഒരു ബാച്ച് നീക്കം.

WebDAV: ബൈൻഡിംഗുകൾ ലൂപ്പുകൾ സൃഷ്ടിക്കുമ്പോൾ ഒരേ ശേഖരത്തിലെ അംഗങ്ങൾ ആവർത്തിച്ച് ലിസ്റ്റ് ചെയ്യാതിരിക്കാൻ 207 Multi-Status പ്രതികരണങ്ങൾക്കുള്ളിൽ ഉപയോഗിക്കുന്നു.

ഡെൽറ്റ എൻകോഡിംഗ്: മുഴുവൻ റിസോഴ്‌സിനു പകരം സെർവർ മുൻ പതിപ്പുമായുള്ള വ്യത്യാസം (diff) തിരികെ നൽകുന്നു, ഇത് ബാൻഡ്‌വിഡ്ത്ത് ലാഭിക്കുന്നു. വളരെ അപൂർവമായി മാത്രം ഉപയോഗിക്കുന്നു.

സെർവർ ഒന്നിലധികം ഓപ്ഷനുകൾ (ഉദാ. വ്യത്യസ്ത ഫോർമാറ്റുകൾ അല്ലെങ്കിൽ ഭാഷകൾ) നൽകുന്നു, ക്ലയന്റ് ഒന്ന് തിരഞ്ഞെടുക്കണം. അപൂർവമായി ഉപയോഗിക്കുന്നു, കാരണം സ്വയമേവയുള്ള കണ്ടന്റ് നെഗോഷിയേഷൻ സാധാരണയായി ഇത് കൈകാര്യം ചെയ്യും.

സ്ഥിരമായ URL മാറ്റങ്ങൾക്ക് ഇത് ഉപയോഗിക്കുക — സെർച്ച് എഞ്ചിനുകൾ അവയുടെ ഇൻഡെക്സ് അപ്‌ഡേറ്റ് ചെയ്യും. SEO അധികാരം പുതിയ URL-ലേക്ക് കൈമാറും.

റീഡയറക്ട് സ്ഥിരമല്ലെന്ന് സൂചിപ്പിക്കുന്നു. 301-നെക്കാൾ കാഷിംഗ് കുറവാണ്. 'ലോഗിൻ ആവശ്യമാണ്, /login-ലേക്ക് റീഡയറക്ട് ചെയ്യുന്നു' പോലുള്ള കാര്യങ്ങൾക്ക് ഉപയോഗിക്കുക.

POST സമർപ്പിച്ചതിനു ശേഷം ഉപയോഗിക്കുന്നു — 'നിങ്ങളുടെ POST വിജയിച്ചു, ഫലം ഈ GET URL-ൽ കാണുക' എന്ന് പ്രതികരണം പറയുന്നു. ബ്രൗസറുകൾ എപ്പോഴും പുതിയ URL GET ചെയ്യും.

കണ്ടീഷണൽ അഭ്യർത്ഥനയ്ക്കുള്ള പ്രതികരണം (If-None-Match അല്ലെങ്കിൽ If-Modified-Since ഹെഡറുകൾ സഹിതം). ബാൻഡ്‌വിഡ്ത്ത് ലാഭിക്കുന്നു — ബോഡി തിരികെ നൽകില്ല.

യഥാർത്ഥത്തിൽ POST ആയിരുന്നെങ്കിൽ, റീഡയറക്ടും POST ഉപയോഗിക്കും. മെത്തേഡ് നിലനിർത്തൽ പ്രധാനമാകുമ്പോൾ 302-ന് പകരം ആധുനിക ബദൽ.

റീഡയറക്ടിനു ശേഷം POST അഭ്യർത്ഥനകൾ POST ആയി തുടരണമെങ്കിൽ 301-ന് പകരമുള്ള ആധുനിക രീതി.

സാധാരണ കാരണങ്ങൾ: ബോഡിയിൽ തെറ്റായ JSON, അസാധുവായ ക്വറി പാരാമീറ്ററുകൾ, അല്ലെങ്കിൽ ആവശ്യമായ ഫീൽഡുകൾ ഇല്ലാത്തത്. അഭ്യർത്ഥന ബോഡിയും ഹെഡറുകളും പരിശോധിക്കുക.

ക്ലയന്റ് ഓതന്റിക്കേഷൻ ക്രെഡൻഷ്യലുകൾ (Authorization ഹെഡർ, കുക്കി, ടോക്കൺ) ഉൾപ്പെടുത്തണം. 'Unauthorized' എന്നത് തെറ്റായ പേരാണ് — യഥാർത്ഥത്തിൽ ഇതിനർത്ഥം 'ഓതന്റിക്കേറ്റ് ചെയ്തിട്ടില്ല' എന്നാണ്.

യഥാർത്ഥത്തിൽ ഡിജിറ്റൽ പേയ്‌മെന്റുകൾക്കായി ഉദ്ദേശിച്ചത്. ആധുനിക ഉപയോഗം: ഒരു ഉപയോക്താവ് പണമടച്ച ക്വാട്ട കവിഞ്ഞാൽ APIകൾ ചിലപ്പോൾ 402 തിരികെ നൽകുന്നു.

401-ൽ നിന്ന് വ്യത്യസ്തം — ഉപയോക്താവ് ലോഗിൻ ചെയ്തിട്ടുണ്ട്, പക്ഷേ ഈ റിസോഴ്‌സിന് അക്കൗണ്ടിന് അനുമതിയില്ല. റോൾ/അനുമതി ലോജിക് പരിശോധിക്കുക.

URL തെറ്റാണ്, റിസോഴ്‌സ് ഇല്ലാതാക്കി, അല്ലെങ്കിൽ അത് ഒരിക്കലും നിലവിലുണ്ടായിരുന്നില്ല. 403 ആണ് കൂടുതൽ കൃത്യമെന്നത് മറയ്ക്കാൻ സെർവറുകൾ ചിലപ്പോൾ 404 തിരികെ നൽകും.

ഉദാഹരണത്തിന്, POST മാത്രം സ്വീകരിക്കുന്ന എൻഡ്‌പോയിന്റിലേക്കുള്ള GET അഭ്യർത്ഥന. പ്രതികരണത്തിൽ സാധുവായ മെത്തേഡുകൾ ലിസ്റ്റ് ചെയ്യുന്ന Allow ഹെഡർ ഉൾപ്പെടുത്തണം.

സെർവറിന് നിറവേറ്റാൻ കഴിയാത്ത കണ്ടന്റ് തരം, ഭാഷ, അല്ലെങ്കിൽ എൻകോഡിംഗ് (Accept, Accept-Language, Accept-Encoding വഴി) ക്ലയന്റ് ആവശ്യപ്പെട്ടു. പല സെർവറുകളും കർശനമായ നെഗോഷിയേഷൻ ഒഴിവാക്കി ഡിഫോൾട്ട് നൽകും.

401 പോലെ, പക്ഷേ പ്രോക്സി നൽകുന്നത്: ക്ലയന്റ് Proxy-Authorization ക്രെഡൻഷ്യലുകൾ അയക്കണം. ഓതന്റിക്കേറ്റിംഗ് പ്രോക്സികളുള്ള കോർപ്പറേറ്റ് നെറ്റ്‌വർക്കുകളിൽ കാണാറുണ്ട്.

അഭ്യർത്ഥന ബോഡി അയക്കാൻ ക്ലയന്റ് വളരെ സമയമെടുത്തു അല്ലെങ്കിൽ കണക്ഷൻ നിഷ്‌ക്രിയമായി സൂക്ഷിച്ചു. അഭ്യർത്ഥന വീണ്ടും ശ്രമിക്കുക.

സാധാരണയായി ഒരേസമയ എഡിറ്റ് വൈരുദ്ധ്യങ്ങൾക്കോ ഡ്യൂപ്ലിക്കേറ്റ് റിസോഴ്‌സ് സൃഷ്ടിക്കുന്നതിനോ (ഉദാ. ഇതിനകം നിലവിലുള്ള ഇമെയിലുള്ള ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുന്നത്) തിരികെ നൽകുന്നു.

404-നെക്കാൾ ശക്തം — റിസോഴ്‌സ് മുമ്പ് നിലവിലുണ്ടായിരുന്നെന്നും സ്ഥിരമായി നീക്കം ചെയ്തെന്നും സെർവറിന് വ്യക്തമായി അറിയാം. സെർച്ച് എഞ്ചിനുകൾ ഡിഇൻഡെക്സ് ചെയ്യും.

Content-Length ഹെഡർ ഇല്ലാത്തതിനാൽ അഭ്യർത്ഥന നിരസിച്ചു, അജ്ഞാത വലിപ്പമുള്ള ബോഡികൾ സെർവർ നിരസിക്കുന്നു. ഹെഡർ ചേർത്ത് വീണ്ടും ശ്രമിക്കുക.

If-Match അല്ലെങ്കിൽ If-Unmodified-Since പോലുള്ള കണ്ടീഷണൽ ഹെഡറുകൾ പരാജയപ്പെടുമ്പോൾ തിരികെ നൽകുന്നു — സാധാരണയായി ഒപ്റ്റിമിസ്റ്റിക് ലോക്കിംഗ്: നിങ്ങളുടെ പതിപ്പിനു ശേഷം മറ്റാരോ റിസോഴ്‌സ് മാറ്റി. വീണ്ടും ഫെച്ച് ചെയ്ത് ശ്രമിക്കുക.

വലിയ ഫയലുകൾ അപ്‌ലോഡ് ചെയ്യുമ്പോൾ സാധാരണം. സെർവർ കോൺഫിഗ് (nginx, apache) പരമാവധി ബോഡി വലിപ്പം സെറ്റ് ചെയ്യുന്നു. സെർവറിന്റെ കോൺഫിഗറേഷൻ പരിശോധിക്കുക.

സാധാരണയായി വളരെ നീളമുള്ള ക്വറി സ്ട്രിംഗുകൾ (ഉദാ. GET-ൽ ഡാറ്റ എൻകോഡ് ചെയ്യൽ) കാരണമാണ്. POST ബോഡിയിലേക്ക് മാറുക, അല്ലെങ്കിൽ നിങ്ങൾക്ക് നിയന്ത്രിക്കാൻ കഴിയുമെങ്കിൽ സെർവർ പരിധി ഉയർത്തുക.

ഉദാഹരണത്തിന്, application/json മാത്രം സ്വീകരിക്കുന്ന സെർവറിലേക്ക് application/xml അയക്കുന്നത്. Content-Type ഹെഡർ ശരിയായി സെറ്റ് ചെയ്യുക.

Range ഹെഡർ ഫയലിന് ഇല്ലാത്ത ഒരു ഭാഗം ആവശ്യപ്പെടുന്നു — ഉദാ. ഫയലിന്റെ അവസാനത്തിനു ശേഷം ഒരു ഡൗൺലോഡ് പുനരാരംഭിക്കുന്നത്. യഥാർത്ഥ വലിപ്പം സഹിതം Content-Range പ്രതികരണത്തിൽ ഉൾപ്പെടുത്തണം.

Expect: 100-continue സെർവർ പിന്തുണയ്ക്കാത്തപ്പോൾ അയക്കുന്നു. ചില ക്ലയന്റുകൾ വലിയ POST-കളിൽ ഡിഫോൾട്ടായി ഈ ഹെഡർ അയക്കും; ഇത് നിർജ്ജീവമാക്കുന്നത് സാധാരണയായി പിശക് പരിഹരിക്കും.

1998-ലെ ഒരു ഏപ്രിൽ ഫൂൾ തമാശ (RFC 2324). ചില യഥാർത്ഥ APIകൾ തമാശയ്ക്കോ കാലഹരണപ്പെട്ട എൻഡ്‌പോയിന്റുകൾ അടയാളപ്പെടുത്താനോ ഇത് ഉപയോഗിക്കുന്നു. പ്രൊഡക്ഷനിൽ ഉപയോഗിക്കരുത്.

HTTP/2 കണക്ഷൻ പുനരുപയോഗത്തിൽ സാധാരണം: ടാർഗെറ്റ് ഹോസ്റ്റ്‌നെയ്മിനായി കോൺഫിഗർ ചെയ്തിട്ടില്ലാത്ത സെർവറിലേക്ക് അഭ്യർത്ഥന എത്തി. ക്ലയന്റ് ഒരു പുതിയ കണക്ഷനിൽ വീണ്ടും ശ്രമിക്കണം.

ഉദാഹരണത്തിന്, JSON ശരിയായി പാഴ്സ് ചെയ്തു, പക്ഷേ ആവശ്യമായ ഒരു ഫീൽഡ് ഇല്ലായിരുന്നു, അല്ലെങ്കിൽ ഒരു ഫീൽഡിന്റെ മൂല്യം പരിധിക്ക് പുറത്തായിരുന്നു. REST API വാലിഡേഷൻ പ്രതികരണങ്ങളിൽ സാധാരണം.

WebDAV: സോഴ്‌സ് അല്ലെങ്കിൽ ഡെസ്റ്റിനേഷൻ റിസോഴ്‌സ് മറ്റൊരു ക്ലയന്റ് ലോക്ക് ചെയ്തിരിക്കുന്നു, അതിനാൽ പ്രവർത്തനം തുടരാനാവില്ല. ലോക്ക് റിലീസ് ചെയ്യുന്നത് വരെ കാത്തിരിക്കുക അല്ലെങ്കിൽ ശരിയായ ടോക്കൺ ഉപയോഗിച്ച് അത് ബ്രേക്ക് ചെയ്യുക.

WebDAV: ആശ്രിത പ്രവർത്തനങ്ങളുടെ ഒരു ശൃംഖലയിൽ, ഒരു മുൻ പ്രവർത്തനം പരാജയപ്പെട്ടു, അതിനാൽ ഇത് നടത്തിയില്ല. യഥാർത്ഥ കാരണത്തിനായി മുൻ പരാജയം നോക്കുക.

TLS 1.3 0-RTT (early data) മായി ബന്ധപ്പെട്ടത്: ആവർത്തിച്ചേക്കാവുന്ന അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യാൻ സെർവർ റിസ്ക് എടുക്കില്ല. ഹാൻഡ്ഷേക്ക് പൂർത്തിയായ ശേഷം ക്ലയന്റ് വീണ്ടും ശ്രമിക്കണം.

നിലവിലെ പ്രോട്ടോക്കോളിൽ അഭ്യർത്ഥന നൽകാൻ സെർവർ വിസമ്മതിക്കുന്നു, പക്ഷേ അപ്‌ഗ്രേഡിനു ശേഷം നൽകും — ആവശ്യമായ പ്രോട്ടോക്കോൾ പേരിടുന്ന Upgrade ഹെഡർ പ്രതികരണത്തിൽ ഉൾപ്പെടുന്നു.

ലോസ്റ്റ്-അപ്ഡേറ്റ് വൈരുദ്ധ്യങ്ങൾ തടയാൻ സെർവർ കണ്ടീഷണൽ ഹെഡറുകൾ (If-Match പോലെ) ആവശ്യപ്പെടുന്നു. റിസോഴ്‌സ് ഫെച്ച് ചെയ്യുക, അതിന്റെ ETag പിടിച്ചെടുക്കുക, If-Match സഹിതം വീണ്ടും അയക്കുക.

വേഗത കുറയ്ക്കുക. എപ്പോൾ വീണ്ടും ശ്രമിക്കണമെന്ന് സൂചിപ്പിക്കുന്ന Retry-After ഹെഡർ പ്രതികരണത്തിൽ ഉൾപ്പെടുത്തണം. അഭ്യർത്ഥന ക്വാട്ടകളുള്ള APIകളിൽ സാധാരണം.

ഒരു ഹെഡർ അല്ലെങ്കിൽ മൊത്തം ഹെഡർ വലിപ്പം പരിധി കവിയുന്നു — മിക്കപ്പോഴും വലിയ കുക്കികൾ കാരണം. കുക്കികൾ മായ്ക്കുക അല്ലെങ്കിൽ നിങ്ങളുടെ ആപ്പ് അവയിൽ സൂക്ഷിക്കുന്നത് കുറയ്ക്കുക.

നിയമപരമായ കാരണങ്ങളാൽ റിസോഴ്‌സ് തടഞ്ഞിരിക്കുന്നു — സെൻസർഷിപ്പ്, കോടതി ഉത്തരവുകൾ, അല്ലെങ്കിൽ പ്രാദേശിക നിയന്ത്രണങ്ങൾ. ഈ നമ്പർ ഫാരൻഹീറ്റ് 451 എന്ന നോവലിനെ സൂചിപ്പിക്കുന്നു.

സെർവർ-സൈഡ് പിശകുകൾക്കുള്ള പൊതു കാച്ച്-ഓൾ. യഥാർത്ഥ കാരണത്തിനായി സെർവർ ലോഗുകൾ പരിശോധിക്കുക: കൈകാര്യം ചെയ്യാത്ത എക്സെപ്ഷൻ, ഡാറ്റാബേസ് പിശക് മുതലായവ.

ഉദാഹരണത്തിന്, സെർവർ HTTP മെത്തേഡ് തിരിച്ചറിയുന്നില്ല. പ്രായോഗികമായി അപൂർവം — കൂടുതലും നിങ്ങൾ 405 കാണും.

മൈക്രോസർവീസ് ആർക്കിടെക്ചറുകളിൽ സാധാരണം. നിങ്ങളുടെ ലോഡ് ബാലൻസറിനോ റിവേഴ്‌സ് പ്രോക്സിക്കോ ബാക്കെൻഡ് സേവനത്തിൽ നിന്ന് തെറ്റായ പ്രതികരണം ലഭിച്ചു.

മെയിന്റനൻസിന് വേണ്ടി ഇറക്കിവച്ചതോ ഓവർലോഡ് ആയതോ ആണ്. Retry-After ഹെഡർ പ്രതികരണത്തിൽ ഉൾപ്പെടുത്തണം. ഡിപ്ലോയ്‌മെന്റുകൾക്കിടയിൽ പലപ്പോഴും ഇത് തിരികെ നൽകും.

ബാക്കെൻഡ് സേവനം വേഗത്തിൽ പ്രതികരിച്ചില്ല. അപ്‌സ്ട്രീം സേവനത്തിന്റെ ആരോഗ്യവും സമയപരിധി കോൺഫിഗറേഷനുകളും പരിശോധിക്കുക.

അഭ്യർത്ഥനയുടെ പ്രധാന HTTP പതിപ്പ് സെർവർ പിന്തുണയ്ക്കുന്നില്ല. ആധുനിക ക്ലയന്റുകളിൽ ഇത് ഏതാണ്ട് ഒരിക്കലും കാണില്ല.

സുതാര്യമായ കണ്ടന്റ് നെഗോഷിയേഷൻ ഒരു ലൂപ്പിൽ അവസാനിച്ചു: തിരഞ്ഞെടുത്ത വേരിയന്റ് തന്നെ നെഗോഷിയേറ്റ് ചെയ്യാൻ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു. ഒരു സെർവർ കോൺഫിഗറേഷൻ പിശക് സൂചിപ്പിക്കുന്നു.

ഉത്ഭവത്തിൽ WebDAV-സ്പെസിഫിക്, പക്ഷേ ചിലപ്പോൾ പൊതു സെർവറുകൾ ഉപയോഗിക്കുന്നു. സംഭരണ പരിമിതികൾ കാരണം അഭ്യർത്ഥന സേവ് ചെയ്യാൻ സെർവറിന് കഴിയില്ല എന്നാണ് അർത്ഥം.

WebDAV: Depth: infinity അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുമ്പോൾ ഒരു ലൂപ്പിൽ (ഉദാ. വൃത്താകൃതിയിലുള്ള ബൈൻഡിംഗുകൾ) പ്രവേശിച്ചു. പ്രവർത്തനം അവസാനിപ്പിച്ചു.

കാലഹരണപ്പെട്ട HTTP Extension Framework-ൽ നിന്ന്: അഭ്യർത്ഥന നിറവേറ്റുന്നതിന് മുമ്പ് സെർവറിന് കൂടുതൽ വിവരങ്ങൾ ആവശ്യമാണ്. ആധുനിക വെബിൽ ഫലത്തിൽ ഉപയോഗിക്കുന്നില്ല.

ബാഹ്യ സൈറ്റുകൾ ആക്‌സസ് ചെയ്യുന്നതിന് മുമ്പ് ഉപയോക്താവ് നെറ്റ്‌വർക്കിൽ ലോഗിൻ ചെയ്യണമെന്ന് സൂചിപ്പിക്കാൻ ക്യാപ്റ്റീവ് പോർട്ടലുകൾ (ഹോട്ടൽ/എയർപോർട്ട് വൈഫൈ) ഇത് ഉപയോഗിക്കുന്നു.