HTTP amaliyoti: DevTools bilan tahlil

HTTP asoslari darsida so’rov va javob nazariy jihatdan qanday ishlashini ko’rdik. Endi shu bilimni o’z brauzeringizda sinab ko’ramiz. Bu dars o’qish uchun emas, yoningizda brauzer ochiq holda bajarish uchun yozilgan.

Brauzerda istalgan sahifani oching, DevTools’ni F12 (yoki macOS’da Cmd + Option + I) bilan ishga tushiring va Network panelini tanlang.

Nega aynan Network paneli

Web dasturchi ish vaqtining katta qismini “nega ishlamayapti?” degan savolga sarflaydi. Bu savolning javobi deyarli har doim uch joydan birida bo’ladi: so’rov umuman yuborilmagan, server kutilmagan javob qaytargan yoki frontend javobni noto’g’ri o’qigan.

Network paneli aynan shu uchtasini ajratib beradi. U yerda har bir so’rovning manzili, metodi, holat kodi, hajmi va vaqti ko’rinadi. Taxmin qilish o’rniga dalil olasiz — bu debugging darsidagi asosiy tamoyilning web tizimidagi ko’rinishi.

Laboratoriya tartibi

Quyidagi qadamlarni ketma-ket bajaring. Har qadamda ko’rganingizni qisqa yozib boring — keyin taqqoslash uchun asqotadi.

1. Network ochiq holda sahifani yangilang (F5).
2. Ro’yxatning eng yuqorisidagi asosiy HTML so’rovini tanlang.
3. Metod (GET) va holat kodini (200) ko’ring.
4. Headers bo’limida URL, Content-Type va cache qoidalarini toping.
5. Ro’yxatni Fetch/XHR bo’yicha filtrlang — bu JavaScript yuborgan so’rovlar.
6. JSON qaytaradigan so’rovni tanlab, Response yoki Previewni oching.
7. Formani yuborib, POST so’rovining Payload bo’limini ko’ring.

Ustunlarni o’qish

So’rovlar ro’yxatidagi har ustun aniq savolga javob beradi:

Ustun	Nimani ko’rsatadi	Qachon muhim
Name	So’rov manzilining oxirgi qismi	Qaysi endpoint chaqirilganini topish
Status	HTTP holat kodi	Xato server tomondami yoki mijozdami
Type	Javob turi (document, xhr, script)	So’rovni kim yuborgan
Size	Yuklangan hajm	Sahifa sekinligi sababi
Time	So’rov necha millisekund davom etgani	Sekin endpointni aniqlash

Size ustunida (disk cache) yoki (memory cache) yozuvi ko’rinsa, fayl tarmoqdan umuman yuklanmagan — u brauzerda saqlangan. Bu cache va CDN darsida ko’rgan mexanizmning amaldagi isboti.

Headerlarni tushunish

Header — so’rov va javob bilan birga ketadigan qo’shimcha ma’lumot. Ularning hammasini yodlash shart emas, lekin bir nechtasi kundalik ishda tez-tez uchraydi:

Header	Kim yuboradi	Ma’nosi
Content-Type	Ikkalasi	Body qaysi formatda (application/json)
Accept	Mijoz	Mijoz qaysi formatni kutmoqda
Authorization	Mijoz	Kim so’rayapti (token yoki kalit)
Cache-Control	Server	Javobni qancha vaqt saqlash mumkin
Set-Cookie	Server	Brauzerga cookie o’rnatish buyrug’i

Content-Type: application/json body JSON ekanini bildiradi. Agar server JSON kutayotgan bo’lsa-yu, siz oddiy matn yuborsangiz, 400 xatosi kelishi mumkin — sabab kodda emas, headerda bo’lishi ham mumkin.

Holat kodlarini amalda ajratish

Nazariyada 404 “topilmadi” degani. Amalda esa savol boshqacha: kim aybdor? Quyidagi jadval shu savolga javob beradi:

Kod	Ma’nosi	Kim tuzatadi
200, 201	Muvaffaqiyat	—
400	So’rov noto’g’ri tuzilgan	Frontend
401	Kirish qilinmagan	Frontend (login)
403	Tanilgan, lekin ruxsat yo’q	Backend (ruxsatlar)
404	Manzil topilmadi	Frontend (URL) yoki backend (route)
500	Server ichida xato	Backend

401 va 403 farqi boshlovchilarni ko’p chalkashtiradi. Sodda qilib aytganda: 401 — “siz kimsiz?”, 403 — “sizni tanidim, lekin bunga ruxsatingiz yo’q”. Bu farq cookie va autentifikatsiya darsida batafsil ochilgan.

