મફત HTTP સ્ટેટસ કોડ્સ રેફરન્સ

Expect: 100-continue વાળી વિનંતીઓ માટે વપરાય છે. સર્વર જણાવે છે કે તે body મળે તે પહેલાં તેને સ્વીકારવા તૈયાર છે. આધુનિક વેબ એપ્સમાં ભાગ્યે જ જોવા મળે છે.

મોટાભાગે WebSocket અપગ્રેડ માટે વપરાય છે — ક્લાયન્ટ Upgrade: websocket વિનંતી કરે છે અને સર્વર સ્વિચ કરવા 101 જવાબ આપે છે.

લાંબી કામગીરી દરમિયાન ક્લાયન્ટ ટાઇમઆઉટ અટકાવવા મોકલવામાં આવતો WebDAV વચગાળાનો જવાબ. Deprecated — આધુનિક સર્વરોએ તે મોકલવું જોઈએ નહીં.

અંતિમ જવાબ હજુ તૈયાર થઈ રહ્યો હોય ત્યારે સર્વરોને Link headers (preload/preconnect) મોકલવા દે છે, જેથી બ્રાઉઝર જરૂરી assets વહેલા ફેચ કરવાનું શરૂ કરી શકે.

પ્રમાણભૂત સફળતાનો જવાબ. અર્થ HTTP method પર આધારિત છે: GET → resource પરત મળે છે, POST/PUT → ક્રિયા પૂર્ણ થઈ.

સામાન્ય રીતે POST પછી. જવાબમાં નવા resource ના URL તરફ ઇશારો કરતું Location header હોવું જોઈએ.

અસિંક્રોનસ કામગીરીઓ માટે — સર્વર કામને ક્યૂમાં મૂકી રહ્યું છે. ક્લાયન્ટે status endpoint પોલ કરવું જોઈએ અથવા પછીથી તપાસવું જોઈએ.

વિનંતી સફળ થઈ, પણ કોઈ intermediary (જેમ કે caching અથવા transforming proxy) એ origin server માંથી payload બદલ્યો — ઉદાહરણ તરીકે, ઇમેજને ફરીથી compress કરીને. વ્યવહારમાં દુર્લભ.

ઘણીવાર DELETE કામગીરીઓ અથવા body પરત કરવાની જરૂર ન હોય તેવા PUT અપડેટ્સ માટે વપરાય છે. ક્લાયન્ટે વર્તમાન પેજ પરથી દૂર ન જવું જોઈએ.

204 ની જેમ, કોઈ body પરત મળતો નથી — પણ ક્લાયન્ટને વધુમાં એ ફોર્મ અથવા view રીસેટ કરવાનું કહેવાય છે જેણે વિનંતી બનાવી (દા.ત. આગલી એન્ટ્રી માટે ફોર્મ ફિલ્ડ્સ સાફ કરવા).

Range વિનંતીનો જવાબ. અટકેલા ડાઉનલોડ ફરી શરૂ કરવા અથવા મોટી ફાઇલો સ્ટ્રીમ કરવા વિડિયો પ્લેયર્સ અને ડાઉનલોડ મેનેજર્સ દ્વારા વપરાય છે.

WebDAV: એક XML body અનેક sub-operations ના પરિણામો સ્વતંત્ર રીતે જણાવે છે — દા.ત. batch move જેમાં કેટલીક વસ્તુઓ સફળ થઈ અને અન્ય નિષ્ફળ ગઈ.

WebDAV: બાઇન્ડિંગ્સ લૂપ બનાવે ત્યારે એક જ કલેક્શનના સભ્યોને વારંવાર સૂચિબદ્ધ ન કરવા 207 Multi-Status પ્રતિસાદોમાં વપરાય છે.

ડેલ્ટા એન્કોડિંગ: સર્વર સંપૂર્ણ રિસોર્સને બદલે અગાઉના વર્ઝન સાથેનો ડિફ પરત કરે છે, જેથી બેન્ડવિડ્થ બચે છે. ભાગ્યે જ ઉપયોગમાં લેવાય છે.

