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

@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 客户端里是可以看到的。

@inet6 我前些天尝试往国内的播客平台传了一下，不得不说实在太麻烦了，要实名认证和审核，每一期都要去分别上传和填写内容摘要（而不是像 iTunes 那样自动从 feed 同步），我有点犹豫以后还是否要在国内的播客平台上维护。另外就是感觉国内的一些播客平台的收听或关注量是有造假的，起码乘了十倍，对于我这种刚起步且还没有做宣传的播客是不可能有那样的收听量的。

你的公众号我是看过一些的，感觉故事性会更强一些，感觉这才是出于休闲的目的去听播客的人希望听到的内容，这方面我还得多下些功夫。

@liubin @pandachow 之前毫无经验 ... 目前是 MacBook 录音， iMovie 剪辑，正在尝试 GarageBand

@cctvsmg 现在看来，这篇文章里的我，的确是我现在所不喜欢的那种人。如果我可以辩解一下的话，当时还未成年，价值观还未成型。
@RihcardLu 这个规则很难被细化呀，就好像很多人说的，要不要区分模拟点击和直接发请求、脚本写出了 Bug 算谁的，总有些情况是定义不到的。事实上也有一些传统企业的规章制度非常严谨和具体，但包括我在内的很多人想要的并不是这样的公司。
@quericy 同意你的说法，其实我是想抛开阿里这个背景去讨论这几个细节问题，但可能是我表达的问题，很多人觉得我是在支持阿里。
@Daniel65536 我仅代表我个人，希望不要影响到对我的公司的看法。
@HankAviator 不知道你是否是在讽刺我，但这的确是我想说的，并不是所有事情都是被规则定义好的。

最近自己录了一档播客，已经录了三期 https://caipai.fm 目前都是计算机或互联网相关的内容。
坦率来说，因为没有录音和剪辑的经验，最后的效果并不是特别理想，也很难和前面朋友推荐的播客一同比较。

其实最大的差别是 Ctrl 和 Cmd 键（毕竟我们大部分时候都在 Ctrl-C 、 Ctrl-V ），我在 Windows 上会把 Ctrl 键换成和 Mac 一样靠近空格，然后把键帽换一下位置。改键的话之前是用一个软件改的，后来买了个支持硬件改键的键盘。

参考我的粉丝团主页，并没有什么人看 https://jybox.net

参考 https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html