HTTP Response និង Status Code

មាតិកា

1. រូបរាងរបស់ Response
2. Status Code៖ ក្រុមទាំងប្រាំ
3. 2xx៖ ជោគជ័យ
4. 3xx៖ Redirect
5. 4xx៖ Client ធ្វើខុស
6. 5xx៖ Server ធ្វើខុស
7. Response Header និង Content-Type
8. ការអាន Response ពិតមួយ
9. សាកល្បងដោយខ្លួនឯង

1. រូបរាងរបស់ Response

Server អាន request របស់អ្នក សម្រេចថាត្រូវផ្ញើអ្វីត្រឡប់មកវិញ ហើយឆ្លើយតប។ Response មួយមានរូបរាងស្ទើរតែដូចគ្នានឹង request ដែរ៖

HTTP/1.1 200 OK                          ← status line
Content-Type: text/html; charset=utf-8   ← headers
Content-Length: 1543
Cache-Control: max-age=600
                                         ← blank line
<!DOCTYPE html>                          ← body
<html>
  <head><title>Dara Sok</title> …

ភាពខុសគ្នាតែមួយគត់គឺបន្ទាត់ទីមួយ។ ជំនួសឲ្យ method និង path វាមាន status line៖

HTTP/1.1  200  OK
   │       │    └── reason phrase: a human-readable label
   │       └─────── status code: the number that matters
   └─────────────── HTTP version

Status code គឺជាលេខបីខ្ទង់ ដែលប្រាប់ client ថាអ្វីៗដំណើរការយ៉ាងដូចម្តេច។ កម្មវិធីមើលតែលេខប៉ុណ្ណោះ ហើយពាក្យនៅពីក្រោយវាគឺសម្រាប់តែមនុស្សទេ (HTTP/2 មិនផ្ញើពាក្យទាំងនោះផងទេ)។

2. Status Code៖ ក្រុមទាំងប្រាំ

ខ្ទង់ទីមួយ ប្រាប់អ្នកពីក្រុម។ រៀនក្រុមទាំងប្រាំនេះ ហើយអ្នកអាចយល់ពីលេខណាមួយក៏បាន សូម្បីតែលេខដែលអ្នកមិនដែលឃើញ៖

អ្នកស្ទើរតែមិនដែលឃើញលេខ 1xx ដោយផ្ទាល់ទេ។ ក្រុមបួនផ្សេងទៀតមាននៅគ្រប់ទីកន្លែង។ ការបែងចែកដែលមានប្រយោជន៍បំផុតគឺរវាង 4xx និង 5xx៖ វាប្រាប់អ្នកថា error មួយ ជាកំហុសរបស់អ្នកណា ហើយដូច្នេះត្រូវរកមើលនៅកន្លែងណា។ 4xx មានន័យថាត្រូវមើល request ហើយ 5xx មានន័យថាត្រូវមើល log របស់ server។

3. 2xx៖ ជោគជ័យ

200 គឺជាលេខដែលទូទៅបំផុតនៅលើ web ឆ្ងាយណាស់។ នៅពេលអ្នកបង្កើត API នៅក្នុង NestJS Crash Course អ្នកនឹងត្រឡប់ 201 ពី endpoint POST និង 200 ពី endpoint ផ្សេងទៀតភាគច្រើន — NestJS ធ្វើរឿងនេះជំនួសអ្នកតាមលំនាំដើម។

4. 3xx៖ Redirect

Redirect មួយនិយាយថា៖ «អ្វីដែលអ្នកចង់បានមិននៅទីនេះទេ — សូមទៅ URL ផ្សេងនេះវិញ»។ អាសយដ្ឋានថ្មីនៅក្នុង header Location ហើយ browser ធ្វើតាមវា ដោយស្វ័យប្រវត្តិ — អ្នកគ្រាន់តែឃើញ address bar ផ្លាស់ប្តូរ។

HTTP/1.1 301 Moved Permanently
Location: https://dara-sok.github.io/my-site/

អ្នកបានធ្វើឲ្យកើត redirect ដោយមិនបានកត់សម្គាល់៖

• ការវាយ http:// នៅលើ site ដែលធ្វើតែ HTTPS → 301 ទៅ https://។
• ការចូលមើល /my-site ដោយគ្មាន slash នៅខាងចុងនៅលើ GitHub Pages → 301 ទៅ /my-site/ ព្រោះវាជា folder មួយ។
• ការបើកទំព័រដែលតម្រូវឲ្យអ្នក log in → 302 ទៅទំព័រ login ដែលនឹង redirect អ្នកត្រឡប់មកវិញនៅពេលក្រោយ។ Tutorial Keycloak ត្រូវបានកសាងឡើងលើលំនាំនេះពិតប្រាកដ។

