142

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"
11
  • 7
    Perhaps you should show us the request your proxy is sending to SO? Jun 22, 2013 at 5:50
  • 207
    What if. Just what if. Stack Overflow is a teapot?
    – Cole Tobin
    Jun 22, 2013 at 5:56
  • 2
    @JanDvorak: It is a pretty standard C# Http POST.
    – caesay
    Jun 22, 2013 at 6:07
  • 25
    @caesay it seems non-standard enough for SO to know you're a cup of tea. Jun 22, 2013 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, 2013 at 6:14
  • 13
    Well, what does one normally have with tea? ;)
    – Tim Post
    Jun 22, 2013 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, 2013 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, 2016 at 16:21
  • 3
    @JanDvorak It is not my cup of tea.
    – Peter Wone
    Aug 9, 2016 at 1:22
  • 9
    In the Internet of Things, 418 now becomes relevant. How did they know??? Jun 26, 2017 at 20:49
  • Protected to prevent teapot spam! Oct 8, 2019 at 7:25

2 Answers 2

156
+50

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.

13
  • 3
    You should answer this question, then.
    – Ry-
    Jun 22, 2013 at 15:35
  • 95
    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, 2013 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, 2013 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, 2014 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, 2014 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 Staff
    Nov 7, 2014 at 5:52
  • 3
    @balpha Wikipedia's description is way off, then... I'd better fix that.
    – Brilliand
    Nov 7, 2014 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, 2014 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, 2017 at 6:18
  • 2
    @balpha how did you get Apache (I assume you use apache) to return 418? Oct 31, 2017 at 16:17
  • 3
    @Blacksilver No Apache here.
    – balpha Staff
    Nov 1, 2017 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, 2019 at 23:55
  • 3
    Not sure APIs are the right place for jokes. Nov 29, 2019 at 12:03
28

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.

4
  • 14
    Only sometimes? Come on, don't be coy now. Jun 22, 2013 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. Jun 22, 2013 at 11:34
  • 9
    @NickCraver: After that you make them turn it into a coffee pot?
    – animuson StaffMod
    Jun 22, 2013 at 16:09
  • Teapot spotting using SE's imgur function for about 20 minutes.
    – uhoh
    Mar 29, 2017 at 23:45

You must log in to answer this question.

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