Status code — ตัวเลขที่บอกว่าใครผิด

1 · ตัวเลขสามหลักคือ "หัวข้อ" ของคำตอบ ไม่ใช่ของประดับ

มือใหม่เกือบทุกคนคิดแบบนี้ตอนเริ่ม: "ก็ตอบ JSON ไปสิ ในนั้นมี field error อยู่แล้ว ใครอยากรู้ก็อ่านเอา" — ฟังดูสมเหตุสมผล จนกระทั่งนึกออกว่า คนที่อ่านคำตอบของคุณไม่ได้มีแค่โปรแกรมเมอร์คนเดียว

   handler ของคุณตอบกลับไป
        │
        ├─▶ client library   ดู "ตัวเลข" ก่อนเสมอ แล้วค่อยตัดสินใจว่าจะแกะ body ไหม
        │
        ├─▶ เบราว์เซอร์       ตัดสินใจ cache / redirect / ถาม username จาก "ตัวเลข"
        │
        ├─▶ proxy · load balancer  นับ error rate จาก "ตัวเลข" (มันไม่แกะ body ให้คุณ)
        │
        ├─▶ monitoring / alert    กราฟ 4xx / 5xx ที่ทีม on-call จ้องอยู่ = "ตัวเลข" ล้วน
        │
        └─▶ คน                คนเดียวในลิสต์นี้ที่อ่าน body เป็น

(proxy กับ load balancer คือเครื่องที่ยืนคั่นกลางระหว่าง client กับ server ของเรา คอยส่งต่อ request — ยังไม่ต้องรู้ลึกกว่านี้ในบทนี้)
ทุกคนในภาพยกเว้นบรรทัดสุดท้าย ไม่รู้จัก field error ของคุณเลย พวกเขารู้จักแค่ตัวเลข เพราะตัวเลขคือส่วนเดียวของคำตอบที่มีความหมายมาตรฐาน ไม่ว่าจะเขียนด้วยภาษาอะไร ทีมไหน บริษัทไหน
ดังนั้นกฎข้อแรกของบทนี้คือ: ตัวเลขคือคำตอบที่เครื่องอ่าน · body คือคำตอบที่คนอ่าน — ต้องพูดตรงกันเสมอ

2 · อ่านหลักแรกให้เป็น แล้วที่เหลือเดาได้ครึ่งทาง

status code มี 3 หลัก แต่หลักแรกหลักเดียวบอกได้แล้วว่าเรื่องนี้จบยังไง สองหลักหลังเป็นแค่รายละเอียดว่า "จบแบบไหน"

ลองตัวอย่างเดียวกันสองแบบ: ผู้ใช้สมัครสมาชิกด้วยอีเมลที่มีคนใช้แล้ว
ถ้าคุณตอบ 409 Conflict → กราฟ 4xx ขยับ ทีม server มองแล้วรู้ว่า "คนใช้กรอกอีเมลซ้ำเยอะขึ้น" ซึ่งอาจแปลว่าหน้าเว็บสื่อสารไม่ดี — ไม่ใช่ระบบพัง
ถ้าคุณตอบ 500 → กราฟ 5xx พุ่ง alert ดัง คนถูกปลุกมาไล่ดู log แล้วพบว่า "ทุกอย่างปกติ แค่อีเมลซ้ำ" — เสียแรงคนทั้งกะ และที่แย่กว่าคือ ครั้งหน้าที่ 5xx พุ่งจริง ๆ จะไม่มีใครเชื่อกราฟนั้นอีก

3 · เก้าตัวที่ต้องคล่อง — รันจริงทั้งชุดในคราวเดียว

ผมเขียน API เล็ก ๆ ด้วย net/http ตัวเดียว (สมัครสมาชิก + ลบผู้ใช้ที่ให้เฉพาะแอดมิน) แล้วยิงมันด้วย client จริงผ่าน httptest.NewServer (ตัวช่วยที่ติดมากับ Go: เปิด server ชั่วคราวบนพอร์ตสุ่มให้ยิงทดสอบ แล้วปิดทิ้ง — หัวข้อ 10 จะใช้อีกที) — ทุกบรรทัดข้างล่างนี้คือ output ที่ออกมาจริง ไม่ได้พิมพ์เอง:

