Pines
主要内容： 1. 内容脚本（content scripts）和 扩展（extension） 2. 跨插件通信（chrome.runtime.sendMessage(laserExtensionId，） 3. 从网页发送信息（ chrome.runtime.sendMessage(editorExtensionId,） 4. Native messaging ## Message Passing 由于内容脚本（content scripts）运行在 web 页面的上下文中，而不是在扩展（extension）中，因此它们通常需要某种方式与扩展（extension）的其余部分进行通信。 例如，RSS 阅读器扩展可能使用内容脚本（content scripts）检测页面上是否存在 RSS feed，然后通知后台页面以显示该页面的页面操作图标。 扩展（extension）和它们的内容脚本（content scripts）之间的通信是通过消息传递（message passing）进行的。 任何一方都可以 监听（listen）...
实际应用中，如果需要 Websocke 进行双向数据通信，[Socket.io](https://github.com/socketio/socket.io) 是一个非常好的选择。其实 github上面也有通过 JS 封装好的 Websocket 库，[ws](https://github.com/websockets/ws) 可用于 client 和基于 node 搭建的服务端使用，但是用起来相对繁琐，star 相对 Socket.io 较少，所以不推荐使用。 Socket.io 不是 Websocket，它只是将 Websocket 和轮询 （Polling）机制以及其它的实时通信方式封装成了通用的接口，并且在服务端实现了这些实时机制的相应代码。也就是说，Websocket 仅仅是 Socket.io 实现实时通信的一个子集。**因此 Websocket 客户端连接不上 Socket.io 服务端，当然...
在 VSCode 插件开发的中，webview 可以通过 [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables) 访问 VS Code 主题，这些变量以 vscode 为前缀，并且用 - 替代了.，例如 `editor.foreground` 变成了 `var(--vscode-editor-foreground)`： ```css code { color: var(--vscode-editor-foreground); } ``` 更多可用的主题变量，参阅[主题色彩](https://liiked.github.io/VS-Code-Extension-Doc-ZH/#/references/theme-color)。
最近一直没关注 decorators 的提案，居然才知道新的提案都发布了两年了，而且和旧提案不兼容，几乎算是重写了。 一般而言，一个 JavaScript 的特性在达到 `stage 3` 之后可考虑在 production 中使用。而 decorator 至今未能进入 stage 3。不仅如此，decorator 提案到现在为止已有三版草案，尤其第三版是对前两版的推倒重来（前两版是类似于 python decorator 的语义，第三版是静态语义，类似于弱化的宏），但是这三版都无法推进到 stage 3（主要的障碍来自于引擎厂商）。 注意现在 TypeScript 所实现的 decorator，基于第一版的草案。 **TS 的装饰器遵循了旧的 提案，然后又加入了一些自己的东西。如装饰 feild 和...
### no-Store与no-Cache响应首部 HTTP/1.1 提供了几种限制对象缓存，或限制提供已缓存对象的方式，以维持对象的新鲜度。no-store 首部和 no-cache 首部可以防止缓存提供未经证实的已缓存对象: ``` Pragma: no-cache Cache-Control: no-store Cache-Control: no-cache ``` 标识为 `no-store` 的响应会禁止缓存对响应进行复制。缓存通常会像非缓存代理服 务器一样，向客户端转发一条 `no-store` 响应，然后删除对象。 **标识为 `no-cache` 的响应实际上是可以存储在本地缓存区中的。只是在与原始服 务器进行新鲜度再验证之前，缓存不能将其提供给客户端使用**。这个首部使用 `do- not-serve-from-cache-without-revalidation` 这个名字会更恰当一些。 HTTP/1.1 中提供...
## Expires响应首部 不推荐使用 Expires 首部，它指定的是实际的过期日期而不是秒数。HTTP 设计者 后来认为，由于很多服务器的时钟都不同步，或者不正确，所以最好还是用剩余秒 数，而不是绝对时间来表示过期时间。可以通过计算过期值和日期值之间的秒数差 来计算类似的新鲜生存期: ``` Expires: Fri, 05 Jul 2002, 05:00:00 GMT ``` 有些服务器还会回送一个 Expires:0 响应首部，试图将文档置于永远过期的状态， 但这种语法是非法的，可能给某些软件带来问题。应该试着支持这种结构的输入， 但不应该产生这种结构的输出。
## 实体标签和最近修改日期优先级 - 如果服务器回送了一个实体标签，HTTP/1.1 客户端就必须使用实体标签验证器。 - 如果服务器只回送了一个 Last-Modified 值，客户端就可以使用 If-Modified-Since 验证。 - 如果实体标签和最后修改日期都提供了，客户端就应该使用这两种再验证方 案，这样 HTTP/1.0 和 HTTP/1.1 缓存就都可以正确响应了。 除非 HTTP/1.1 原始服务器无法生成实体标签验证器，否则就应该发送一个出去， 如果使用弱实体标签有优势的话，发送的可能就是个弱实体标签，而不是强实体标 签。而且，最好同时发送一个最近修改值。 如果 HTTP/1.1 缓存或服务器收到的请求既带有 If-Modified-Since，又带有实体 标签条件首部，那么只有这两个条件都满足时，才能返回 304 Not...
@UniKylin 哈哈，感谢～
## 证书与数字签名 公钥证书(Public-Key Certificate，PKC)其实和驾照很相似，里面记有姓名、组织、邮箱 地址等个人信息，以及属于此人的**公钥**，并由 `认证机构(Certification Authority、Certifying Authority, CA)` 施加 `数字签名`。只要看到公钥证书，我们就可以知道认证机构认定该公钥的确属于此人。公钥证书也简称为 `证书(certificate )`。 鲍勃给苏珊回信，决定采用**数字签名**。他写完后先用Hash函数，生成信件的`摘要（digest）`。然后，鲍勃使用私钥，对这个摘要加密，生成`数字签名（signature）`。鲍勃将这个签名，附在信件下面，一起发给苏珊。苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。 后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找 `证书中心（certificate authority，简称CA）`，为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成 `数字证书（Digital Certificate）`。 > 这里有两对密钥： > - 一对是服务器自己的 公钥（加密在证书里面）和私钥（一般服务器自己保留），这对密钥是在HTTPS握手阶段使用，用于协商出 对话密钥（session key）。 > - 另一对是认证机构的公钥和私钥，私钥由认证机构自己保留，公钥公开。...