Bepul HTTP Holat Kodlari Ma'lumotnomasi

Expect: 100-continue bo'lgan so'rovlar uchun ishlatiladi. Server mijoz tanasini yuborishdan oldin uni qabul qilishga tayyorligini tasdiqlaydi. Zamonaviy veb-ilovalarda kamdan-kam uchraydi.

Ko'pincha WebSocket yangilanishlari uchun ishlatiladi — mijoz Upgrade: websocket so'raydi va server almashtirish uchun 101 bilan javob beradi.

Uzoq davom etadigan amallar paytida mijoz vaqt tugashining oldini olish uchun yuboriladigan WebDAV oraliq javobi. Eskirgan — zamonaviy serverlar uni yubormasligi kerak.

Serverlarga yakuniy javob hali tayyorlanayotgan paytda Link sarlavhalarini (preload/preconnect) yuborish imkonini beradi, shunda brauzerlar muhim resurslarni tezroq yuklashni boshlashi mumkin.

Standart muvaffaqiyatli javob. Ma'nosi HTTP metodiga bog'liq: GET → resurs qaytarildi, POST/PUT → amal bajarildi.

POST-dan keyin odatiy holat. Javobda yangi resurs URL-iga ishora qiluvchi Location sarlavhasi bo'lishi kerak.

Asinxron amallar uchun — server ishni navbatga qo'ymoqda. Mijoz holat endpointini so'rashi yoki keyinroq tekshirishi kerak.

So'rov muvaffaqiyatli bajarildi, ammo oraliq vosita (masalan, keshlash yoki o'zgartiruvchi proksi) manba serverdan kelgan yukni o'zgartirdi — masalan, rasmlarni qayta siqish. Amalda kamdan-kam uchraydi.

Ko'pincha DELETE amallari yoki tana qaytarishni talab qilmaydigan PUT yangilanishlari uchun ishlatiladi. Mijoz joriy sahifadan chiqib ketmasligi kerak.

204 kabi, tana qaytarilmaydi — lekin mijozga qo'shimcha ravishda so'rovni yaratgan forma yoki ko'rinishni qayta tiklash aytiladi (masalan, keyingi kiritish uchun forma maydonlarini tozalash).

Range so'roviga javob. Video pleyerlar va yuklab olish menejerlari tomonidan uzilgan yuklab olishlarni davom ettirish yoki katta fayllarni oqim sifatida uzatish uchun ishlatiladi.

WebDAV: XML tanasi bir nechta quyi amallar natijasini alohida-alohida bildiradi — masalan, ba'zi elementlar muvaffaqiyatli, boshqalari muvaffaqiyatsiz bo'lgan ommaviy ko'chirish.

WebDAV: bog'lanishlar tsikl hosil qilganda bir xil to'plam a'zolarini qayta-qayta sanab o'tirmaslik uchun 207 Multi-Status javoblarida ishlatiladi.

Delta kodlash: server to'liq resurs o'rniga oldingi versiyaga nisbatan farqni qaytaradi va shu bilan trafikni tejaydi. Juda kam qo'llaniladi.

Server bir nechta variant (masalan, turli format yoki tillar) taklif qiladi va mijoz ulardan birini tanlashi kerak. Kamdan-kam ishlatiladi, chunki avtomatik kontent moslashuvi odatda buni o'zi hal qiladi.

Doimiy URL o'zgarishlari uchun ishlating — qidiruv tizimlari indeksini yangilaydi. SEO nufuzi yangi URL manziliga o'tadi.

Yo'naltirish doimiy emasligini bildiradi. Keshlash 301 ga qaraganda kamroq agressiv. Masalan, "tizimga kirish talab qilinadi, /login sahifasiga yo'naltirilmoqda" holatlari uchun ishlating.

POST yuborilgandan keyin ishlatiladi — javob "POST so'rovingiz bajarildi, natijani ushbu GET URL orqali ko'ring" degan ma'noni bildiradi. Brauzerlar har doim yangi URL manzilga GET so'rovi yuboradi.

Shartli so'rovga (If-None-Match yoki If-Modified-Since sarlavhalari bilan) javob. Trafikni tejaydi — hech qanday tana qaytarilmaydi.

Agar asl so'rov POST bo'lsa, yo'naltirish ham POST bo'lib qoladi. Metodni saqlash muhim bo'lganda 302 ning zamonaviy muqobili.