วิธีอ่าน: บรรทัดที่ขึ้นต้นด้วย $ คือคำขอที่ยิงเข้าไป (เขียนย่อ ๆ ให้อ่านง่าย ไม่ใช่คำสั่งที่พิมพ์ในเทอร์มินัลได้) · บรรทัดที่ขึ้นต้นด้วย -> คือคำตอบที่ได้กลับมา

$ POST /users  body={"email":"new@example.com"}
  -> 201 Created   Location: /users/2
     {"id":"2","email":"new@example.com"}
$ POST /users  body={"email":"new@example.com"}      # อีเมลเดิมซ้ำ
  -> 409 Conflict
     {"error":"email already registered"}
$ POST /users  body={"email":"ไม่ใช่อีเมล"}
  -> 422 Unprocessable Entity
     {"error":"email is not a valid address"}
$ POST /users  body={"email":                        # JSON ขาดครึ่ง
  -> 400 Bad Request
     {"error":"invalid json body"}
$ DELETE /users/1                                # ไม่ส่ง token
  -> 401 Unauthorized   WWW-Authenticate: Bearer realm="api"
     {"error":"missing token"}
$ DELETE /users/1  Authorization: Bearer user-token
  -> 403 Forbidden
     {"error":"admin only"}
$ DELETE /users/1  Authorization: Bearer admin-token
  -> 204 No Content
                                                 # ← body ว่างจริง ๆ
$ DELETE /users/1  Authorization: Bearer admin-token   # ลบซ้ำ ของหายไปแล้ว
  -> 404 Not Found
     {"error":"user not found"}
$ PATCH /users/1  Authorization: Bearer admin-token
  -> 405 Method Not Allowed
     Method Not Allowed                          # ← อันนี้ Go ตอบเอง ไม่ได้เขียน

สังเกตว่า request แทบเหมือนกันหมด — DELETE /users/1 ตัวเดียวกัน ได้ 401, 403, 204 และ 404 ตามลำดับ เพราะสิ่งที่เปลี่ยนคือบริบท: ใครถาม · ถามตอนไหน
นี่คือเหตุผลที่ status code ไม่ใช่ "ตารางที่ต้องท่อง" แต่เป็นคำถามที่ต้องตอบให้ตรง

ผลรันข้างบนมี 422 กับ 405 แถมมาด้วย (สองตัวนี้พูดถึงในหัวข้อ 6 และ 8) — แต่เก้าตัวที่ต้องคล่องจริง ๆ คือตารางข้างล่างนี้ ยึดตารางนี้เป็นหลัก

4 · ฝั่งสำเร็จ: 200 vs 201 vs 204 ต่างกันที่ "มีอะไรกลับไปไหม"

ทั้งสามตัวแปลว่าสำเร็จเหมือนกัน คำถามที่ใช้แยกมีข้อเดียว: หลังทำเสร็จ มีของส่งกลับหรือเปล่า และของนั้นเพิ่งเกิดใหม่ไหม

Location ในคำตอบ 201 คือการบอกว่า "ของที่คุณเพิ่งสร้าง ไปหาได้ที่ URL นี้" ผมรันแล้วได้ Location: /users/2 จริงตามผลในหัวข้อ 3 — client ที่ฉลาดหน่อยจะเอาไปใช้ต่อได้เลยโดยไม่ต้องเดาว่า id อยู่ตรงไหนใน body

ส่วน 204 มีข้อบังคับที่ทำให้คนใหม่งงบ่อยที่สุด: มันห้ามมี body ไม่ใช่ "ไม่ควร" แต่ "ห้าม" ระดับ protocol — แล้วถ้าเราเผลอเขียน body ตามไปล่ะ?

mux.HandleFunc("GET /x", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusNoContent)
    n, err := w.Write([]byte(`{"message":"deleted"}`))
    fmt.Printf("[server] w.Write -> n=%d err=%v\n", n, err)
})

[server] w.Write -> n=0 err=http: request method or response status code does not allow body
[client] status="204 No Content" ContentLength=0

5 · 401 vs 403 — "ไม่รู้ว่าคุณเป็นใคร" กับ "รู้แล้ว แต่คุณทำไม่ได้"

