Is 418 “I'm a teapot” really an HTTP response code?

后端 未结 5 1382
遥遥无期
遥遥无期 2020-12-23 02:47

Is 418 \"I\'m a teapot\" really an HTTP response code?

There are various references to this on the internet, including in lists of response codes, but I ca

相关标签:
5条回答
  • 2020-12-23 03:02

    HTTP response code 418 was originally defined in RFC 2324 ("Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)") and RFC 7168 ("The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)") protocols.

    Per Wikipedia: List of HTTP status codes: #418

    This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee. This HTTP status is used as an Easter egg in some websites, including Google.com.

    0 讨论(0)
  • 2020-12-23 03:13

    Yes it's a "real" code in that it was actually published as an official RFC by the Internet Engineering Task Force, but that RFC was published on April 1 and meant as an April fools joke (along with the rest of Hyper Text Coffee Pot Control Protocol), not for legitimate implementation. That's why most sites use it as an Easter egg, but otherwise avoid it. As noted by this comment, there are often more appropriate statuses like 400 (Bad Request). All that said, thanks to the IT community, it's now a reserved code, so don't expect it to be going anywhere anytime soon.

    Notably, according to Larry Masinter (the author of that RFC purported by Wikipedia), the HTTP extension in question actually does serve a (satirical) purpose: "it identifies many of the ways in which HTTP has been extended inappropriately."

    0 讨论(0)
  • 2020-12-23 03:16

    I think it is safer to treat 418 as a reserved code that once had a half - official meaning but now officially "unassigned".

    I assume, historically something has been differently thought about these codes than it is now. This sounds meaningless and funny today; probably was not?

    In other words, I would avoid using this code.

    0 讨论(0)
  • 2020-12-23 03:24

    Yes, I can confirm, that I've seen HTTP 418 coming back from a real production server. It does exist.

    0 讨论(0)
  • 2020-12-23 03:25

    I use this code. I have nginx reverse-proxying requests to two separate HTTP servers. One handles requests for unauthenticated users, and the second handles requests for authenticated users. The problem in this particular case, is the first server is the one that determines if the user is authenticated. Please don't ask why.

    So, if the first server determines the user is authenticated, it responds 418 I'm a teapot. NGINX then reroutes the traffic internally to the second server. As far as the browser is concerned, it was a single request.

    This is in the spirit of HTCPCP code 418, because if you attempt to BREW with a teapot, the appropriate response is "I'm not the kind of thing that can handle that request, but there may be others." .. In other words, "I'm a teapot. Find a coffee maker." (the second server being the coffee maker).

    Ultimately, while 418 is not explicitly defined in RFC 7231, it is still covered by the umbrella of 4xx (Client Error).

    6. Response Status Codes

    • 4xx (Client Error): The request contains bad syntax or cannot be fulfilled

    6.5. Client Error 4xx

    • The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.
    0 讨论(0)
提交回复
热议问题