关于 GET、POST 的误解

如果密码用 get 发送，那么浏览器的浏览记录就能看到密码，还是有不同的。

这都是常识，如果面试官连这都不知道，那你也别去了

粗略说来，在这个知识点上，你在考面试官和未来共事的团队。

GET 的 URL 会被网络运营商记录, Web 日志记录, 浏览器记录

GET 可以有 BODY ，但一有 BODY 以后 client cache 会完蛋（ undefined behavior ），同时导致 GET 不合 HTTP 协议（ RFC
2616 ）的语义（ The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI ），所以 GET 加 BODY 是一个非常操蛋的搞法

其它都是事实中的事实

关于 GET 和 BODY 的问题建议看下这里，应该会有更深刻的认识，不要被一些“发现规范没写就大叫着新大陆”的论断迷惑了： http://stackoverflow.com/questions/978061/http-get-with-request-body

+ GET 可以包含 body ，但服务器端应当忽略 body 内容

https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3

if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

+ URI 长度协议里写的很清楚，服务器只需要支持自己提供服务范围长度内的 URI 就可以，超长返回 414

https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

+ 有关，标准里确实没有，但安全这件事复杂程度肯定是远超标准的。 GET 的所有数据只能在 QueryString 里传（见第一点）， QueryString 又是个非常容易泄露的地方（ nginx log/referer/browser history ）

+ HTML 是标记语言，我不知道 HTML 的标准哪里会让人误解 POST ／ GET

简单来说，不要看到一篇文章说了些和你认知不同又似是而非的东西就以为这篇文章是对的了，而且人家都贴了标准的链接了，点进去看一下花不了几分钟的

协议只是一种约定，规范是这种约定变成事实标准，但并不是说只能按约定来。

可以在 GET 请求中放 BODY ，只要服务端事先跟你约定好会去处理 GET 请求里面的 BODY 。

至于信息是在 URL 里面还是在 BODY 还是 Header ，非 https 的话其实运营商都能拿到。

放在哪里是因为有 RFC 文档的约定实现，如果客户端按标准实现了，服务端返回不按标准来，会产生一些问题。

反过来讲，如果能解决两端的约定问题，就算不按规范来也不是不行，只不过不具有通用性——其他使用服务的人还得再按非标准规范来实现一次。

@tomczhen 说白了就是基于一个协议生造出另一个协议呗

不赞同文章里面关于 GET/POST 安全方面的观点。

安全本来就是个相对的概念， POST 在降低信息泄露上确实比 GET 好那么一点，这就足够了