คู่นี้สลับกันบ่อยที่สุดในโลก ส่วนหนึ่งเพราะชื่อมันหลอก: 401 ชื่อ Unauthorized แต่ความหมายจริงคือ "unauthenticated" = ยังไม่ได้พิสูจน์ตัวตน ส่วน 403 Forbidden ต่างหากที่แปลว่า "ไม่ได้รับอนุญาต"

$ DELETE /users/1        # ไม่ส่ง token
-> 401 Unauthorized
   WWW-Authenticate: Bearer realm="api"
   {"error":"missing token"}

$ DELETE /users/1
  Authorization: Bearer user-token
-> 403 Forbidden
   {"error":"admin only"}

ทำไมต้องแยก? เพราะ frontend ทำคนละอย่างกับสองรหัสนี้
เจอ 401 → เด้งไปหน้า login (หรือใช้ refresh token ต่ออายุแล้วยิงซ้ำ)
เจอ 403 → ต้องขึ้นข้อความ "คุณไม่มีสิทธิ์" ห้ามเด้งไป login เพราะผู้ใช้ล็อกอินอยู่แล้ว การเด้งไปหน้า login จะกลายเป็นลูปที่ผู้ใช้ออกไม่ได้
ตอบสลับสองตัวนี้ = frontend ทำงานผิด ทั้งที่โค้ด frontend ถูก

6 · 400 vs 422 vs 409 — ผิดที่รูปแบบ · ผิดที่ค่า · ผิดที่จังหวะ

ทั้งสามตัวเป็น 4xx เหมือนกัน (client ต้องแก้) ต่างกันที่ คำขอเดินมาได้ไกลแค่ไหนก่อนตาย ผมเรียง handler ให้ตรวจตามลำดับนี้เป๊ะ ๆ แล้วรันจริง:

  request เข้ามา
      │
      ├─ แกะ JSON ไม่ออกเลย ─────────────▶ 400  {"error":"invalid json body"}
      │   (วงเล็บไม่ปิด · ไม่ใช่ JSON)
      │
      ├─ แกะออกแล้ว แต่ค่าไม่ผ่านกฎ ─────▶ 422  {"error":"email is not a valid address"}
      │   (อีเมลไม่มี @ · อายุติดลบ)
      │
      ├─ ค่าถูกทุกอย่าง แต่ชนของที่มีอยู่ ──▶ 409  {"error":"email already registered"}
      │   (อีเมลซ้ำ · ลบของที่ถูกลบไปแล้ว)
      │
      └─ ผ่านหมด ───────────────────────▶ 201  + Location

โครง if ที่เรียงแบบนี้ก็คือ guard clause ตัวเดียวกับที่ฝึกใน บทเรียน 4: ตรวจเคสที่ผิดแล้ว return ทันที เรียงจากผิดหยาบไปผิดละเอียด เส้นทางสำเร็จจึงเหลืออยู่ล่างสุดโดยไม่มี else สักตัว

[GIN-debug] [WARNING] Headers were already written. Wanted to override status code 400 with 422
STATUS=400

7 · กับดักที่แพงที่สุด: ตอบ 200 พร้อม {"error":"not found"}

นี่คือโค้ดที่เจอในโปรเจกต์จริงบ่อยมาก และมักเกิดจากความหวังดี — "ตอบ 200 ไว้ก่อน เดี๋ยว frontend อ่าน field error เอง จะได้ไม่ต้องมี try/catch"
ผมเขียน client แบบที่ทุกคนเขียนกัน แล้วยิงใส่ server สองตัวที่ body เหมือนกันเป๊ะ ต่างกันแค่ตัวเลข:

func fetchUser(url string) (string, error) {
    resp, err := http.Get(url)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    if resp.StatusCode >= 400 {                    // ← ด่านเดียวที่ client มี
        return "", fmt.Errorf("api error: %s", resp.Status)
    }
    b, _ := io.ReadAll(resp.Body)
    var u struct {
        ID   string `json:"id"`
        Name string `json:"name"`
    }
    json.Unmarshal(b, &u)
    return fmt.Sprintf("โหลดสำเร็จ: id=%q name=%q", u.ID, u.Name), nil
}

=== A: server ตอบ 200 + {"error":"user not found"} ===
err = <nil>
out = โหลดสำเร็จ: id="" name=""

