我们知道，对于没有纳入版本控制的文件，我们可以使用.gitignore文件来忽略它们。
但是，对于已经纳入版本控制的文件，我们要怎样忽略对它们的修改呢？
简单介绍向。
关键词： 免费、个人用户、拥有域名 + 主机
主要是默认为常规文件夹，以及去除文件预览
总的来说，经典的Web框架会将每个HTTP请求回复抽象为两部分： Request, Response。
其中Request包括Scheme、Method、HTTP Version、Url、Headers、Body等；Response包括Status、Headers、Body等等。
像Cookie、User-Agent、Host、Query/Post参数等则更加细节，是对Url、Headers、Body的进一步处理。
但有一个问题，这些框架的逻辑，每一次请求更加像是单向的数据流。Client每一次将请求发送(至少是除了Body以外的部分)给Server端完毕后，Server端再处理给出回应。
像特殊情况，上传超大文件这种，一般都是要自己实现的，主要是针对Request的Body进行一些解析实现。
不过虽然开始处理时没有收到完整的数据，但是Body的大小其实在Content-length里是已知的。Server也是在保存文件成功或者失败以后再给Client答复。
Request的Body大小一般来说是已知的，写在Content-length里，当然也可以未知，例如Transfer-Encoding: Chunked通过指示每一份内容来做分割和控制，不过极其少见，估计也没多少场景中会用到这个。
Response的Body大小一般来说也是已知的，写在Content-length里，当然也可以未知，通过Transfer-Encoding: Chunked一段一段的写。
(当然http2里面这个被禁止使用了，详见MDN)
是的，理论上你可以通过Chunked+ Chunked来实现一个双向数据流，至少本地可以跑通。但是会有缺陷，就像TCP的粘包一样，中间层可能会缓存Chunked0、Chunked1、…ChunkedN甚至等到结尾再传给你。
毕竟逻辑上的普遍情况是Server端收到完整Request后，再返回Response，之后当次HTTP请求算是跑完了一整个流程。
我们考虑以下场景：
实际上，可能在上述第二步和第三步就会卡住，无法实现。
所以，讲这么多最简单的还是Websocket。 通过Client通过HTTP GET附带Upgrade请求, Server 回复 101消息表示请求升级。接下来则完全不必按照Websocket来了，因为中间层不会浪费资源去解析或截留缓存接下来的内容。
官方文档已经整理得挺好的，这里额外补充一些注意事项
有两个使用场景：
- PC端禁止火狐更新已经有2年了，现在想升一下级(然后再禁止😳)。
- Android端使用Beta版本，通过
about:config设置DoH，绕过某些DNS污染(主要是不需要开其它的东西，也不是手机的全局配置，省电)。正好有点关联（都是火狐），放在一起做个笔记。
接上文。
在入门的时候并不能全方位地看待问题，有时候会忽略一些显而易见的知识，现在回过头梳理，把前面的补起来。