સર્વર અનેક વિકલ્પો (દા.ત. અલગ ફોર્મેટ કે ભાષાઓ) ઓફર કરે છે અને ક્લાયન્ટે એક પસંદ કરવો જોઈએ. ભાગ્યે જ વપરાય છે, કારણ કે ઓટોમેટિક કન્ટેન્ટ નેગોશિયેશન સામાન્ય રીતે આ સંભાળે છે.

કાયમી 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' નામ ભ્રામક છે — તેનો ખરેખર અર્થ 'unauthenticated' છે.

મૂળ ડિજિટલ ચુકવણીઓ માટે ઈરાદો હતો. આધુનિક ઉપયોગ: વપરાશકર્તાએ તેમનો ચૂકવેલ ક્વોટા વટાવ્યો હોય ત્યારે APIs ક્યારેક 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). કેટલાક વાસ્તવિક APIs તેને મજાક માટે અથવા deprecated એન્ડપોઇન્ટ્સ ચિહ્નિત કરવા વાપરે છે. પ્રોડક્શન માટે નહીં.

HTTP/2 કનેક્શન રીયુઝ સાથે સામાન્ય: રિક્વેસ્ટ એવા સર્વર પર પહોંચી કે જે લક્ષ્ય હોસ્ટનેમ માટે કન્ફિગર થયેલ નથી. ક્લાયન્ટે નવા કનેક્શન પર ફરીથી પ્રયાસ કરવો જોઈએ.

ઉદાહરણ તરીકે, JSON યોગ્ય રીતે પાર્સ થયું પણ જરૂરી ફીલ્ડ ગુમ હતું, અથવા ફીલ્ડ વેલ્યુ મર્યાદા બહાર હતી. REST API વેલિડેશન પ્રતિસાદોમાં સામાન્ય.

WebDAV: સ્રોત અથવા લક્ષ્ય રિસોર્સ બીજા ક્લાયન્ટ દ્વારા લોક કરેલ છે, તેથી ઓપરેશન આગળ વધી શકતું નથી. લોક છૂટે તેની રાહ જુઓ અથવા યોગ્ય ટોકન વડે તેને તોડો.

WebDAV: આધારિત ઓપરેશન્સની ચેઇનમાં, અગાઉનું પગલું નિષ્ફળ ગયું, તેથી આ કરવામાં આવ્યું નહીં. મૂળ કારણ માટે અગાઉની નિષ્ફળતા જુઓ.

TLS 1.3 0-RTT (early data) સાથે સંબંધિત: સર્વર સંભવિત રીતે ફરીથી ચલાવવામાં આવેલી રિક્વેસ્ટ પર પ્રક્રિયા કરવાનું જોખમ લેશે નહીં. ક્લાયન્ટે હેન્ડશેક પૂર્ણ થયા પછી ફરીથી પ્રયાસ કરવો જોઈએ.

સર્વર હાલના પ્રોટોકોલ પર રિક્વેસ્ટ સર્વ કરવાનો ઇનકાર કરે છે પણ અપગ્રેડ પછી કરશે — પ્રતિસાદમાં જરૂરી પ્રોટોકોલનું નામ આપતું Upgrade હેડર હોય છે.

લોસ્ટ-અપડેટ સંઘર્ષો રોકવા સર્વર કન્ડિશનલ હેડર (જેમ કે If-Match) માંગે છે. રિસોર્સ મેળવો, તેનું ETag કેપ્ચર કરો, અને If-Match સાથે ફરી મોકલો.

ધીમા પડો. પ્રતિસાદમાં ક્યારે ફરીથી પ્રયાસ કરવો તે દર્શાવતું Retry-After હેડર હોવું જોઈએ. રિક્વેસ્ટ ક્વોટા ધરાવતા APIs સાથે સામાન્ય.

