First a little background:

I recently wrote a reverse proxy which I have found to work wonderfully so far, and being an avid Stack Overflow user, I thought I would try it out there.

I was just playing around and everything was working perfectly, until I hit one page that suddenly returned HTTP error code 418 (I'm a teapot) which was an april fools joke from Hyper Text Coffee Pot Control Protocol.

Why would Stack Exchange ever be set up to return this status code?

The pages I have found to return 418 with my reverse proxy are https://stackoverflow.com/users/login and https://stackoverflow.com/users/authenticate

I do not even know what to call this. I would at first have thought "Bug", but it is obviously not, because, well - how would you end up with an HTTP server returning 418 without doing it on purpose.

I will not dispute that this may be a result of my reverse proxy not doing something exactly the same as a browser, and because that is an OAuth authentication page and there may be some security or something, but perhaps it should be returning a more appropriate HTTP response?

And screenshot:

Screenshot of an HTTP 418

As requested, more information about the post request my client is sending. It is, for instance, sending a standard HttpWebRequest pointed at https://stackoverflow.com/users/authenticate with the client's cookies/useragent forwarded, method set to POST and post values of the following:

  • fkey: "4dde960.........."
  • oauth_version: ""
  • openid_username: ""
  • openid_identifier: "https://www.google.com/accounts/o8/id"
  • 7
    Perhaps you should show us the request your proxy is sending to SO? – John Dvorak Jun 22 '13 at 5:50
  • 204
    What if. Just what if. Stack Overflow is a teapot? – Cole Johnson Jun 22 '13 at 5:56
  • 2
    @JanDvorak: It is a pretty standard C# Http POST. – caesay Jun 22 '13 at 6:07
  • 23
    @caesay it seems non-standard enough for SO to know you're a cup of tea. – John Dvorak Jun 22 '13 at 6:09
  • I think it may have something to do with the construction of POST requests - I am digging right now, but that still does not explain the error code :) – caesay Jun 22 '13 at 6:14
  • 13
    Well, what does one normally have with tea? ;) – Tim Post Jun 22 '13 at 6:31
  • 1
    @caesay It's a long shot guess based on my understanding of certain senses of humor actually, I can't see why it returned a 418, only that it did. – Tim Post Jun 22 '13 at 6:35
  • General Info: Apparently, the proper use case for 418 is... Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". (Yes, I realize it's a joke, but always remember to joke in the proper context to show you actually got it. ;^D) – ruffin Jun 28 '16 at 16:21
  • 3
    @JanDvorak It is not my cup of tea. – Peter Wone Aug 9 '16 at 1:22
  • 9
    In the Internet of Things, 418 now becomes relevant. How did they know??? – Monica Cellio Jun 26 '17 at 20:49
  • Protected to prevent teapot spam! – Andrew Grimm Oct 8 '19 at 7:25

A while ago we finally switched the response to CSRF violations from a non-descript error page, as we had been doing for years, to something sensible that somewhat explains what's going on.

While implementing this change, I was considering what HTTP status code to return in such a case. Excerpt from our chatroom:

Me: There's really no good HTTP status code for an XSRF violation, but it feels like it should be a class 4 code. Any objection to returning a 418?

Marc: 403 seems more apt, but I can get with 418

Me: > Authorization will not help and the request SHOULD NOT be repeated.
that's 403, not really true
if you fix the xsrf token, repeating will help

412 Precondition Failed was also suggested, but that's not applicable either, since a "precondition" is a pretty specific thing in that context.

Long story short: There's not really a good status code for this case, so I figured we might as well return a 418. In addition, it's a little easter egg you just found :)

Note that these responses actually have a body that the browser displays; it's your proxy that hides this explanation.

| improve this answer | |
  • 3
    You should answer this question, then. – Ry- Jun 22 '13 at 15:35
  • 92
    Note that these respones actually have a body that the browser displays. Fair enough, but is the response body short and stout? – TRiG Aug 2 '13 at 10:42
  • 3
    As for the lost body of the error response: love it when new software mimics IE4/5/6 ;-) – Arjan Aug 9 '13 at 8:07
  • Just in case it matters: I just got the same error a few times when commenting and voting (here), even after a page refresh. I doubt I should have been running into CSRF issues, but Chrome's network tab revealed "Sorry, your request could not be completed because it looked suspicious. If you meant to perform an action on Super User, please return to the previous page and try again.", after I already refreshed. (Meanwhile the comment succeeded, the vote still did not, but that's not a problem.) – Arjan Apr 29 '14 at 18:48
  • 4
    I think error code 400 is appropriate here: "I refuse to process this request and I think it's your fault." – Brilliand Nov 7 '14 at 4:37
  • 2
    @Brilliand The definition of a 400 is "The request could not be understood by the server due to malformed syntax." That is not at all appropriate here; the request isn't malformed. It's just missing a correct parameter. – balpha Nov 7 '14 at 5:52
  • 3
    @balpha Wikipedia's description is way off, then... I'd better fix that. – Brilliand Nov 7 '14 at 17:33
  • 11
    @balpha I think it's safe to treat 400 as an "other" 400 code in practice, much like 500 is, "some error happened and no other 500 code is appropriate." There really needs to be some kind of catch all for "this request was bad and no other code is appropriate"; if it's not 400, what is it? – jpmc26 Dec 1 '14 at 20:42
  • 2
    @TRiGisTimothyRichardGreen: IIRC the relevant RFC says that the body MAY be short and stout, so it's not a requirement of the standard. – Kevin Apr 6 '17 at 6:18
  • 2
    @balpha how did you get Apache (I assume you use apache) to return 418? – SIGSTACKFAULT Oct 31 '17 at 16:17
  • 3
    @Blacksilver No Apache here. – balpha Nov 1 '17 at 9:07
  • 2
    A strange decision. 403 Forbidden is standard and usual for an authenticated user trying to do something that's syntactically and semantically valid but you're not allowed. Of course in this case you're preventing the authenticated user from being tricked into doing something by a malicious third party. There's nothing to fix and it should not be repeated. – OrangeDog Nov 28 '19 at 23:55
  • 3
    Not sure APIs are the right place for jokes. – Lightness Races in Orbit Nov 29 '19 at 12:03

The form you're submitting isn't valid, this is one possible result when your fkey isn't correct on the submission. Either it's missing, or it doesn't match what it should be.

Also, sometimes Stack Overflow is a teapot.

| improve this answer | |
  • 13
    Only sometimes? Come on, don't be coy now. – BoltClock's a Unicorn Jun 22 '13 at 11:31
  • 5
    @BoltClock'saUnicorn Yep! Well, at least more so in the morning, when only the British and German halves of the dev team are awake. – Nick Craver Jun 22 '13 at 11:34
  • 9
    @NickCraver: After that you make them turn it into a coffee pot? – animuson Jun 22 '13 at 16:09
  • Teapot spotting using SE's imgur function for about 20 minutes. – uhoh Mar 29 '17 at 23:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .