我也写了一个堪称愚蠢的小工具（用来打印接收到的 HTTP 请求）

受到我写了一个堪称愚蠢的小工具鼓舞，遂决定把 23 年写的一个工具发出来，ddrpa/corgi 可以用来打印收到的 HTTP 请求。

这个工具本质上是对下面这段脚本的扩展：

listen_port () {
	while true
	do
		{
			echo -e 'HTTP/1.1 200 OK\r\n'
		} | nc -l -v $1
		echo '\r\n'
	done
}

支持的功能有：

$ ./corgi -h
usage: corgi [-h|--help] [-p|--port <integer>] [--max-printable-size <integer>]
             [--pretty] [--fetch "<value>"]

             Corgi HTTP Request Logger, version 1.1.0

Arguments:

  -h  --help                Print help information
  -p  --port                监听指定端口. Default: 8000
      --max-printable-size  请求体最大打印长度（ 0
                            表示不截断），JSON 和 URLEncoded
                            表单不受影响）. Default: 256
      --pretty              特定类型请求体输出美化
      --fetch               转发请求到指定地址

对接调试接口时，可以在代码有错误（或一行代码都没写）的情况下知道对方发送了什么。

效果演示（监听 8000 端口，打印收到的 HTTP 请求）：

$ ./corgi -p 8000 --pretty

2023/07/06 16:27:32 corgi is waiting on :8000
2023/07/06 16:27:38 POST /proxy?url=/iot/alipayApi/faceAuth/getAlipayUserInfo HTTP/1.1
RemoteAddr: [::1]:57382
Host: localhost:8000
cookie: Cookie_1=value
authorization: Bearer Igp5d444444444444444
user-agent: PostmanRuntime/7.32.3
accept: */*
accept-encoding: gzip, deflate, br
content-type: application/x-www-form-urlencoded
content-length: 98
postman-token: 9a00e0be-f921-4605-b2f3-b577c1e263c2
connection: keep-alive

payload={"username":"admin","password":"wecsnuigb43j@_f"}
method=PATCH

为什么说这个工具很愚蠢，因为：

双方把对接文档写清楚，或使用 Swagger 之类的工具的话，就不需要这样调试了；
我发现有的项目都进预发布环节了，才发现对接有误。因此这个工具是 Golang 编写的，方便直接从 GitHub Release 页面下载二进制文件到预发布环境；

要是您觉得这个小工具愚蠢的比较清澈的话，我还有一堆。

amet

167 天前

@adrianzhang 还有广大的软件开发市场是由中小规模的公司瓜分的，这些公司承接的项目（甚至包括我见过的一些重要的城市基础设施），如果从最佳实践的角度来看（只是看了点 HN 、Thoughtworks 什么的，不敢妄言），确实是十分惊险的。做到那些（不管是日志还是其他）需要：

1. 项目达到一定规模，时间和金钱能够覆盖这样做的成本
2. 业主、项目负责人等能够理解这样做的意图
3. 开发人员认识到这样做的必要性

还有些其他什么七七八八的原因，只能说这条路还有些漫长。

我不能阻止人们把灯泡放进嘴巴里，但是可以做个方便把灯泡取出来的工具（这个比喻有点不恰当，但也差不多意思了）。

好在从我目前的处境来看，2 和 3 多少是比较可行的，所以我也在 README.md 里说了，看到谁再“整活”就“揍”他。

amet

167 天前

@adrianzhang 感谢你的回复，不过我的论点基于「广大的软件开发市场」而不是「互联网产品」。

社交 APP 是软件，负责收取停车费用的也是软件，监测传感器群的也是软件，后者一般不需要各种分析来决定下一步怎么走，它们最主要目的是记录和重建已经发生的问题，避免重蹈覆辙。

如果你建设一个日志服务平台或采购云服务，用户（业主）就会问「为什么我的数据要传输到互联网上/通过互联网发送到你这里？」。如果你为每个软件项目创建自己的，比如 ELK 这样经典而又基础的服务，也许会发现相比于要解决的问题，有时它们占用了太多的资源。