Attack on Life ⚔️

例行周四的技术会议时，有人抛出了一个线上故障，Web上有个表格表头过滤，当选择所有值请求时会报错ERR_CONNECTION_CLOSED，但当选择较少的时正常返回200。因为不清楚ERR_CONNECTION_CLOSED的含义，因此排查过程也走了点弯路，这里总结下。

ERR_CONNECTION_CLOSED

Chrome下请求报错但没有状态码，因此一开始并不确定是服务端还是浏览器层面报错。

但一般还是从前端排查起。

最近在做开源项目，临上线前被告知，需要在每个程序文件追加下版权归属。由于时间紧，我也就放弃了寻找自动化的办法，选择了人工编辑，一番体力操作，花了几分钟时间解决该问题

但为了以后可以高效解决同类问题，还是需要寻找下高效/自动化的办法。因为程序文件动辄百十个，人工编辑麻烦且存在失误可能。

借着节假日研究了下IDE下操作的可行性，发现还真有办法。

以下办法是建立在使用JB公司的IDE，比如WebStorm，Intellij IDEA等。

为多文件统一追加版权归属

如果是想为项目中已经存在的文件统一追加版权说明，可以如下操作解决

项目中使用过redux

声明文件的作用

1. 编辑器代码不全，接口提示等feat
2. 类型安全检测

声明文件的创建/使用方式

1. 编写TS类型程序文件，TSC编译tsc --declaration，生成JS文件的同时即生成.d.ts的声明文件
2. 手动编写.d.ts类型文件，一般是面向不活跃的项目，无法在本身包中提供类型声明文件，于是发布到@types，生成@types/packageName
3. 项目中编写.d.ts，同时tsconfig中指向该type文件

今天访问Web突然报错，原来是网站被重定向到HTTPS，而请求API服务仍然是HTTP，Chrome安全策略进行了拦截，从而报错。

为什么会突然出现重定向到HTTPS呢，经过排查，最终发现原来是Chrome下的HSTS导致。

这里围绕着这个问题排查过程总结梳理下。

307

通过network，查看请求在发起后307重定向到HTTPS。而HTTPS安全链接下发起不安全的HTTP请求，浏览器会实现拦截，报错即如此。

307是由谁发起的呢，理论上后台/浏览器都可以做到，查看response ，发现header中有这样一个字段

1

Non-Authoritative-Reason: HSTS

最近在做开源项目，因此可以脱离公司成熟的CI/CD，自己搞搞。为了降低用户部署门槛，因此决定使用Docker来构建部署镜像，解决部署效率问题。

dockerfile

这里贴下构建镜像文件，文件名称比如是build.Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

FROM node:14.17.0 as builder

ENV NODE_ENV production

RUN echo " ------------------Web打包 --------------------"

WORKDIR /management-web

COPY . /management-web

RUN npm install --registry=https://registry.npm.taobao.org
RUN npm run build

RUN echo " ------------------Web容器部署启动 --------------------"

FROM nginx:1.19.2
COPY --from=builder /management-web/build /usr/share/nginx/html
COPY deploy/nginx/conf.d /etc/nginx/conf.d
EXPOSE 80

说明

对于我当前所在team来说，TS几乎已是JS项目标配，估计其他厂也类似。原因很简单，就是类型检测可以为项目保驾护航，同时也TS类型声明本身充当了一部分文档的作用。

不知不觉，使用TS也好多年头，但是有些类型并不常用，必须承认原因就是没懂。因此，这里根据实践和学习，Mark下。

never

关于never需要有几点认识

1. never是底部类型
2. 常用于逻辑分支判断，确保新增的逻辑不会被遗忘
3. void 表示返回为空，即返回undefined，没有任何类型，never 表示永远不存在的值的类型，永不返回。

使用场景

最近生产环境监控系统报告一个前端渲染报错。于是着手分析了下，这里记录总结下

报错信息

this.service.apply(…).then(…).catch(…).finally is not a function

报错环境

• Mac OS 10.14.6 Mojave
• Chrome 92.0.4515.131 最新版
• WebKit 537.36
• ahooks v2.9.6

Web请求抓包，一般使用Chrome network进行分析，如果是HTTPS解密抓包，或者Mac下对iPhone进行抓包，我会使用Surge，但是如果我想具体查看HTTP请求/响应的原始数据，同时了解HTTP应用层之下的传输层等数据的话，那就得更专业的工具，比如说Wireshark。

最近因为分析一个下载问题，了解和使用了Wireshark，觉得Wireshark很强大，同时网上的资料太分散，这里总结下，兴许也可以帮到一些小伙伴。

Wireshark定位

网络协议分析工具

正如一开始所说，Chrome只可以看到应用层协议，比如HTTP，WebSocket，而Surge只可以抓到HTTP请求，如果想完整的学习分析网络协议，Wireshark就非常合适。

最近在跟后端对接压缩包下载遇到了下载OK，解压报错inappropriate file type or format，尝试使用postman却可以正常下载解压，所以很是奇怪。毕竟postman可以，后端不改的基础上前端一定是有解的，于是继续摸索，最终因为进度所赶，改用base64编码传输，解决了这个问题，但没有根本搞清root cause。

借着周末，研究输出下。

报错

报错如上

代码

最近team收到通知，安全团队扫描WEB是遇到有人提交了.DS_Store文件到公司CDN，于是告之告知大家注意这个文件，不要提交。

那问题来了，为什么这个文件会影响安全，我们又如何最大程度规避这个呢，这里总结下。

.DS_Store

先了解下该文件 .DS_Store是Mac系统中产生的一个隐藏文件，记录文件或目录的一些自定义属性

​

比如，这里我创建一个空文件夹，创建一个文件，然后命令行浏览会看到.DS_Store