我也写了一个堪称愚蠢的小工具（用来打印接收到的 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

103 天前

@adrianzhang 不好意思，之前我将你的 #15 回复理解为「因为汽车工业很发达了，所以道路设施不必考虑自行车」这种论调，此外我还见过一些夸夸其谈的「互联网」开发者，可能不自觉将你带入了。

如果我的理解有偏差，我先道歉。

我不知道之前的发言是否有让你产生一种没见过世面（确实，这个我承认）或是老顽固或是傲慢的感觉。我玩票的项目里，技术方案第一件事就是考虑能不能 Serverless 。集中式日志、CI/CD 、对象存储，以及非实体层面的开发规范、设计准则什么的，相信我，我能够拍板的地方，如果有助于提高生产效率（开发、运维、运营工作） / 系统稳定性（可用服务时间、可维护性） / 用户满意度，是一定会使用的。

我的 #14 和 #18 观点来自我的工作经历。将这种「不正经」视为了常态现象，有一些心理预期，就好像多雨地区生活久了的人不管在哪里，出门都会习惯带伞而不是太阳镜一样。

此外我并没有觉得这个小工具应该有什么「广阔前景」，这也是为什么我称其为“最愚蠢”和开篇就说「希望没人会用到」这种话的原因。

后面的评论我也一并回复，我确实见过 4GB+ 的不连接互联网（或者说在某种程度上禁止将这些信息通过互联网传输）的系统产生的日志。这个系统不由我负责设计/实现，后续也与我没有瓜葛，我只是当时帮忙看看问题并写了 chainsaw 提供点帮助而已，我的团队如果产生了这种问题，就会被我喷 X 。

万物在线互联的愿景很好，也许很快就会到来，但是在那之前肯定是有问题解决问题，总不能干等着吧。

adrianzhang

103 天前

@amet #21
我跟你交流一直不够顺畅的原因在于，你总是用身边统计学证明合理性，而我在告诉你一个更高的视角，更广阔的视角去看待这个工具所处的市场。你的自我否定看似用一个所谓的“愚蠢”标题就表达了，但你对我的回复字里行间都透露着 bonding in your previous view ，一直在告诉我身边统计学是什么什么样子，你真的在第一时间就自我否定后看看别人的建议了吗？拜托！你得好好想想自己为什么要去否定别人而不是仔细看看别人的视角。恕我直言，你这种沟通方式十有八九是因为内心的自卑。

顺便告诉你，国内著名运营商我待过，著名投行我待过，著名互联网公司待过，著名顶级外企也待过，著名大型风口国企集团我也待过。从我所经历的一切看，你#21 描述见过的那点东西只是沧海一粟。国内著名运营商里面也有大把的系统就是这么烂，就是有大量日志存在本地，但这是不规范！再说一遍，不规范！不利于商业不利于运营。存在即合理说的是，因为有历史原因所以它存在，但并不是说现存的一切就该保持原样继续不规范下去。你有开发这个软件并继续跟我较劲的功夫和时间，不如去想想怎么规范运营你的业务，从我的经验中学到点什么。