临近下班，闲来无事忽然想起Fundebug的BUG监控今天很安静，竟然没有给我推送报警，有点不适应。于是主动登录管理后台看看我们网站有没有出什么严重的bug。
报错401，Unauthorized, "token authentication fail: member does not exist, 未授权访问，一周内总计出现两次，影响两个用户，也不是很严重[一脸懒散不在意]
反正闲着也是闲着，干脆来看看能不能把这个错误给解了。
一般看到401都忽略了，基本上都是因为用户在未登录的情况下尝试去访问登录的页面，属于正常情况。可我今天就是好奇，点进去看了一下。
这种错误叫做HTTP请求错误，没有堆栈信息，直接查看用户行为：
用户行为记录很长，总共有20条。在这里我只截取了报错前的4条记录, 分别是：HTTP请求错误、两次HTTP请求和一次点击。
由于是倒序的，我们从下往上看：用户点击了“创建团队”按钮，第一个HTTP请求该邮箱未被注册，返回404， 第二个HTTP请求发送创建请求，成功返回200。然后，```/members/me```的请求报错401了。
明明账户都创建成功了啊，为啥？为啥？为哈？
搞不懂，接着看另一个北京用户的报错：
一模一样，创建完毕后立马报错401！
我不由得陷入了沉思，我将时间跨度选择为一个月甚至全部，依然只有两个错误事件。
每天都有不少用户注册成功，可见并不是每一个注册用户都受到影响，也就是说和他输入的内容有关？
好在GET请求有带参数，眼尖的我很快发现了问题的可能性： [email protected]， [email protected]。这些邮箱都是大小写混合的！应该是网站客户端发送给服务器的token解码之后的邮箱地址和服务器本身存储的匹配失败，导致报错“token authentication fail”。
通过查看后端代码，发现问题果真如此。数据库对于邮箱字段设置了小写的限制，会自动将大写转换为小写，而token中的邮箱是原始的包含大小写混合的字段，因此匹配失败。
最后，给大家补充一个关于邮箱大小写的知识点( 什么情况下，邮箱账号需要区分大小写？）：
根据RFC5321，要求 SMTP 的实现必须区分邮件地址中的 local-part （即 @ 之前的部分）的字母大小写，不过可以看到其原因是“邮件发送方不能假定接收方是大小写不敏感的（或者反过来）”。再看最后一句， RFC5321 对于区分大小写这一做法的态度是“不鼓励”。
2.4. General Syntax Principles and Transaction Model...The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
也就是说邮箱不区分大小写已经是一个约定俗成了，技术上实现必须要考虑进去，并且要小心注意不要漏掉某些接口需要特殊处理。
不看还好，一看还真发现了一个看不懂的报错。
反正闲着也是闲着，干脆来看看能不能把这个错误给解了。
一般看到401都忽略了，基本上都是因为用户在未登录的情况下尝试去访问登录的页面，属于正常情况。可我今天就是好奇，点进去看了一下。
这种错误叫做HTTP请求错误，没有堆栈信息，直接查看用户行为：
用户行为记录很长，总共有20条。在这里我只截取了报错前的4条记录, 分别是：HTTP请求错误、两次HTTP请求和一次点击。
由于是倒序的，我们从下往上看：用户点击了“创建团队”按钮，第一个HTTP请求该邮箱未被注册，返回404， 第二个HTTP请求发送创建请求，成功返回200。然后，```/members/me```的请求报错401了。
明明账户都创建成功了啊，为啥？为啥？为哈？
搞不懂，接着看另一个北京用户的报错：
一模一样，创建完毕后立马报错401！
我不由得陷入了沉思，我将时间跨度选择为一个月甚至全部，依然只有两个错误事件。
每天都有不少用户注册成功，可见并不是每一个注册用户都受到影响，也就是说和他输入的内容有关？
好在GET请求有带参数，眼尖的我很快发现了问题的可能性： [email protected]， [email protected]。这些邮箱都是大小写混合的！应该是网站客户端发送给服务器的token解码之后的邮箱地址和服务器本身存储的匹配失败，导致报错“token authentication fail”。
通过查看后端代码，发现问题果真如此。数据库对于邮箱字段设置了小写的限制，会自动将大写转换为小写，而token中的邮箱是原始的包含大小写混合的字段，因此匹配失败。
最后，给大家补充一个关于邮箱大小写的知识点( 什么情况下，邮箱账号需要区分大小写？）：
根据RFC5321，要求 SMTP 的实现必须区分邮件地址中的 local-part （即 @ 之前的部分）的字母大小写，不过可以看到其原因是“邮件发送方不能假定接收方是大小写不敏感的（或者反过来）”。再看最后一句， RFC5321 对于区分大小写这一做法的态度是“不鼓励”。
2.4. General Syntax Principles and Transaction Model...The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
也就是说邮箱不区分大小写已经是一个约定俗成了，技术上实现必须要考虑进去，并且要小心注意不要漏掉某些接口需要特殊处理。