304 គឺខុសពីគេ៖ វាមិនមែនជា redirect ពិតប្រាកដទេ ប៉ុន្តែជា «អ្នកមានវារួចហើយ» ហើយវាជាគន្លឹះនៃជំពូក caching។

5. 4xx៖ Client ធ្វើខុស

គូដែលធ្វើឲ្យអ្នកគ្រប់គ្នាច្រឡំគឺ 401 ធៀបនឹង 403។ សូមស្រមៃមើលអគារមួយដែលមានសន្តិសុខ៖

• 401៖ «ខ្ញុំមិនស្គាល់អ្នកទេ។ សូមបង្ហាញអត្តសញ្ញាណប័ណ្ណរបស់អ្នក។» → Log in ហើយសាកល្បងម្តងទៀត។
• 403៖ «ខ្ញុំបានឃើញអត្តសញ្ញាណប័ណ្ណរបស់អ្នកហើយ។ អ្នកមិនធ្វើការនៅជាន់នេះទេ។» → ការ log in ម្តងទៀតនឹងមិនជួយទេ អ្នកត្រូវការសិទ្ធិផ្សេង។

(ឈ្មោះ «Unauthorized» សម្រាប់ 401 គឺជាកំហុសចាស់មួយ — តាមពិតវាមានន័យថា unauthenticated។ Tutorial Keycloak ពន្យល់ពីភាពខុសគ្នារវាង authentication និង authorization។)

404 គឺជាលេខដែលអ្នកគ្រប់គ្នាស្គាល់។ វាគ្រាន់តែមានន័យថា server គ្មានអ្វីនៅ path នោះទេ៖ ការវាយខុស ទំព័រដែលត្រូវបានលុប ឬ — នៅលើ GitHub Pages — relative link ដែលចង្អុលទៅ folder ខុស ដូចជាឧទាហរណ៍ /about.html ពីជំពូកទី 2។

429 សំខាន់ភ្លាមៗនៅពេលអ្នកហៅ API របស់អ្នកដទៃ។ សេវាកម្មជាច្រើនកំណត់ចំនួន request ដែលអ្នកអាចធ្វើក្នុងមួយនាទី។ Response 429 ជារឿយៗមាន header Retry-After ដែលប្រាប់ថាត្រូវរង់ចាំប៉ុន្មានវិនាទី។

6. 5xx៖ Server ធ្វើខុស

ដើម្បីយល់ពី 502 និង 504 អ្នកត្រូវការគំនិតមួយទៀត៖ នៅលើ website ពិតៗ request របស់អ្នកជារឿយៗមិនទៅដល់កម្មវិធីដោយផ្ទាល់ទេ។ វាទៅដល់ proxy ឬ load balancer មុន — server ដែលការងារតែមួយគត់របស់វាគឺបញ្ជូន request បន្តទៅ app server នៅខាងក្រោយវា៖

 Browser ──▶ Proxy (nginx, a CDN, a load balancer) ──▶ Your app
              └── 502 if the app's reply is broken
              └── 504 if the app takes too long
              └── 503 if no app is available

ដូច្នេះ 502 ជារឿយៗមានន័យថា «កម្មវិធីរបស់អ្នក crash ឬមិនកំពុងដំណើរការ» ទោះបីជាទំព័រ error មកពី proxy ក៏ដោយ។ នៅពេលអ្នក deploy អ្វីមួយនៅក្នុង tutorial Docker ឬ Cloud+ ហើយឃើញ 502 សូមពិនិត្យថាតើ container របស់អ្នកពិតជាកំពុងដំណើរការឬអត់។

ច្បាប់មួយដែលគួរចងចាំនៅពេលអ្នកបង្កើត API៖ 500 តែងតែជា bug។ បើអ្នកប្រើប្រាស់ផ្ញើទិន្នន័យមិនត្រឹមត្រូវ នោះគឺជា 400 ឬ 422 — ប្រាប់ពួកគេថាអ្វីខុស។ 500 គួរកើតឡើងតែនៅពេលមានអ្វីមួយដែលមិនបានរំពឹងទុកខូចនៅខាងអ្នកប៉ុណ្ណោះ។

7. Response Header និង Content-Type

Response ក៏មាន header ដែរ។ ខ្លះអ្នកនឹងជួបនៅក្នុងជំពូកក្រោយៗ (Set-Cookie នៅក្នុងជំពូកទី 8, Cache-Control និង ETag នៅក្នុងជំពូកទី 9)។ Header ដែលសំខាន់បំផុតឥឡូវនេះគឺ Content-Type៖ វាប្រាប់ client ថា body ជា ទិន្នន័យប្រភេទអ្វី។ Browser មិនមើល extension របស់ file នៅក្នុង URL ទេ វាទុកចិត្តលើ header នេះ។