Yo'naltirishdan keyin ham POST so'rovlari POST bo'lib qolishini istasangiz, 301 ning zamonaviy o'rnini bosuvchisi.

Odatiy sabablar: tanadagi noto'g'ri JSON, yaroqsiz so'rov parametrlari yoki yetishmayotgan majburiy maydonlar. So'rov tanasi va sarlavhalarini tekshiring.

Mijoz autentifikatsiya ma'lumotlarini (Authorization sarlavhasi, cookie, token) yuborishi kerak. "Unauthorized" nomi biroz noto'g'ri — aslida bu "autentifikatsiya qilinmagan" degani.

Dastlab raqamli to'lovlar uchun mo'ljallangan edi. Zamonaviy foydalanish: foydalanuvchi pullik kvotasidan oshib ketganda API'lar ba'zan 402 qaytaradi.

401 dan farqi — foydalanuvchi tizimga kirgan, lekin uning hisobida ushbu resurs uchun ruxsat yo'q. Rol/ruxsatlar mantig'ini tekshiring.

Yoki URL manzil noto'g'ri, yoki resurs o'chirilgan, yoki u umuman mavjud bo'lmagan. Ba'zan serverlar 403 to'g'riroq bo'lgan holatlarda ham buni yashirish uchun 404 qaytaradi.

Masalan, faqat POST qabul qiladigan endpointga GET so'rovi yuborilishi. Javobda ruxsat etilgan metodlarni sanab o'tuvchi Allow sarlavhasi bo'lishi kerak.

Mijoz server qondira olmaydigan kontent turi, til yoki kodlashni (Accept, Accept-Language, Accept-Encoding orqali) so'ragan. Ko'p serverlar qat'iy moslashuvni o'tkazib yuborib, standart variantni qaytaradi.

401 kabi, lekin proksi tomonidan chiqariladi: mijoz Proxy-Authorization ma'lumotlarini yuborishi kerak. Autentifikatsiya talab qiluvchi proksili korporativ tarmoqlarda uchraydi.

Mijoz so'rov tanasini yuborishda juda uzoq vaqt sarfladi yoki ulanishni harakatsiz holda ushlab turdi. So'rovni qayta urinib ko'ring.

Odatda bir vaqtdagi tahrirlash ziddiyatlari yoki takroriy resurs yaratish uchun qaytariladi (masalan, allaqachon mavjud email bilan foydalanuvchi yaratish).

404 dan kuchliroq — server resurs ILGARI mavjud bo'lganini, lekin butunlay olib tashlanganini aniq biladi. Qidiruv tizimlari uni indeksdan chiqaradi.

So'rov Content-Length sarlavhasi yo'qligi sababli rad etildi, server esa noma'lum hajmdagi tanalarni qabul qilmaydi. Sarlavhani qo'shib, qayta urinib ko'ring.

If-Match yoki If-Unmodified-Since kabi shartli sarlavhalar bajarilmaganda qaytariladi — odatda optimistik bloklash: boshqa kimdir resursni sizning versiyangizdan keyin o'zgartirgan. Qayta yuklab oling va qayta urinib ko'ring.

Katta fayllarni yuklashda ko'p uchraydi. Server sozlamalari (nginx, apache) maksimal tana hajmini belgilaydi. Server sozlamalarini tekshiring.

Odatda juda uzun so'rov satrlari sabab bo'ladi (masalan, GET so'rovida ma'lumotni kodlash). POST tanasiga o'ting yoki, agar serverni boshqarsangiz, chegarani oshiring.

Masalan, faqat application/json qabul qiladigan serverga application/xml yuborish. Content-Type sarlavhasini to'g'ri sozlang.

Range sarlavhasi faylda mavjud bo'lmagan qismni so'ramoqda — masalan, fayl oxiridan keyin yuklab olishni davom ettirish. Javobda haqiqiy hajmni ko'rsatuvchi Content-Range bo'lishi kerak.

Server Expect: 100-continue ni qo'llab-quvvatlamaganda yuboriladi. Ba'zi mijozlar bu sarlavhani katta POST so'rovlarida standart bo'yicha yuboradi; uni o'chirish odatda xatolikni hal qiladi.

1998-yilgi 1-aprel hazili (RFC 2324). Ba'zi haqiqiy API'lar buni hazil sifatida yoki eskirgan endpointlarni belgilash uchun ishlatadi. Ishlab chiqarishda ishlatilmaydi.

