我最近写了一个反向代理，到目前为止我发现它工作得很好，作为一个狂热的Stack Overflow用户，我想我可以在那里尝试一下。
我只是在玩耍，并且一切正常，直到我碰到一页突然返回HTTP错误代码418（我是茶壶）的页面，这是Hyper Text Coffee Pot Control的一个愚人节玩笑协议。
为什么要设置StackExchange以返回此状态代码？
我发现使用反向代理返回418的页面是https：// stackoverflow .com / users / login和https://stackoverflow.com/users/authenticate
我什至不知道该怎么称呼。我本来以为是“错误”，但显然不是，因为，好吧，您将如何在没有故意的情况下以HTTP服务器返回418的结果。
我不会对此表示怀疑。这可能是由于我的反向代理没有执行与浏览器完全相同的操作的结果，并且因为这是OAuth身份验证页面并且可能存在一些安全性或某些功能，但是也许它应该返回更合适的HTTP响应？
和屏幕截图：
根据要求，有关我的客户正在发送的帖子请求的更多信息。例如，它发送一个指向https://stackoverflow.com/users/authenticate的标准HttpWebRequest，并转发了客户端的cookie / useragent，方法设置为POST，并发布以下值：
fkey: "4dde960.........." oauth_version: "" openid_username: "" openid_identifier: "https://www.google.com/accounts/o8/id" #1 楼
不久前，我们终于将对CSRF违规的响应从我们多年以来的一个非描述性错误页面切换到了一种明智的方式，在某种程度上可以解释发生了什么。实施此更改时，我在考虑在这种情况下返回什么HTTP状态代码。摘录自我们的聊天室：
我：对于XSRF违规，确实没有很好的HTTP状态代码，但是感觉它应该是第4类代码。任何反对
返回418的异议？
Marc：403似乎更合适，但我可以使用418
我：>授权将无济于事，请求不应重复。
是403，不是真的
如果您修复xsrf令牌，
重复将有帮助
412 Precondition Failed，但这也不适用，因为在这种情况下，“前提条件”是非常具体的事情。长话短说：这种情况下并没有很好的状态代码，所以我认为我们也可以返回418。此外，它只是一个复活节彩蛋：)
请注意，这些响应实际上具有浏览器显示的正文；隐藏此解释的是您的代理。
评论
那你应该回答这个问题。
– Ry-
2013年6月22日15:35
请注意，这些响应实际上具有浏览器显示的正文。足够公平，但是反应身体短而粗壮吗？
– TRiG
13年8月2日在10:42
至于错误响应的遗体：当新软件模仿IE4 / 5/6时，请喜欢它；-)
– Arjan
13年8月9日在8:07
万一重要，以防万一：即使在刷新页面后，我在评论和投票时（这里）也几次遇到相同的错误。我怀疑我是否应该一直遇到CSRF问题，但是Chrome的网络标签显示“很抱歉，您的请求看起来很可疑，因此无法完成。如果您打算对超级用户执行操作，请返回上一页并重试。”，已经刷新了。 （虽然评论成功，但投票仍然没有，但这不是问题。）
– Arjan
2014年4月29日在18:48
我认为错误代码400在这里是合适的：“我拒绝处理此请求，我认为这是您的错。”
– Briilliand
2014年11月7日下午4:37
@Brilliand 400的定义是“由于语法格式不正确，服务器无法理解该请求。”这根本不合适。该请求没有格式错误。它只是缺少正确的参数。
– balpha
2014年11月7日下午5:52
@balpha Wikipedia的描述很遥远，然后...我最好解决它。
– Briilliand
2014年11月7日17:33
@balpha我认为在实践中将400视为“其他” 400代码是安全的，就像500一样，“发生了一些错误，没有其他500代码是合适的”。对于“此请求很糟糕，没有其他合适的代码”，确实需要采取某种措施。如果不是400，那是什么？
– jpmc26
2014年12月1日20:42
@TRiGisTimothyRichardGreen：IIRC的相关RFC表示主体可能短而结实，因此这不是标准的要求。
–凯文
17年4月6日在6:18
@balpha您如何获得Apache（我假设您使用apache）返回418？
–SIGSTACKFAULT
17年10月31日在16:17
@Blacksilver这里没有Apache。
– balpha
17年11月1日在9:07
一个奇怪的决定。对于经过身份验证的用户，尝试执行在语法和语义上有效但不允许您执行的操作，“ 403禁止访问”是标准和常见的操作。当然，在这种情况下，您可以防止经过身份验证的用户被恶意的第三方欺骗。没有可修复的东西，不应重复。
–橙色狗
19-11-28在23:55
不确定API是否适合开玩笑。
–轨道轻赛
19年11月29日在12:03
#2 楼
您提交的表单无效，这是您提交的fkey不正确时的一种可能结果。要么丢失了它，要么不匹配它。此外，有时Stack Overflow是一个茶壶。
评论
只有某些时候？来吧，现在不要co。
– BoltClock是独角兽
13年6月22日在11:31
@ BoltClock'saUnicorn是的！好吧，至少在早晨这样，开发团队只有英国和德国两半都醒了。
–尼克·克拉弗♦
13年6月22日在11:34
@NickCraver：之后，让他们把它变成咖啡壶？
– animuson♦
2013年6月22日16:09
使用SE的imgur功能查找茶壶约20分钟。
– uhoh
17 Mar 29 '17在23:45
评论
也许您应该向我们显示您的代理发送给SO的请求？如果。如果有的话。堆栈溢出是一个茶壶吗？
@JanDvorak：这是一个非常标准的C＃Http POST。
@caesay似乎对SO来说已经很不合标准了。
我认为这可能与POST请求的构建有关-我现在正在挖掘，但这仍然不能解释错误代码:)
好吧，一个人通常喝什么茶？ ;）
@caesay根据我对某些幽默感的理解，这是一个很长的猜想，我看不出为什么它返回了418，只是如此。
常规信息：显然，418的正确用例是...任何尝试用茶壶冲泡咖啡的尝试都应导致错误代码“ 418我是茶壶”。 （是的，我知道这是个玩笑，但请始终记住在适当的上下文中开玩笑，以表明您确实知道了。; ^ D）
@JanDvorak不是我的茶。
在物联网中，418现在变得很重要。他们怎么知道的？
保护防止茶壶垃圾邮件！