=== B: server ตอบ 404 + {"error":"user not found"} ===
err = api error: 404 Not Found
out =

ความเสียหายไม่ได้จบแค่ client ตัวเดียว ผมนับ error rate แบบเดียวกับที่ monitoring ทำ (คือดูแค่หลักแรกของ status) ได้ผลนี้:

A(200) -> StatusCode=200  class=2xx  นับเป็น error? false
B(404) -> StatusCode=404  class=4xx  นับเป็น error? true

8 · status ที่คุณไม่ได้สั่ง แต่มันตอบไปแล้ว

ก่อนจะโทษตัวเองว่าเขียน status ผิด ต้องรู้ก่อนว่าไม่ใช่ทุกตัวเลขที่ออกจาก handler ของคุณ บางตัว router ตอบไปตั้งแต่ก่อนถึงโค้ดที่คุณเขียนแล้ว — และของแต่ละเจ้าไม่เหมือนกันด้วย

$ curl -s -i -X POST http://127.0.0.1:8765/hello
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff

Method Not Allowed

=== default HandleMethodNotAllowed = false ===
GET    /only-post   -> 404  body=404 page not found
DELETE /users/42    -> 404  body=404 page not found

=== ตั้ง r.HandleMethodNotAllowed = true ===
GET    /only-post   -> 405  Allow="POST, PUT"

ทั้งสองผลรันจริงบน Go 1.26.5 / gin v1.12.0 และเป็นเรื่องที่ต้องรู้ตอน debug: เจอ 404 ทั้งที่แน่ใจว่าเขียน route ไว้แล้ว — คำถามแรกที่ต้องถามคือ "method ตรงไหม" ไม่ใช่ "path พิมพ์ผิดหรือเปล่า"

อีกสองตัวที่โผล่มาเองบ่อย:

• 307 Temporary Redirect — ลงทะเบียน pattern ไว้เป็น /files/ (มี / ปิดท้าย = คลุมทุก path ที่ขึ้นต้นด้วย /files/) แล้วมีคนยิง /files เฉย ๆ ไม่มีสแลช — ServeMux จะ redirect ให้เอง (Location: /files/) · ตำราเก่าเขียนว่า 301 แต่ผลรันบน Go 1.26.5 คือ 307
• ไม่มี status เลย — handler ที่ panic (ฟังก์ชันเจอเหตุร้ายจนไปต่อไม่ได้ เลยเลิกกลางคันแล้วไล่ย้อนออกมาทีละชั้น — ใน server ของ net/http ไม่ได้ล้มทั้งโปรแกรม แต่ตัด connection เส้นนั้นทิ้ง แล้วรับ request เส้นอื่นต่อตามปกติ) โดยไม่มีใครจับ ผมรันสองเส้นทางเทียบกัน: /users/1 คือ handler ที่ เขียน 500 เอง · /boom คือ handler ที่ panic เฉย ๆ

  GET /users/1 -> 500 Internal Server Error  body="{\"error\":\"internal error\"}\n"
  GET /boom    -> client error: Get "http://127.0.0.1:55237/boom": EOF

  EOF ไม่ใช่ status code — มันคือ "สายถูกตัดกลางคัน" (net/http เจอ panic แล้วปิด connection ทิ้ง ไม่ส่งตัวเลขอะไรกลับมาเลย) ซึ่งแย่กว่า 500 เพราะ client แยกไม่ออกว่าเป็นเน็ตหลุดหรือ server พัง

  ฝั่ง server ไม่ได้เงียบนะ — มันพิมพ์ http: panic serving 127.0.0.1:55462: explode พร้อม stack trace (รายการว่าโค้ดวิ่งผ่านฟังก์ชันไหนมาบ้างก่อนพัง) ยาว ๆ ลง log ให้ แต่ client ไม่มีทางเห็นบรรทัดนั้น

  Gin ต่างออกไป: gin.Default() มี Recovery (ตัวดัก panic แล้วตอบ 500 กลับไปแทนที่จะตัดสายทิ้งเงียบ ๆ) ติดมาให้ จึงตอบ status=500 แทน · ส่วน gin.New() ที่ไม่มี Recovery ได้ curl status=000 (คือ curl ไม่ได้รับ status เลย = อาการเดียวกับ EOF ข้างบน)
  ทั้งสองแบบ server ไม่ได้ตาย — ยิงเส้นทางอื่นต่อก็ยังตอบปกติ · สิ่งที่ Recovery ซื้อให้คุณจึงไม่ใช่ "ไม่ให้ server ล้ม" แต่คือ เปลี่ยนจากสายขาดที่ไม่มีตัวเลขให้นับ ให้กลายเป็น 500 ที่ขึ้นกราฟและตั้ง alert ได้

