ข้อความข้อผิดพลาด HTTP 418 I'm a teapot
(developer.mozilla.org)- HTTP 418
I'm a teapotคือรหัสสถานะการตอบกลับที่เซิร์ฟเวอร์ปฏิเสธว่าไม่สามารถชงกาแฟได้ เพราะเซิร์ฟเวอร์เป็นกาน้ำชาอย่างถาวร - หากเป็นกรณีที่กาน้ำแบบใช้ได้ทั้งกาแฟ/ชาชั่วคราวไม่สามารถให้บริการกาแฟได้ ควรส่งกลับ
503 Service Unavailableไม่ใช่ 418 - รหัสนี้เป็นมุกวันเมษาหน้าโง่จาก Hyper Text Coffee Pot Control Protocol และเชื่อมโยงกับโปรโตคอลที่กำหนดไว้ในปี 1998 และ 2014
- เดิมเป็นรหัสมุกใน RFC 2324 แต่เนื่องจากถูกนำไปใช้งานอย่างแพร่หลาย จึงถูกสงวนไว้อย่างเป็นทางการใน RFC 9110
- บางเว็บไซต์ใช้ 418 กับคำขอที่ไม่ต้องการประมวลผล เช่น คำค้นอัตโนมัติ และในอนาคตอันใกล้จะไม่สามารถกำหนดความหมายที่ไม่ใช่มุกให้กับรหัสนี้ได้
สถานการณ์ที่ HTTP 418 สื่อถึง
- รหัสสถานะการตอบกลับ
418 I'm a teapotหมายความว่าเซิร์ฟเวอร์ปฏิเสธการชงกาแฟ - เหตุผลที่ปฏิเสธคือเซิร์ฟเวอร์เป็น กาน้ำชา อย่างถาวร
- หากกาน้ำแบบใช้ได้ทั้งกาแฟ/ชาชั่วคราวไม่สามารถให้บริการกาแฟได้ ควรส่งกลับ
503
รหัสที่เริ่มจากโปรโตคอลวันเมษาหน้าโง่
- รหัสสถานะนี้อ้างอิงถึง Hyper Text Coffee Pot Control Protocol
- โปรโตคอลดังกล่าวถูกกำหนดเป็น มุกวันเมษาหน้าโง่ ในปี 1998 และ 2014
- เดิม 418 เป็นรหัสที่ถูกกำหนดเป็นมุกวันเมษาหน้าโง่ใน RFC 2324
เหตุผลที่ถูกสงวนไว้ใน RFC 9110
- รหัสสถานะ 418 ถูกนำไปใช้งานอย่างแพร่หลายในฐานะมุก จึงถูกสงวนไว้อย่างเป็นทางการใน RFC 9110
- การสงวนนี้ทำให้ในอนาคตอันใกล้ไม่สามารถกำหนด ความหมายที่ไม่ใช่มุก ให้กับ 418 ได้
วิธีใช้งานจริง
- บางเว็บไซต์ใช้ การตอบกลับ 418 กับคำขอที่ไม่ต้องการประมวลผล
- ตัวอย่างที่พบบ่อยคือคำขออย่าง คำค้นอัตโนมัติ
สเปกและเอกสารอ้างอิงที่เกี่ยวข้อง
- RFC 2324 section 2.3.2: นิยามดั้งเดิมของรหัสสถานะ 418
- HTTP Semantics name-418-unused: สถานะการสงวนของ 418
- HTTP response status codes: รายการรหัสสถานะการตอบกลับ HTTP
- Wikipedia: Hyper Text Coffee Pot Control Protocol: เอกสารอ้างอิงเกี่ยวกับ Hyper Text Coffee Pot Control Protocol
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้าว่าง ๆ ก็น่าอ่านการถกเถียงตอนที่ mnot พยายามลบ status code 418 ออกจากหลายภาษาและหลาย implementation ด้วยเหตุผลว่ามันไม่ถูกต้องในเชิงเทคนิค
https://github.com/nodejs/node/issues/14644
https://github.com/golang/go/issues/21326
สุดท้ายมีคนถึงขั้นทำเว็บ http://save418.com/ ขึ้นมา
ประมาณว่าใส่อีโมจิจรวดเวลางานสำเร็จ ซึ่งผมไม่เห็นด้วย พอเริ่มใส่อะไรแบบนี้ แต่ละคนก็จะมีรสนิยมของตัวเอง แล้วก็จะมีการถกกันต่อว่า ตรงนี้ควรใส่เพิ่ม ตรงนั้นควรเอาออก และแม้ตอนคุยเรื่องที่ไม่เกี่ยวกันเลยก็ยังถูกลากกลับมาพูดถึง
โดยเฉพาะถ้าไม่ได้ใช้การติดตามพฤติกรรมผู้ใช้เพื่อดูว่าตัวชี้วัดดีขึ้นจริงไหม ผมมองว่าต้นทุนด้าน การสื่อสาร ที่เพิ่มขึ้นเป็นความเสียหายใหญ่ ไม่ใช่ปัญหาเรื่องความเป็นมืออาชีพ แต่เป็นเรื่องความเป็นอัตวิสัยแบบที่บางคนชอบ บางคนไม่ชอบ บางคนไม่สังเกตเห็น ซึ่งสร้างแรงเสียดทานเล็ก ๆ ได้บ่อย
ผมตอบคำขอจากบอทที่ไม่ชอบธรรมด้วย 418 สนุกดี และทำให้กรอง log ได้ง่ายขึ้น
ตัวอย่างการตั้งค่า Nginx เป็นแบบนี้
Nothing to hack around here, I’m just a teapot:
location ~* .(?:php|aspx?|jsp|dll|sql|bak)$ {
return 418;
}
error_page 418 /418.html;
ตัวอย่าง: https://FreeSolitaire.win/wp-login.php
สำหรับข้อมูลเพิ่มเติม /wp-login.php เป็น URL สำหรับล็อกอินของ WordPress และบอทที่หา WordPress ที่ติดตั้งแบบมีช่องโหว่มักจะยิงขอเข้ามาแบบสุ่ม ๆ
ผมสงสัยว่าถ้าต้องการบล็อกที่อยู่นั้นถาวรเพียงเพราะมันร้องขอ URL แบบนี้ ควรทำอย่างไร
RFC ต้นฉบับที่ลิงก์ไว้ก็อ่านเพลิน: https://www.rfc-editor.org/rfc/rfc2324
เวลาอ่านเอกสารว่า TCP หรือ TLS ทำงานอย่างไร จะรู้สึกว่าเขียนโดยผู้เชี่ยวชาญที่มีประสบการณ์และวิสัยทัศน์ แต่เอกสาร CCSDS ดูเหมือนเขียนโดยข้าราชการที่ทั้งชีวิตไม่เคยเขียนโค้ดสักบรรทัด
นี่เป็น มุกเนิร์ดแบบโผล่มาไม่ดูจังหวะ ก่อนที่ “sir, this is a wendy's” จะดังเป็นมีมบน Facebook ในช่วงทศวรรษ 2010
ผมมักนึกถึงส่วนเจ๋ง ๆ ส่วนหนึ่งที่เคยเจอตอนอ่าน HTTP/2 RFC ด้วยเหตุผลอะไรก็จำไม่ได้
ก่อนที่ “429 Too Many Requests” จะถูกทำให้เป็นมาตรฐาน Twitter API เคยส่ง status code 420 ที่ไม่ใช่มาตรฐาน พร้อมข้อความ “Enhance Your Calm” เมื่อจำกัดอัตราคำขอ เขาเลิกใช้ด้วยเหตุผลที่เข้าใจได้ แต่ข้อความนั้นกลับแอบเข้าไปอยู่ใน HTTP/2
https://datatracker.ietf.org/doc/html/rfc7540#section-7
ถ้าดูรายการ 0xb จะเห็นว่าข้อความสำหรับการปิดการเชื่อมต่อเพราะโหลดมากเกินไปเป็น ENHANCE_YOUR_CALM จริง ๆ เห็นทีไรก็ขำ
ทุกครั้งที่เจอรหัสข้อผิดพลาดนี้ในบริการจริง ๆ จะหงุดหงิดมาก
มีคนอยากดูมีไหวพริบเลยส่งตัวนี้แทน status code ที่ถูกต้องอย่าง 429 หรือ 503 แล้วทำให้ HTTP status code parser จำนวนมากพัง
มันไม่ได้ฉลาด ไม่ได้ตลก และจริง ๆ แล้วน่าเบื่อ ผมรู้ว่าตัวเองเป็นคนไม่สนุก แต่ผมมีงานต้องทำ
ว่ากันว่า Van Halen เขียนไว้ในสัญญาการแสดงว่าให้มี M&M ไว้หลังเวที แต่ต้องเอาสีน้ำตาลออกทั้งหมด
นักร้องนำ David Lee Roth อธิบายในอัตชีวประวัติ ‘Crazy From the Heat’ ว่านี่ไม่ใช่คำขอแบบเด็ก ๆ แต่เป็นการทดสอบที่ชาญฉลาดเพื่อประเมินทันทีว่าสถานที่จัดงานปลอดภัยหรือไม่
ถ้าสถานที่จัดงานวาง M&M สีน้ำตาลไว้ ก็แปลว่าไม่ได้อ่านสัญญาอย่างละเอียด และอาจผิดพลาดในส่วนที่อันตรายกว่านั้น เช่น ระบบไฟฟ้าหรือการรับน้ำหนักของเวทีด้วย
https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...
เมื่อก่อน Sonatype Nexus เคยส่ง 418 ระหว่างอัปโหลด artifact ซึ่งไม่ได้ประทับใจเลย
การใช้ HTTP status code ผิดวัตถุประสงค์ เห็นทีไรก็ยังทึ่ง ตัวอย่างที่ผมชอบคือบริการของลูกค้ารายหนึ่งที่ส่ง “200 OK” กลับมา แล้วใส่ข้อความ “500” อย่างเดียวไว้ใน response body
พอขอให้ส่ง error 500 แทน 200 เมื่อมี API error เขากลับไปเปลี่ยนแค่ 200 ใน response ไม่ใช่ใน header “200 Created” ก็เป็นตัวอย่างที่แรงพอสมควรของความไม่เข้าใจของนักพัฒนา หรือข้อจำกัดแปลก ๆ ของ framework
เราใช้ response code 418 ในบริการยืนยันตัวตน
ใช้แยกว่า token ไม่ถูกต้องเพราะหมดอายุ หรือเพราะเหตุผลอื่น ถ้าเป็น 418 ก็ถือว่าสามารถ refresh access token อัตโนมัติได้ ค่อนข้างไม่เป็นพิษเป็นภัย และไม่ใช่มาตรการด้านความปลอดภัยเลย
การถกเถียงที่เกี่ยวข้อง
ปี 2020, 153 คะแนน·118 ความคิดเห็น: https://news.ycombinator.com/item?id=24206899
ปี 2021, 193 คะแนน·108 ความคิดเห็น: https://news.ycombinator.com/item?id=28541327
ปี 2023, 206 คะแนน·189 ความคิดเห็น: https://news.ycombinator.com/item?id=36090344
ใน thread แบบนี้ ปกติมักมีใครสักคนลิงก์ iiNet coffee cam อยู่เสมอ อยู่ที่นี่
https://coffeecam.iinet.net.au/coffee/history/
coffeecam ก็น่ารัก และ acb ซึ่งเป็นคนดูแล coffeecam เป็นหลัก ยังขายขนมอเมริกันแถวนั้นด้วย อย่างน้อยก็ตอนที่ผมทำงานที่ Hay Street