CORSni tushunish

Brauzer boshqa origin’dagi APIga so’rov yuborayotganda server ruxsatini tekshiradi. Origin — protokol, domen va portning birikmasi: https://example.com va https://api.example.com — ikki xil origin.

Ayrim POST so’rovlari, maxsus header yoki boshqa murakkab holatlarda brauzer asosiy so’rovdan avval OPTIONS metodi bilan preflight so’rov yuboradi. Bu “menga shunday so’rov yuborishga ruxsat bormi?” degan oldindan savol.

Network panelida CORS muammosini tanish oson: OPTIONS so’rovi ko’rinadi, lekin asosiy so’rov yo umuman yo’q, yo Console’da blocked by CORS policy xabari chiqadi.

Amaliy mashq

Ochiq, bepul API bilan ishlab ko’ring. Brauzer Console’ida quyidagi kodni ishga tushiring va Network panelida nima sodir bo’lishini kuzating:

fetch('https://api.github.com/users/github')
  .then((javob) => {
    console.log('Holat kodi:', javob.status);
    return javob.json();
  })
  .then((malumot) => console.log(malumot.name, malumot.public_repos));

Keyin quyidagilarni sinang va har safar Network’da nima o’zgarishini yozing:

1. Manzildagi github o’rniga mavjud bo’lmagan foydalanuvchi nomini yozing — qaysi holat kodi keladi?
2. URL’ni ataylab buzing (api.github.comX) — so’rov umuman ketadimi?
3. Slow 3G tarmoq rejimini yoqib, Time ustuni qanday o’zgarishini ko’ring.

Muammoni qatlamlarga ajratish

So’rov ishlamasa, tartib bilan besh savol bering. Har savol muammoni bir qatlamga toraytiradi:

1. So’rov yuborildimi? Network’da ko’rinmasa — muammo JavaScriptda: hodisa ulanmagan yoki kod xatosi bor.
2. Qaysi URLga ketdi? Manzil noto’g’ri bo’lsa — frontenddagi konfiguratsiya.
3. Holat kodi nima? 4xx mijozda, 5xx serverda ishora qiladi.
4. Javob qanday? Responseda kutilgan maydonlar bormi?
5. Frontend uni qanday o’qidi? Javob to’g’ri kelib, ekran bo’sh bo’lsa — muammo render yoki state’da.

Sekin so’rovni topish

Sahifa sekin ochilsa, aybdorni topish uchun Time ustuni bo’yicha saralang. Eng uzoq davom etgan so’rovni tanlab, Timing bo’limini oching. U yerda vaqt qanday taqsimlanganini ko’rasiz:

Bosqich	Ma’nosi	Sekin bo’lsa sabab
Queueing	So’rov navbatda kutdi	Bir vaqtda juda ko’p so’rov
DNS Lookup	Domen IP manzilga o’girildi	DNS sozlamasi yoki birinchi tashrif
Waiting (TTFB)	Server javob boshlagunga qadar	Server yoki baza sekin
Content Download	Javob yuklab olindi	Fayl hajmi katta

Bu taqsimot muhim savolga javob beradi: muammo tarmoqdami yoki serverdami? Agar Waiting (TTFB) uzoq bo’lsa, backend yoki ma’lumotlar bazasi sekin ishlayotgan bo’lishi mumkin — rasmni siqish bu holda yordam bermaydi. Aksincha, Content Download uzoq bo’lsa, muammo fayl hajmida va uni siqish yoki CDN orqali hal qilish mumkin.

Sahifa yuklanishini turli tarmoq tezligida sinash uchun Network panelidagi No throttling ro’yxatidan Slow 3G ni tanlang. Foydalanuvchilaringizning bir qismi aynan shunday sharoitda ishlashini yodda tuting.

Qisqacha xulosa

• Network paneli so’rovni taxmin qilish o’rniga ko’rish imkonini beradi.
• Status ustuni muammo mijozdami yoki serverdami — birinchi ishorani beradi.
• Content-Type va Authorization — eng ko’p uchraydigan headerlar.
• 401 “kim siz?”, 403 “ruxsat yo’q” — ikkisi turli muammo.
• CORS muammosi serverda hal qilinadi, brauzerda emas.
• Har xatoda besh savolni tartib bilan bering: yuborildimi, qayerga, qaysi kod, qanday javob, frontend qanday o’qidi.

Keyingi darsda web testing — kod ishlaydi degan ishonchni qo’lda taxmindan takrorlanadigan tekshiruvga aylantiramiz.