HTTP/2 ulanishni qayta ishlatishda ko'p uchraydi: so'rov maqsad host nomi uchun sozlanmagan serverga yetib borgan. Mijoz yangi ulanishda qayta urinishi kerak.

Masalan, JSON to'g'ri o'qildi, lekin majburiy maydon yetishmayapti yoki maydon qiymati diapazondan tashqarida. REST API tekshiruv javoblarida ko'p uchraydi.

WebDAV: manba yoki maqsad resurs boshqa mijoz tomonidan qulflangan, shuning uchun amal davom eta olmaydi. Qulf ochilishini kuting yoki tegishli token bilan uni buzing.

WebDAV: bog'liq amallar zanjirida oldingi amal muvaffaqiyatsiz tugadi, shuning uchun bu amal bajarilmadi. Asosiy sabab uchun oldingi xatolikka qarang.

TLS 1.3 0-RTT (erta ma'lumot) bilan bog'liq: server qayta yuborilgan bo'lishi mumkin bo'lgan so'rovni qayta ishlash xavfini o'z zimmasiga olmaydi. Mijoz qo'l siqishuv tugagandan keyin qayta urinishi kerak.

Server so'rovni joriy protokol orqali bajarishdan bosh tortadi, lekin yangilashdan keyin bajaradi — javobda talab qilinadigan protokolni nomlovchi Upgrade sarlavhasi bo'ladi.

Server yo'qotilgan yangilanish ziddiyatlarining oldini olish uchun shartli sarlavhalarni (If-Match kabi) talab qiladi. Resursni yuklab oling, uning ETag qiymatini oling va If-Match bilan qayta yuboring.

Sekinlashtiring. Javobda qachon qayta urinish kerakligini ko'rsatuvchi Retry-After sarlavhasi bo'lishi kerak. So'rovlar kvotasiga ega API'larda ko'p uchraydi.

Yoki bitta sarlavha, yoki umumiy sarlavha hajmi chegaradan oshib ketgan — ko'pincha bunga haddan tashqari katta cookie'lar sabab bo'ladi. Cookie'larni tozalang yoki ilovangiz ularda saqlayotgan ma'lumotni kamaytiring.

Resurs huquqiy sabablarga ko'ra bloklangan — senzura, sud qarorlari yoki mintaqaviy qoidalar. Raqam "Fahrenheit 451" romaniga ishoradir.

Server tomonidagi xatolar uchun umumiy tur. Haqiqiy sababni bilish uchun server jurnallarini tekshiring: qayta ishlanmagan istisno, ma'lumotlar bazasi xatosi va h.k.

Masalan, server HTTP metodini tanimaydi. Amalda kamdan-kam uchraydi — ko'proq 405 ko'rasiz.

Mikroservis arxitekturalarida ko'p uchraydi. Yuklama balansirovkachingiz yoki teskari proksingiz backend xizmatidan buzuq javob oldi.

Yoki texnik xizmat ko'rsatish uchun o'chirilgan, yoki ortiqcha yuklangan. Javobda Retry-After sarlavhasi bo'lishi kerak. Ko'pincha deploy jarayonida qaytariladi.

Backend xizmati yetarlicha tez javob bermadi. Yuqori bosqich xizmatining holati va vaqt sozlamalarini tekshiring.

So'rovning asosiy HTTP versiyasi server tomonidan qo'llab-quvvatlanmaydi. Zamonaviy mijozlarda deyarli uchramaydi.

Shaffof kontent moslashuvi tsiklga tushib qoldi: tanlangan variant o'zi ham moslashishga sozlangan. Server sozlamasidagi xatolikni bildiradi.

Kelib chiqishi WebDAV'ga xos, lekin ba'zan umumiy serverlar tomonidan ham ishlatiladi. Xotira cheklovlari tufayli server so'rovni saqlay olmasligini bildiradi.

WebDAV: Depth: infinity so'rovini qayta ishlash tsiklga tushib qoldi (masalan, aylanma bog'lanishlar). Amal to'xtatildi.

Eskirgan HTTP Extension Framework'dan: server so'rovni bajarish uchun qo'shimcha ma'lumot talab qiladi. Zamonaviy internetda amalda ishlatilmaydi.

Foydalanuvchi tashqi saytlarga kirishdan oldin tarmoqqa kirish uchun tizimga kirishi kerakligini bildirish uchun captive portal'lar (mehmonxona/aeroport Wi-Fi) tomonidan ishlatiladi.