@wonderfulcxm
那是因为 php 和 nginx 的结合方式是用 cgi-bin, 原理上和 允许 lua 类似，属于于 nginx + 插件这种方式，nginx 和你的脚本绑定到一块了，属于 nginx 作为执行者去调用了某个函数然后访问了你的脚本，属于同一个进程内的方法调用，然后函数去返回某个结果，调用出错 nginx 作为调用方是会接收到异常退出信息的。

然而这种题主的截图对话里告诉你了人家后端是 java 开发，java 不玩 cgi-bin 。


实际上 cgi-bin 的优点是非常简单方便，但缺点限制更明显，以前的脚本语言支持这种协议的多一些，php, py, perl 。

但其他大多数语言不论是 java ，go ，.net 还是 nodejs ，甚至你们 php 的许多框架也都直接选择了用自己实现的 http-server 来执行对应的代码，这样可以支持更多的特性更灵活的业务处理。
在这种时候 nginx 只是一个单纯的 反代服务器， 他只有一个作用，反代，完全不会参与代码执行，，这时候就不是进程内的方法调用了， 而是网络传输，nginx 去代用户发起了一个 http 请求到后端服务器上，这种情况 nginx 不会接收到异常调用栈的，这时候他实际上是不会涉及 500 错误的。 只会发生 502 ，504 ，这种 nginx 访问后端超时的错误。

如果这种反代的情况下还触发了 500 ，那只能说明 nginx 除了反代还做了其他功能，比如 lua 脚本或者其他插件进行限流等操作时候发生了 bug 。

总结一下问题。

运营发现访问不了，喊运维，
运维粗查监控没有宕机，甩锅前端，
前端一看 500 错误，就觉得这是后端的错，甩锅后端。
后端一看返回的是 nginx 的页面，而且访问的还是前端的路径(聊天里说的)，和我有 p 关系？

最后前端出来发帖："现在后端都这么好干吗》"

----------------------------

期待后续楼主出来解答一下到底谁的问题， 看看谁是真的在甩锅。

我唯一能想到的 前端项目路径报 500 还会是后端引起的情况就是 —— 你们是 SPA 应用做了首屏服务端渲染，然后服务端渲染时调用后端 api 报错。
有人知道其他可能性的话麻烦也给我讲讲。

我初步猜测，最有可能的情况是 500 的访问链接是代码拼接生成的，但拼接了特殊符号或者什么其他内容，导致反代解析出问题；
除此外要么是 WAF 相关设置有毛病，要么反代服务器配置有问题或者写了 Lua 脚本但出 bug 了。

@wonderfulcxm
如果后端报 500 错，会由后端的服务器程序以自己的格式返回错误信息，对于 java 的后端而言是 tomcat 或者其他程序，而不是 openresty 的标准 500 页面。
不信的话你自己用 node 起一个服务让他访问就 500 ，然后你用 openresty/nginx 反代套一层，自己访问看一下会不会出现 openresty 的 500 页面。

网上看了看教学视频， 然后去池子里扑腾了 5 次学会了蛙泳。
第一次第二次连飘起来都做不到，别说游了， 后面第三次基本学会了大概，可以憋着一口气游几米，第 4 第 5 次都是在找手脚配合抬头换气的节奏。

@huangmingyou 是不是那个什么保洁大妈去把散热扇拔了充电的那个？ 检查的人去的时候大妈看着有人就没进去拔。

@dingwen07 现在说的是前端哈希，正常情况后端会自己做加密以及摘要，脱裤了攻击者拿到的也是无用的数据，你拿到前端的哈希那攻击者还能登录，但拿到数据库的密码字段是纯粹无用字段，除了 md5 和 sha1 其他方式攻击者都无法用彩虹表反解，连在本站登录都不能做到，如何危害其他网站安全？

而且这偏题了，提名是说 https ， 我的意思是 https 没那么容易被监听，所以前端不要自己做哈希， 你要是 http 那你爱怎么折腾怎么折腾去，我虽然依然觉得前端哈希不如前端 RSA ，但好歹比裸奔强。

@Buges 有影响，你前端哈希了如何做弱密码禁止相关的策略？ 写个 5M 的 js 来个穷举？

@Buges 我承认你说的这个问题，但我个人还是认为 https 不太容易被攻击，前端 hash 的缺点高于优点。
同时我说了我觉得前端要做可以做非对称加密

我今天用招行 app 的时候发现招行可以直接 nfc 读取身份证信息，在苹果手机上现在原来可以 nfc 了

当然 @GuuJiang 也理解错了一点他们的说法， 他们的说法是说 前端后端各做自己的哈希。
数据库存储的密码在他们的设计里是 后端:hash( 前端:hash(用户输入+前端固定 salt) + 每个用户个人 salt)。

这在后端眼里只是对于本站而言，等于脱了裤子放屁，用户密码由 123 变成了 a2cf ，但攻击者拿到的就是 a2cf ，拿到就能登录，对后端完全没区别。

@dingwen07
@g531956119
@Buges

我赞同 @GuuJiang 的观点，前端不要闲得没事自己做哈希，你们是准备把弱密码库之类的也写个 js 库自己前端做校验吗？然后弱密码策略也前端自己维护一份？比如什么密码包含生日包含连续数字包含账户名这种？

