Thông báo lỗi HTTP 418 I'm a teapot

 (developer.mozilla.org)
1 điểm bởi GN⁺ 2024-10-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • HTTP 418 I'm a teapot là mã phản hồi trạng thái cho biết máy chủ từ chối pha cà phê vì nó vĩnh viễn là một ấm trà
  • Nếu đó là trường hợp ấm đun kết hợp cà phê/trà tạm thời không thể phục vụ cà phê, thì không phải 418 mà phải trả về 503 Service Unavailable
  • Mã này là một trò đùa Cá tháng Tư xuất phát từ Hyper Text Coffee Pot Control Protocol, gắn với các giao thức được định nghĩa vào năm 1998 và 2014
  • Ban đầu đây là mã đùa trong RFC 2324, nhưng vì đã được triển khai rộng rãi nên được RFC 9110 chính thức dành riêng
  • Một số website dùng 418 cho các yêu cầu mà họ không muốn xử lý như truy vấn tự động, và trong tương lai gần mã này không thể được gán một ý nghĩa không mang tính đùa vui

HTTP 418 biểu thị tình huống gì

  • Mã phản hồi trạng thái 418 I'm a teapot có nghĩa là máy chủ từ chối pha cà phê
  • Lý do từ chối là vì máy chủ vĩnh viễn là một ấm trà
  • Nếu là ấm đun kết hợp cà phê/trà tạm thời không thể phục vụ cà phê thì phải trả về 503

Mã bắt nguồn từ giao thức trò đùa Cá tháng Tư

  • Mã trạng thái này tham chiếu đến Hyper Text Coffee Pot Control Protocol
  • Giao thức này được định nghĩa như một trò đùa Cá tháng Tư vào các năm 1998 và 2014
  • 418 ban đầu là mã được định nghĩa như một trò đùa Cá tháng Tư trong RFC 2324

Vì sao được dành riêng trong RFC 9110

  • Mã trạng thái 418 đã được triển khai rộng rãi như một trò đùa nên được RFC 9110 chính thức dành riêng
  • Vì việc dành riêng này, trong tương lai gần không thể gán cho 418 một ý nghĩa không mang tính đùa vui

Cách được sử dụng trong thực tế

  • Một số website dùng phản hồi 418 cho các yêu cầu mà họ không muốn xử lý
  • Ví dụ tiêu biểu là các yêu cầu như truy vấn tự động

