Retry-After — HTTP javob sarlavhasi bo‘lib, server mijozga navbatdagi urinishdan oldin qancha kutish kerakligini bildiradi. U odatda vaqtinchalik mavjud emaslik yoki so‘rov tezligi cheklanganda yuboriladi. Sarlavha kechikishni soniyalarda yoki mutlaq HTTP sana shaklida ifodalashi mumkin; mijoz ikkala ko‘rinishni ham ehtiyotkorlik bilan talqin qilishi kerak.
Sintaksis va status kodlari
Sonli qiymat manfiy bo‘lmagan butun son bo‘lib, javob olingan paytdan boshlab kutish soniyalarini anglatadi. Sana qiymati esa GMT asosidagi HTTP-date formatida keladi. Mutlaq sana server va mijoz soatlari mos bo‘lmasa noaniqlik keltirishi mumkin, shu sababli qisqa muddat uchun soniyali shakl oddiyroq. Mijoz noto‘g‘ri, o‘tib ketgan yoki haddan tashqari katta qiymatga nisbatan o‘z xavfsiz chegarasini qo‘llaydi.
429 Too Many Requests bilan Retry-After tezlik limiti qachon yumshashini ko‘rsatadi. 503 Service Unavailable holatida u vaqtinchalik yuk yoki texnik xizmatdan keyin qayta murojaat vaqtini bildiradi. Ayrim qayta yo‘naltirish statuslarida ham qo‘llanishi mumkin. Sarlavha yo‘qligi darhol qayta urinish kerak degani emas; mijozning standart backoff siyosati baribir ishlashi lozim.
Mijoz xulqi
Mijoz Retry-After ko‘rsatmasini umumiy deadline va maksimal urinishlar bilan birga baholaydi. Kutish foydalanuvchi operatsiyasining qolgan muddatidan uzun bo‘lsa, so‘rovni keyin bajariladigan navbatga o‘tkazish yoki xatoni darhol qaytarish ma’qul bo‘lishi mumkin. Ko‘plab mijozlar bir vaqtda uyg‘onib serverga yangi cho‘qqi yuk yubormasligi uchun ko‘rsatilgan muddatga tasodifiy jitter qo‘shiladi.
Qayta urinish faqat amal takrorlashga xavfsiz bo‘lsa bajariladi. Idempotent metodlar odatda qulayroq; holat yaratuvchi so‘rovda idempotency key takroriy natijaning oldini oladi. Javob tanasi o‘qilib, ulanish havzasiga to‘g‘ri qaytarilishi va cancellation signaliga hurmat qilinishi ham muhim.
Server tomoni
Server Retry-After qiymatini haqiqiy tiklanish yoki rate-limit oynasi haqidagi ma’lumotdan hisoblaydi. Har bir so‘rovga bir xil taxminiy qiymat berish mijozlarni sinxronlashtirishi mumkin. Dinamik yukda qiymat taxmin ekanini hisobga olib, server erta qabul qilishga tayyor bo‘lishi yoki yana nazoratli 429/503 qaytarishi kerak.
Rate-limit javobida limit, qolgan kvota va reset vaqtini tushuntiruvchi boshqa standart yoki mahsulotga xos sarlavhalar bo‘lishi mumkin, lekin Retry-After mijoz uchun asosiy kutish ko‘rsatmasi bo‘lib qoladi. Proksi va keshlar status hamda sarlavhani o‘zgartirishi ehtimoli test qilinadi. Kuzatuvda status, endpoint, berilgan kechikish, qayta urinish natijasi va umumiy urinish soni qayd etiladi; autentifikatsiya ma’lumoti esa jurnalga kiritilmaydi.
Oraliq komponentlar va vaqt
Retry-After mutlaq sana bilan kelsa, mijoz serverning Date sarlavhasidan nisbiy farqni hisoblab soat og‘ishini kamaytirishi mumkin. Shunga qaramay, manfiy natija darhol cheksiz urinishga sabab bo‘lmasligi kerak. CDN yoki reverse proxy o‘z 429 javobini yaratishi mumkin, shu bois qaysi qatlam limit qo‘yganini diagnostik sarlavha va tracing orqali ajratish foydali. Kesh 503 javobini saqlasa, ko‘rsatilgan muddat va cache policy uyg‘un bo‘lishi lozim. SDK Retry-After bilan o‘z exponential backoff qiymatidan kattarog‘ini tanlashi, lekin operator belgilagan maksimal kutishdan oshmasligi mumkin.
Brauzer yoki mobil mijoz uzoq kutishda yopilishi mumkin, shuning uchun server holatni tekshirish identifikatori berishi mumkin. Mijoz keyingi ishga tushishda deadline va foydalanuvchi niyatini qayta baholab, eskirgan amalni avtomatik takrorlamaydi.
Bog‘liq tushunchalar
HTTP, 429 Too Many Requests, 503 Service Unavailable, Rate limiting, Backoff, Jitter, Idempotency