当然如果做加密我不反对，尤其是用非对称的，前端 js 里固定公钥就行，后端可以在注册和登录的时候照常反解回来，然后各种安全服务可以照常调用，弱密码相似密码也都不用前端处理，就是后端高并发的性能会差一些。

而且 https 被监听的问题我觉得不会如后端被脱裤那样容易引起大范围反应，https 要被攻击者解密我只知道让用户手动信任中间人的证书这一种情况。
除此之外我只听说过只有之前沃通还是那个 CA 的 bug 会给人发 gitpage.io 的根域名证书，然后这个 CA 就被浏览器火速拉黑了。

@dingwen07
@g531956119
@Buges
你们说的东西和人家 @GuuJiang 说的是两个概念。
人家说的是 即便监听者拿到的是前端哈希后的值，那在当前网站依然被黑了，对于本站和明文传递没区别。A 网站的用户在 A 网站的密码还是暴露了，攻击者可以随意登录。

而你们在说攻击者拦截了流量会危害到使用相同账号密码的其他网站，A 网站用户泄露的密码会导致 BC 网站同样被可以攻击者登录。

我赞同你们说的存在的问题，但这个问题和人家提的点关联性不大，即便按你们说的加 hash 了，那人家提的 A 网站被攻破了的问题你们并没有扛住了，那为什么说的好像人家说错了一样。

而且强 native -> 而是强 native

看到最后一条楼主的附言我说一句，不是楼主走偏了，而且强 native 功能依赖的如今属于小众需求了。
而互联网范围内 app 的功能大多只需要替代网页访问就好。使用不到太多的 native 功能。包括外国的 fb 、twitter 、也一样，大多数 app 都是内容展示类的，他们需要的 native 功能主要就是摄像头和定位。

比如我曾经接触的一个组，他们是给学校卖物联网教学方案的，定制开发板镶嵌一个屏，装了安卓系统，但应用实际全是 c++写的。界面都是 qt 。因为他们天天搞的熟悉的就是那些，并且还会有一些红外烟感光感之类的非手机硬件设备需要写代码调用。

@x66 见过 es - elasticsearch #滑稽

https 是传输数据全加密的，除了请求的目标 IP ，中间设备是抓不到任何内容的，path 部分 body 体都一样，除非请求发起端被黑了，信任了中间人的证书，然后被中间人劫持。
（题外话，所以不要在公司的加域电脑或者需要安装上网控制的内网上干私人的事，对于 IT 和老板你 https 了也是光屁股的）

这个后端找借口都不会 ， 我教他俩百分百对的。
"Restful 对于某些业务很难抽象，比如网上各种对注册登录的实现，要么破坏规则与其他 restful 不统一，要么强行把简单的逻辑抽象成了复杂还别扭的规则。"

"公司运维有统一请求分析控流组件，每个项目都是统一接入的，而这个组件不支持 url 里的携带变量，要求运维发开升级组件难度很大，影响范围很大并且升级后稳定性无法评估。（或者 这是采购的第三方产品，且除软件外还包含专用防火墙硬件设备，厂家无法支持升级，需要购买新设备替换）"。

就是一个标准统一就好，我个人更喜欢驼峰。
虽然阿里巴巴的标准是全大写，并且目前我们项目领导也要求这样，我也遵守了这样的规范。

DTO 和 HTTP 、URL 、SQL 、NBA 、NASA 、API 、GUI 、REST 一样都是一类专有名词缩写，针对于驼峰命名法而言，我的理解是按照驼峰结构修改，和普通单词一样，按照驼峰方式拼写。
QueryUrl 、UpdateSql 、NbaList 、FakeApi 、Rest 、UserDto 、UserVo 。

而 DTO 、VO 、DAO 这类东西和前面其他专有名词缩写有一点不一样的地方在于它在名字中是存在特定编程含义的，而其他专有名词在技术层面没有任何意义。
NbaList 、CnCity 、这类缩写对于某个新加入项目的人而言与 AList 、BObject 并无区别理解代码改造代码的时候无需了解这个缩写的含义； DTO 和 VO 你看到他们的时候你就知道这个类的用途。

所以我可以理解为什么有人认为该保持全大写，但我个人更倾向于统一用驼峰，不能因为它表达的含义不同就专门例外。

前后端分离指的主要是渲染视图和数据分离， 不一定前端非得有专门的服务器。

比如完全可以直接生成静态的 html ，用户请求之前这个页面就已经生成完成， 然后由浏览器直接渲染这个完整的 html ，再执行 js ，通过 ajax 读取到数据 A ，再把数据也渲染出来。当用户访问其他页面的时候就是访问另外一个 html ，从页头到页脚都重新读取重新渲染不管一样不一样，然后再去读取另一个数据 B 。


但这样就出现了一个最主要的问题，当是搜索引擎爬虫访问或者用户网络不好的时候，他们只能看到一个空框架没有任何数据内容。
为了解决这个问题，所以才又专门准备一个渲染服务器，也就是你说的前端服务器，html 页不再是直接生成好的空框架页面了， 而是可以先读取空框架模版再由渲染服务器去访问后端服务器获取数据，然后生成包含数据的 html 页，这时候再返回给用户。