@choury 这和 HTTPS 遇到中间人攻击的效果是一样的，我们只能在通讯被干扰的情况下拒绝加载网页，而不能保证网页一定能加载出来。试想如果中间人就是希望干扰某些内容，而网站开始使用 HTTPS ，中间人是会放弃干扰还是会选择干扰全部的请求？这很难说。

@goodbest 网站标题写了是「 Not Only HTTPS 」呀，并不是说要完全干掉 HTTPS 。

看来是我的 http://nohttps.org 起了作用

工程师在开发的过程中一样会参与很多的讨论，当然绝大部分都是和同事（熟人），可能楼主想要的是和陌生人打交道吧。

而且云主机成本（价格）会持续地下降完全是可以预见的事情。

刚好前排，并不觉得楼主占理，合同已经达成了，除非另有约定就不应该毁约。否则你贷款买了房，房价跌了你就不还贷款了么？至于一次无条件退款，注意这是「无条件」，很多时候你并没有无条件退款（毁约）的机会。

改了代码就一定要进主干么？完全可以放他先去改呀，改完再评估（要不要采用），正好加深下对系统的了解，多好。

@isCyan 昨天发布了第四期~

要看你简历上有没有提到之前的工作经历、提到了多少。如果你用了比较大的篇幅介绍之前的经历和项目，面试的时候自然也会重点问。

@Technetiumer 抱歉 67 楼语序有点错乱，应为： CDN 的问题在于即使 Google 配置了很多 CDN ，但依然不能覆盖到所有的用户，仍然有代理存在的空间（我并不是说不用 CDN ，而是说 CDN 和代理是互相补充的），而且 CDN 所处的位置基本上已经在骨干网了，相比于更末端的代理节点的缓存，会占用更多骨干网的资源。

@shyling 我还是本着能省一点是一点的想法（不过确实有人指出，这种想法会令技术上的复杂度增加，反而需要花费更多的资源在软件开发上）。另一方面是现在网络的延时已经很接近物理极限了，比如中美的延迟极限就是 130ms 左右了，不可能再优化了，而通过代理节点的缓存就可以在一些情况下省掉这个延迟，还是有一定价值的。
@liwanglin12 不是很多网站都会在静态资源的 URL 里加版本来辅助刷新缓存嘛，这种做法可以保留呀。

@skydiver Cache-Control 中的 public 和 private 就用于表示任何人都可以缓存，还是只有浏览器可以缓存。
@msg7086 运营商不是有很多可以在 HTTP 请求中加广告的中间节点么，这些节点就是有能力解析 HTTP 的，加点存储就可以做缓存了。
@bumz 如果是 HTTPS 的话也可以随机地干扰请求造成同样的效果。当然，攻击者可以针对性地干扰特定内容，使这些内容无法被获取，这个确实是个问题。
@Technetiumer 我已经说过了前提是不包括用户数据的资源，按照我的想法，浏览器在收到校验和错误的资源后确实应该拒绝显示和执行（ Subresource Integrity 也是这样要求的，见主贴的附言），对于 HTTPS 连接，攻击者可以随机地干扰请求，造成的效果其实是一样的（一些资源无法被获取），从这个角度来说， HTTPS 也不能防篡改呀。
@Technetiumer CDN 的问题在于即使 Google 配置了很多 CDN ，仍然有代理存在的空间（我并不是说不用 CDN ，而是说 CDN 和代理是互相补充的），但依然不能覆盖到所有的用户，而且 CDN 所处的位置基本上已经在骨干网了，相比于更末端的代理节点的缓存，会占用更多骨干网的资源。
@Technetiumer 我提出的校验和就是为了解决中间节点不可信的问题呀，其实这和 HTTPS 区别不大。如果 HTTPS 是一个小众的东西，那么运营商当然可以肆无忌惮地干扰 HTTPS 连接，迫使你换回可以插广告的 HTTP ，但现在 HTTPS 已经是大势所趋了，所以运营商不敢这么做了。同样的，如果校验和变成一项普遍使用的技术，那么运营商也不敢去通过插广告的方式干扰校验和的工作 —— 因为这样的结果是网页显示不出来，用户会来投诉。

@jigloo SSL （ TLS 和 PKI ）不也是一个标准嘛，如果客户端不遵守标准去校验证书、如果 CA 不遵守标准（规则）去给网站签发证书、如果浏览器和操作系统不去审查 CA ，那 SSL 同样没有可靠性可言。

@jigloo CSS 和 JS 按我的理解应该是不能边下载边执行的，图片的话确实是一个问题（估计这也是 Subresource Integrity 只支持了 script 和 link 的原因，见我在主贴上的附言）。缓存和代理应该尊重 HTTP 中代理相关的头，这本来就是 HTTP 标准的一部分，并不会影响语义。
@wevsty 我是希望浏览器能够支持校验和，前面有人指出有个叫 Subresource Integrity 的特性提供了非常类似的功能，链接见我主贴上的附言。

@msg7086 HTTPS 的中间节点能读到请求内容岂不成了中间人攻击了？我相信 @czb 的意思是可以配置一个有独立的域名和证书的 CDN 来加快资源的获取，但这个过程不是透明的，网站所有者需要去配置 CDN 、更新网站上所引用的资源地址。

而我的意思是说如果我到一个网站的 HTTP 请求经过了若干个路由器或 HTTP 代理，那么其中任何一个路由或代理如果有能力解析 HTTP 的话，都可以按照 HTTP 的缓存规则（例如 cache-control: public ）去做缓存而不是继续转发请求，这个行为对用户和网站所有者都是透明的，这在 HTTPS 是做不到的。

@JJaicmkmy @zsx 所以说这是我不希望看到的呀（浏览器强制我们使用 HTTPS ）
@czb HTTPS 的中间节点（代理）连 URL 都读不到呀
@pmpio @czb 其实是一样的，如果有人干扰所有的 HTTPS 连接的话，一样加载不出来。当然，改成 HTTP 的话，中间人就知道被请求的 URL 了，可以针对性地做干扰。

难道不是应该考虑为什么有 777 的目录么

@clearbug 我发到了网易云音乐上 http://music.163.com/#/djradio?id=340501105
@xiashali 发现是 iTunes 不认我 let's encrypt 的证书，不过订阅后在 Podcast 客户端里是可以看到的。