9 · เขียนใน Go ยังไงไม่ให้พลาด

อย่าพิมพ์เลขดิบ — net/http มีค่าคงที่ให้ครบทุกตัว ผมพิมพ์ออกมาดูพร้อมชื่อข้อความประจำรหัส:

http.StatusOK                    = 200  StatusText = "OK"
http.StatusCreated               = 201  StatusText = "Created"
http.StatusNoContent             = 204  StatusText = "No Content"
http.StatusBadRequest            = 400  StatusText = "Bad Request"
http.StatusUnauthorized          = 401  StatusText = "Unauthorized"
http.StatusForbidden             = 403  StatusText = "Forbidden"
http.StatusNotFound              = 404  StatusText = "Not Found"
http.StatusConflict              = 409  StatusText = "Conflict"
http.StatusUnprocessableEntity   = 422  StatusText = "Unprocessable Entity"
http.StatusInternalServerError   = 500  StatusText = "Internal Server Error"

http.StatusNotFound ยาวกว่า 404 ก็จริง แต่มันทำสองอย่างที่เลขดิบทำไม่ได้: 1) อ่านแล้วรู้เจตนาทันที — StatusNotFound บอกตัวเองว่าแปลว่าอะไร
2) พิมพ์ชื่อผิดแล้ว compile ไม่ผ่าน — เคาะเป็น http.StatusNotFund คอมไพเลอร์ฟ้องทันทีตั้งแต่ยังไม่ได้รัน
เทียบกับเลขดิบ: เผลอพิมพ์ 440 แทน 404 คอมไพเลอร์ไม่มีทางรู้ เพราะมันก็เป็นแค่ int ตัวหนึ่ง — จะรู้ตอน client บ่นเท่านั้น

ต่อมาคือลำดับที่ห้ามสลับ ทดสอบมาแล้วทั้งสามแบบ:

เหตุผลเบื้องหลังทั้งตารางมีข้อเดียว: WriteHeader คือจังหวะที่ status กับ header ถูกส่งออกสายไปแล้ว ของที่ตั้งทีหลังจึงตามไปไม่ทัน (แถว 2) และ Write ครั้งแรก ก็เรียก WriteHeader(200) ให้เองอัตโนมัติถ้ายังไม่เคยเรียก (แถว 3)
แถวสุดท้ายคือต้นตอคลาสสิกของ "ทำไม error ตอบ 200" ที่ไม่ได้เกิดจากตั้งใจเลย — แค่เผลอ fmt.Fprintln(w, ...) ไปก่อนหนึ่งบรรทัด status ก็ถูกล็อกที่ 200 ทันที
ข่าวดีคือ log บอกชื่อฟังก์ชันและเลขบรรทัดมาให้เสร็จ — เห็น superfluous เมื่อไหร่ ให้ตามไปที่บรรทัดนั้นได้เลย
กฎเดียวที่ต้องจำ: Header().Set() → WriteHeader() → Write()/Encode() และเขียน status ได้ครั้งเดียวต่อหนึ่ง response

10 · พิสูจน์ด้วยเทส — status คือสิ่งที่เทสง่ายที่สุดในทั้ง API

ข้อดีของ status code คือมันเป็น int ตัวเดียว จะ assert (เขียนเงื่อนไขให้เทสตรวจว่าค่าที่ได้ตรงกับที่คาดไว้ไหม) ก็ง่ายที่สุดในบรรดาทุกอย่างของ API ใช้ httptest ที่ติดมากับ Go ได้เลย ไม่ต้องเปิด server จริง โครงเป็น table-driven test แบบเดียวกับ บทเรียน 16:

สามชิ้นที่เจอครั้งแรก: NewRouter() = ฟังก์ชันของเราเอง ที่คืน *http.ServeMux ที่ลงทะเบียน route ไว้หมดแล้ว (ในภารกิจข้างล่างต้องเขียนเอง) · httptest.NewRequest = ปั้น request ปลอมขึ้นมาหนึ่งอัน · httptest.NewRecorder() = กระดาษเปล่าที่รับคำตอบแทน client จริง แล้วอ่านผลได้ที่ w.Code กับ w.Body
เรียก router.ServeHTTP(w, req) = สั่งให้ router ทำงานตรง ๆ โดยไม่ต้องเปิดพอร์ตจริงเลย เทสจึงเร็วและไม่ชนกันเอง

func TestUserStatus(t *testing.T) {
    tests := []struct {
        name     string
        path     string
        wantCode int
    }{
        {"เจอ user -> 200", "/users/1", http.StatusOK},
        {"ไม่เจอ user -> 404", "/users/999", http.StatusNotFound},
    }
    router := NewRouter()
    for _, tc := range tests {
        t.Run(tc.name, func(t *testing.T) {
            w := httptest.NewRecorder()                // recorder ใหม่ทุกเคส
            router.ServeHTTP(w, httptest.NewRequest("GET", tc.path, nil))
            if w.Code != tc.wantCode {
                t.Fatalf("อยากได้ %d แต่ได้ %d  body=%s", tc.wantCode, w.Code, w.Body.String())
            }
        })
    }
}

$ go test -v -count=1 ./prove/
=== RUN   TestUserStatus
=== RUN   TestUserStatus/เจอ_user_->_200
=== RUN   TestUserStatus/ไม่เจอ_user_->_404
--- PASS: TestUserStatus (0.00s)
    --- PASS: TestUserStatus/เจอ_user_->_200 (0.00s)
    --- PASS: TestUserStatus/ไม่เจอ_user_->_404 (0.00s)
PASS
ok  	check34/prove	0.452s

$ BUG=1 go test -v -count=1 ./prove/
=== RUN   TestUserStatus
=== RUN   TestUserStatus/เจอ_user_->_200
=== RUN   TestUserStatus/ไม่เจอ_user_->_404
    app_test.go:24: อยากได้ 404 แต่ได้ 200  body={"error":"user not found"}
--- FAIL: TestUserStatus (0.00s)
    --- PASS: TestUserStatus/เจอ_user_->_200 (0.00s)
    --- FAIL: TestUserStatus/ไม่เจอ_user_->_404 (0.00s)
FAIL
FAIL	check34/prove	0.236s
FAIL

นี่คือเทสที่จับกับดักของหัวข้อ 7 ได้ก่อนขึ้น production — และสังเกตว่าเคส "เจอ user" ยัง PASS อยู่ทั้งสองฝั่ง ซึ่งตรงกับความเป็นจริง: bug แบบนี้ไม่เคยทำให้ happy path พัง มันซ่อนอยู่ในเส้นทาง error เสมอ

ทดสอบความเข้าใจ

mkdir status-lab && cd status-lab
go mod init statuslab

$ curl -s -i -X POST http://127.0.0.1:8765/hello
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff

Method Not Allowed

อ้างอิง

• MDN — HTTP response status codes — คำนิยามของทุกรหัสในบทนี้ อ่านหน้าเดียวได้ครบ
• MDN — 401 Unauthorized · 403 Forbidden — อ่านคู่กัน จะเห็นว่าทำไม 401 ถึงต้องมี WWW-Authenticate ส่วน 403 ไม่มี
• RFC 9110 §15 — Status Codes — ตัวข้อกำหนดจริง รวมถึงข้อความที่ระบุว่า 204 ต้องไม่มี body
• pkg.go.dev — net/http constants — รายชื่อ http.Status... ทั้งหมด ใช้แทนเลขดิบ
• pkg.go.dev — http.ResponseWriter — เอกสารอธิบายเองว่าทำไมลำดับต้องเป็น Header → WriteHeader → Write
• pkg.go.dev — net/http/httptest — NewRecorder / NewRequest / NewServer ที่ใช้ในหัวข้อ 10
• Cheat sheet Day 8 — ตารางเลือก status code และกับดักรวมทั้งวัน