ស្លាកទាំងនេះត្រូវបានហៅថា MIME type (ឬ media type)។ បើ server ផ្ញើស្លាកខុស រឿងចម្លែកៗនឹងកើតឡើង៖ ទំព័រ HTML ដែលបង្ហាញជាកូដឆៅ stylesheet ដែលត្រូវបានមិនអើពើ ឬទំព័រដែលទាញយកជំនួសឲ្យការបើក។

charset=utf-8 នោះក៏សំខាន់ដែរ៖ វាប្រាប់ browser ពីរបៀបបំប្លែង byte ត្រឡប់ទៅជាតួអក្សរវិញ។ បើគ្មានវាទេ អក្សរខ្មែរអាចប្រែក្លាយជាសំរាម ដូចជា ក។

8. ការអាន Response ពិតមួយ

សុំ header ពី site GitHub Pages របស់អ្នក៖

curl -I https://dara-sok.github.io/my-site/

អ្នកនឹងទទួលបានអ្វីមួយដូចនេះ (កាត់ឲ្យខ្លី)៖

HTTP/2 200
server: GitHub.com
content-type: text/html; charset=utf-8
last-modified: Mon, 14 Sep 2026 08:12:45 GMT
etag: "6aa7ac7d-60b"
cache-control: max-age=600
date: Thu, 01 Oct 2026 03:20:11 GMT
x-cache: HIT
content-length: 1547

អ្នកអាចអានវាភាគច្រើនបានរួចហើយ៖

• HTTP/2 200 — ជោគជ័យ តាម HTTP/2។
• server — software មួយណាដែលបានឆ្លើយតប។ មិនមែនគ្រប់ site ទាំងអស់ផ្ញើវាទេ។
• content-type — ទំព័រ HTML មួយជា UTF-8។
• last-modified — ពេលដែល file បានផ្លាស់ប្តូរចុងក្រោយ៖ ការ merge ចុងក្រោយរបស់អ្នកទៅ main។
• content-length — ទំហំរបស់ body គិតជា byte។
• etag, cache-control, x-cache — caching។ ពួកវាមានជំពូកមួយទាំងមូលសម្រាប់ខ្លួនឯង។

Header ដែលចាប់ផ្តើមដោយ x- គឺជា header ផ្ទាល់ខ្លួន ដែលបង្កើតឡើងដោយអ្នកណាដែលដំណើរការ server។ អ្នកនឹងឃើញវាច្រើន ស្វែងរកឈ្មោះវាបើអ្នកចង់ដឹង។

9. សាកល្បងដោយខ្លួនឯង

1. ប្រមូល status code។ រត់ command នីមួយៗខាងក្រោម ហើយកត់ចំណាំ status line។ -I បង្ហាញតែ header ប៉ុណ្ណោះ៖

   curl -I https://dara-sok.github.io/my-site/
   curl -I https://dara-sok.github.io/my-site/no-such-page
   curl -I http://dara-sok.github.io/my-site/
   curl -I https://dara-sok.github.io/my-site
   

   Copy

   ពីរចុងក្រោយគឺជា redirect។ តើ header location និយាយអ្វីនៅក្នុងនីមួយៗ?

2. ធ្វើតាម redirect។ curl មិនធ្វើតាម redirect ទេ លុះត្រាតែអ្នកសុំ។ រត់ curl -IL http://dara-sok.github.io/my-site (-L មានន័យថា «ធ្វើតាម»)។ តើអ្នកទទួលបាន response ប៉ុន្មាន មុនពេល 200?

3. បង្កើតលេខណាក៏បានតាមចិត្ត។ httpbin ត្រឡប់ status ណាក៏ដោយដែលអ្នកសុំ៖

   curl -I https://httpbin.org/status/404
   curl -I https://httpbin.org/status/503
   

   Copy

4. រកវានៅក្នុង browser។ បើក DevTools → Network នៅលើ site ដែលមមាញឹកមួយ ហើយបន្ថែម column Status បើវាមិនទាន់មាន។ តើអ្នកអាចរកឃើញ 304, 301 ឬ 204 ទេ? បន្ទាប់មកចូលមើលទំព័រដែលមិនមាននៅលើ site ណាមួយ ហើយរក 404 របស់វា។

Browser មាន response របស់វាហើយ — ជាធម្មតាជាទំព័រ HTML មួយ។ នៅក្នុងជំពូកបន្ទាប់ យើងនឹងមើលពីរបៀបដែលវាប្រែក្លាយអក្សរនោះទៅជាអ្វីដែលអ្នកឃើញនៅលើអេក្រង់។