Đặc tả liên quan và tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-30
Ý kiến trên Hacker News

  • Nếu rảnh thì cũng đáng đọc lại cuộc thảo luận hồi mnot từng định loại bỏ mã trạng thái 418 khỏi nhiều ngôn ngữ và bản triển khai vì cho rằng nó không chính xác về mặt kỹ thuật
    https://github.com/nodejs/node/issues/14644
    https://github.com/golang/go/issues/21326
    Cuối cùng còn có người làm hẳn một trang là http://save418.com/

    • Cứ thấy nhắc đến 418 là tôi lại nhớ chuyện hồi ở công ty cũ từng cãi nhau xem có nên đưa emoji vào ứng dụng hay không
      Kiểu như thêm emoji tên lửa khi tác vụ thành công, và tôi phản đối. Một khi đã bắt đầu thêm mấy thứ này thì mỗi người sẽ có gu riêng, rồi sẽ liên tục nảy sinh tranh luận chỗ nào nên thêm, chỗ nào nên bỏ, và ngay cả khi đang bàn chủ đề hoàn toàn khác nó cũng lại bị lôi ra
      Đặc biệt nếu không theo dõi hành vi người dùng để xem các chỉ số thực sự có cải thiện hay không, thì việc tăng chi phí giao tiếp là một tổn thất lớn. Không phải vấn đề chuyên môn, mà là tính chủ quan kiểu có người thích, có người ghét, có người chẳng để ý, cứ thế tạo ra những ma sát nhỏ rất thường xuyên

  • Tôi phản hồi các yêu cầu bot không chính đáng bằng 418. Vừa vui vừa dễ lọc log hơn
    Ví dụ cấu hình Nginx như sau

    Nothing to hack around here, I’m just a teapot:

    location ~* .(?:php|aspx?|jsp|dll|sql|bak)$ {
    return 418;
    }
    error_page 418 /418.html;
    Ví dụ: https://FreeSolitaire.win/wp-login.php
    Nhân tiện, /wp-login.php là URL đăng nhập của WordPress, và các bot đi tìm bản cài WordPress dễ bị tấn công thường hay gửi bừa yêu cầu đến đó

  • RFC gốc được liên kết cũng rất đáng đọc: https://www.rfc-editor.org/rfc/rfc2324

    • Tôi thích những tài liệu RFC kiểu này. Hiện tôi đang làm việc với tài liệu CCSDS, và so với RFC thì đúng là một mớ hỗn độn
      Khi đọc tài liệu về cách TCP hay TLS hoạt động, tôi có cảm giác chúng được viết bởi các chuyên gia dày dạn kinh nghiệm và có tầm nhìn, còn tài liệu CCSDS thì trông như do mấy quan chức cả đời chưa viết nổi một dòng code soạn ra

  • Đây là kiểu trò đùa nerd vô duyên mà bất ngờ có từ trước khi “sir, this is a wendy's” bùng lên thành meme Facebook vào thập niên 2010

    • Những câu đùa như vậy có rất nhiều, còn có cả “the game” mà nhờ xkcd mọi người mới được giải thoát

  • Tôi luôn nhớ đến một đoạn hay ho từng đọc được khi đang xem HTTP/2 RFC vì một lý do nào đó
    Trước khi “429 Too Many Requests” được tiêu chuẩn hóa, Twitter API khi giới hạn tốc độ yêu cầu từng trả về mã trạng thái 420 không chuẩn cùng dòng chữ “Enhance Your Calm”. Vì những lý do dễ hiểu, họ đã dừng làm vậy, nhưng riêng câu đó thì đã được lén đưa vào HTTP/2
    https://datatracker.ietf.org/doc/html/rfc7540#section-7
    Nếu xem mục 0xb, câu mô tả việc đóng kết nối do tải quá mức đúng là ENHANCE_YOUR_CALM. Lần nào thấy cũng buồn cười

  • Mỗi lần gặp mã lỗi này trong dịch vụ thực tế tôi đều thấy cực kỳ bực mình
    Có người muốn tỏ ra hóm hỉnh nên trả về cái này thay vì các mã trạng thái đúng như 429 hay 503, và vì thế làm hỏng rất nhiều trình phân tích mã trạng thái HTTP
    Chẳng hóm hỉnh cũng chẳng buồn cười, thật ra chỉ thấy chán. Tôi biết mình không phải người vui tính, nhưng vẫn còn việc phải làm

    • Nếu parser không xử lý được mã lỗi nằm trong đặc tả thì đó là lỗi của parser
    • Có một giai thoại mang tính ngụ ngôn, độ xác thực có hơi không chắc lắm, khiến người ta phải nghĩ nếu một triển khai HTTP bỏ sót 418 thì còn bỏ sót gì nữa
      Chuyện kể rằng Van Halen từng ghi trong hợp đồng biểu diễn rằng phải để M&M ở hậu trường nhưng phải bỏ hết viên màu nâu
      Trong hồi ký ‘Crazy From the Heat’, ca sĩ David Lee Roth giải thích rằng đây không phải yêu sách trẻ con mà là một bài kiểm tra thông minh để đánh giá ngay xem địa điểm tổ chức có an toàn hay không
      Nếu địa điểm vẫn mang ra M&M màu nâu thì có nghĩa là họ đã không đọc kỹ hợp đồng, và rất có thể cũng mắc lỗi ở những phần nguy hiểm hơn như nguồn điện hay tải trọng sân khấu
      https://www.metaltalk.net/chris-dale-myth-busting-the-van-ha...

  • Trước đây Sonatype Nexus từng trả về 418 trong lúc tải artifact lên, và tôi chẳng thấy ấn tượng gì cả

    • Bỏ qua yếu tố hài hước thì tôi khá tò mò vì sao họ lại chọn đúng 418. Đôi khi có cảm giác như trong HTTP code đang thiếu một số lỗi, nên lập trình viên либо tự chế ra, либо tái sử dụng những mã như 418 vì có vẻ ít nguy cơ xung đột
      Việc dùng sai mã trạng thái HTTP lần nào thấy cũng khiến tôi ngạc nhiên. Trường hợp tôi thích nhất là một khách hàng có dịch vụ trả về “200 OK” rồi trong phần thân phản hồi chỉ ghi mỗi chữ “500” dưới dạng văn bản
      Khi được yêu cầu nếu API lỗi thì hãy trả lỗi 500 thay vì 200, họ không đổi header mà chỉ đổi số 200 bên trong phản hồi. “200 Created” cũng là một ví dụ khá điển hình cho thấy lập trình viên hiểu chưa tới nơi hoặc bị ràng buộc bởi framework kỳ quặc
    • Nghe nói nó xuất phát từ một Serious Enterprise™ Solution® như thế thì cũng thật lạ

  • Trong dịch vụ xác thực, chúng tôi dùng mã phản hồi 418
    Nó được dùng để phân biệt token không hợp lệ vì đã hết hạn hay vì lý do khác. Nếu là 418 thì hệ thống hiểu rằng chỉ cần tự động làm mới access token là được. Khá vô hại, và hoàn toàn không phải biện pháp bảo mật gì

  • Các cuộc thảo luận liên quan
    Năm 2020, 153 điểm·118 bình luận: https://news.ycombinator.com/item?id=24206899
    Năm 2021, 193 điểm·108 bình luận: https://news.ycombinator.com/item?id=28541327
    Năm 2023, 206 điểm·189 bình luận: https://news.ycombinator.com/item?id=36090344

  • Trong những thread kiểu này thường sẽ có ai đó link đến iiNet coffee cam. Đây nhé
    https://coffeecam.iinet.net.au/coffee/history/

    • iiNet có lẽ là nơi làm việc tốt nhất tôi từng trải qua, nơi tôi học được nhiều nhất và cũng vui nhất
      coffeecam cũng rất dễ thương, còn acb, người chủ yếu phụ trách coffeecam, còn bán cả bánh kẹo Mỹ quanh đó nữa. Ít nhất là hồi tôi còn làm ở Hay Street thì là vậy