કાં તો એક હેડર અથવા કુલ હેડર કદ મર્યાદા વટાવે છે — મોટેભાગે વધુ પડતી મોટી કૂકીઝને કારણે. કૂકીઝ સાફ કરો અથવા તમારી એપ તેમાં જે સંગ્રહ કરે છે તે ઘટાડો.

રિસોર્સ કાયદાકીય કારણોસર બ્લોક કરવામાં આવ્યો છે — સેન્સરશિપ, કોર્ટ ઓર્ડર, અથવા પ્રાદેશિક નિયમો. આ નંબર 'Fahrenheit 451' નવલકથાનો સંકેત છે.

સર્વર-સાઇડ ભૂલો માટે સામાન્ય કેચ-ઑલ. વાસ્તવિક કારણ માટે સર્વર લોગ તપાસો: અનહેન્ડલ્ડ એક્સેપ્શન, ડેટાબેઝ ભૂલ, વગેરે.

ઉદાહરણ તરીકે, સર્વર HTTP મેથડ ઓળખતું નથી. વ્યવહારમાં દુર્લભ — તમે વધુ વખત 405 જોશો.

માઇક્રોસર્વિસ આર્કિટેક્ચરમાં સામાન્ય. તમારા લોડ બેલેન્સર અથવા રિવર્સ પ્રોક્સીને બેકએન્ડ સર્વિસ તરફથી ખોડખાંપણવાળો પ્રતિસાદ મળ્યો.

કાં તો મેન્ટેનન્સ માટે બંધ છે અથવા ઓવરલોડેડ છે. પ્રતિસાદમાં Retry-After હેડર હોવું જોઈએ. ઘણીવાર ડિપ્લોયમેન્ટ દરમિયાન પરત કરવામાં આવે છે.

બેકએન્ડ સર્વિસે પૂરતી ઝડપથી પ્રતિસાદ આપ્યો નહીં. અપસ્ટ્રીમ સર્વિસનું આરોગ્ય અને ટાઇમઆઉટ કન્ફિગરેશન તપાસો.

રિક્વેસ્ટનું મુખ્ય HTTP વર્ઝન સર્વર દ્વારા સપોર્ટેડ નથી. આધુનિક ક્લાયન્ટ્સ સાથે લગભગ ક્યારેય જોવા મળતું નથી.

પારદર્શક કન્ટેન્ટ નેગોશિયેશન લૂપમાં સમાપ્ત થયું: પસંદ કરેલ વેરિયન્ટ પોતે નેગોશિયેટ કરવા માટે ગોઠવેલ છે. સર્વર કન્ફિગરેશન ભૂલ સૂચવે છે.

મૂળે WebDAV-વિશિષ્ટ પણ ક્યારેક સામાન્ય સર્વર દ્વારા વપરાય છે. મતલબ કે સર્વર સ્ટોરેજ મર્યાદાઓને કારણે રિક્વેસ્ટ સાચવી શકતું નથી.

WebDAV: Depth: infinity રિક્વેસ્ટ પર પ્રક્રિયા કરતાં લૂપમાં પ્રવેશ થયો (દા.ત. ગોળાકાર બાઇન્ડિંગ્સ). ઓપરેશન સમાપ્ત કરવામાં આવ્યું.

અપ્રચલિત HTTP Extension Framework તરફથી: સર્વરને રિક્વેસ્ટ પૂર્ણ કરતાં પહેલાં વધુ માહિતી જોઈએ છે. આધુનિક વેબ પર ખરેખર વપરાતું નથી.

કેપ્ટિવ પોર્ટલ્સ (હોટેલ/એરપોર્ટ WiFi) દ્વારા વપરાય છે, જે દર્શાવે છે કે બાહ્ય સાઇટ્સ ઍક્સેસ કરતાં પહેલાં વપરાશકર્તાએ નેટવર્કમાં લોગ ઇન કરવું જોઈએ.