V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
amet
V2EX  ›  程序员

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

  •  1
     
  •   amet · 104 天前 · 2905 次点击
    这是一个创建于 104 天前的主题,其中的信息可能已经有所发展或是发生改变。

    受到 我写了一个堪称愚蠢的小工具 鼓舞,遂决定把 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
    

    为什么说这个工具很愚蠢,因为:

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

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

    23 条回复    2024-07-05 15:59:32 +08:00
    zapper
        1
    zapper  
       104 天前
    赶早不如赶巧,刚好要用到,喂到嘴边了
    Anakin078
        2
    Anakin078  
       104 天前
    nc -lvvp 8000
    adrianzhang
        3
    adrianzhang  
       104 天前
    请把你的愚蠢小工具都放出来看看。
    lizhisty
        4
    lizhisty  
       104 天前
    @Anakin078 root@VM-12-17-debian:~/LycheeServer/deploy/docker-compose# nc -lvvp 9999
    retrying local 0.0.0.0:9999 : Address already in use
    retrying local 0.0.0.0:9999 : Address already in use
    retrying local 0.0.0.0:9999 : Address already in use


    老哥,这个命令似乎不行啊
    shuxhan
        5
    shuxhan  
       104 天前   ❤️ 1
    挺有意思的
    amet
        6
    amet  
    OP
       104 天前   ❤️ 1
    @adrianzhang 你好,帖子中的[“一堆”]( https://yufanonsoftware.me/make) 是一个超链接。不过我觉得这些工具里最蠢的莫过于 [ddrpa/chainsaw]( https://github.com/ddrpa/chainsaw),是用来解决 `nohup *** > app.log 2>&1 &` 问题的。
    amet
        7
    amet  
    OP
       104 天前
    @Anakin078 我一开始也是用的 netcat ,不过后面希望做到一种“中间人”的效果,即这个请求能被打印出来,同时还能继续被发送到原本的目的地去。顺便还做了点输出结果美化的工作。
    amet
        8
    amet  
    OP
       104 天前
    @lizhisty 看起来像是 9999 端口已经被原程序占用了?你可以让 netcat 换一个监听端口,然后,如果使用 NGINX 的话,可以使用 location 配合 proxy_pass 让请求被转发到 netcat 那里去。
    lsk569937453
        9
    lsk569937453  
       104 天前
    https://github.com/lsk569937453/local-echo-server 。花了一个小时撸了一个 rust 版本的,欢迎大家使用。
    adrianzhang
        10
    adrianzhang  
       104 天前
    @amet 都挺好玩的小玩意。顺带提一嘴,日志处理的实践,基本上都是传专门的日志服务器,很少会在本地生成几个 GB 的日志。你这个工具适用于不规范的 dev 环境,stg&prod 中没有使用场景。如果发现你这个工具有很多人经常用,那说明出了大问题。
    adrianzhang
        11
    adrianzhang  
       104 天前   ❤️ 2
    @lsk569937453 卷的起飞
    catsoul
        12
    catsoul  
       103 天前   ❤️ 1
    说实话我就喜欢这些 simple stupid tools ( simple stupid 是说用 tool 的人)
    abolast
        13
    abolast  
       103 天前
    看起来 op 也是运维
    amet
        14
    amet  
    OP
       103 天前   ❤️ 1
    @adrianzhang 还有广大的软件开发市场是由中小规模的公司瓜分的,这些公司承接的项目(甚至包括我见过的一些重要的城市基础设施),如果从最佳实践的角度来看(只是看了点 HN 、Thoughtworks 什么的,不敢妄言),确实是十分惊险的。做到那些(不管是日志还是其他)需要:

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

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

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

    好在从我目前的处境来看,2 和 3 多少是比较可行的,所以我也在 README.md 里说了,看到谁再“整活”就“揍”他。
    adrianzhang
        15
    adrianzhang  
       103 天前
    @amet 不,并不是这样。日志集中分析处理是互联网标配,证据就是 ELK 等工具的流行,另一个逻辑证据是,应用的日志分析是版本升级等功能的基础,也是商业分析基础数据。所以,除非是特别不正经的网络公司(不靠互联网用户挣钱的公司),都应该实行日志集中处理与分析。
    Jeremial
        16
    Jeremial  
       103 天前   ❤️ 1
    可以看看 traefik/whoami 这个, docker 部署很方便.
    还支持各种选项
    ZColin
        17
    ZColin  
       103 天前   ❤️ 1
    好用爱用 多来点
    amet
        18
    amet  
    OP
       103 天前
    @adrianzhang 感谢你的回复,不过我的论点基于「广大的软件开发市场」而不是「互联网产品」。

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

    如果你建设一个日志服务平台或采购云服务,用户(业主)就会问「为什么我的数据要传输到互联网上/通过互联网发送到你这里?」。如果你为每个软件项目创建自己的,比如 ELK 这样经典而又基础的服务,也许会发现相比于要解决的问题,有时它们占用了太多的资源。
    adrianzhang
        19
    adrianzhang  
       103 天前
    @amet 我不明白你为什么一定觉得我不知道离线软件和在线软件。你非要证明你的软件有用武之地前景广阔??
    adrianzhang
        20
    adrianzhang  
       103 天前
    @amet 你告诉我有多少离线软件市场需要处理本地几个 GB 的日志?占离线软件绝对份额的低功耗设备本身存储容量就不大。其他都是在线软件的天下,而且智能化趋势都看懂了,未来完全离线的市场只会越来越小。
    amet
        21
    amet  
    OP
       103 天前
    @adrianzhang 不好意思,之前我将你的 #15 回复理解为「因为汽车工业很发达了,所以道路设施不必考虑自行车」这种论调,此外我还见过一些夸夸其谈的「互联网」开发者,可能不自觉将你带入了。

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

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

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

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

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

    万物在线互联的愿景很好,也许很快就会到来,但是在那之前肯定是有问题解决问题,总不能干等着吧。
    caoyang5689
        22
    caoyang5689  
       103 天前   ❤️ 1
    确实有意思, 在开发中还是很实用和有价值的。
    adrianzhang
        23
    adrianzhang  
       103 天前   ❤️ 1
    @amet #21
    我跟你交流一直不够顺畅的原因在于,你总是用身边统计学证明合理性,而我在告诉你一个更高的视角,更广阔的视角去看待这个工具所处的市场。你的自我否定看似用一个所谓的“愚蠢”标题就表达了,但你对我的回复字里行间都透露着 bonding in your previous view ,一直在告诉我身边统计学是什么什么样子,你真的在第一时间就自我否定后看看别人的建议了吗?拜托!你得好好想想自己为什么要去否定别人而不是仔细看看别人的视角。恕我直言,你这种沟通方式十有八九是因为内心的自卑。

    顺便告诉你,国内著名运营商我待过,著名投行我待过,著名互联网公司待过,著名顶级外企也待过,著名大型风口国企集团我也待过。从我所经历的一切看,你#21 描述见过的那点东西只是沧海一粟。国内著名运营商里面也有大把的系统就是这么烂,就是有大量日志存在本地,但这是不规范!再说一遍,不规范!不利于商业不利于运营。存在即合理说的是,因为有历史原因所以它存在,但并不是说现存的一切就该保持原样继续不规范下去。你有开发这个软件并继续跟我较劲的功夫和时间,不如去想想怎么规范运营你的业务,从我的经验中学到点什么。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1360 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 515ms · UTC 23:36 · PVG 07:36 · LAX 16:36 · JFK 19:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.