Open esingtse opened 2 years ago
proxy:日志
curl详情:
使用你提供的curl信息请求,没有发现你说的问题,正常代理。
proxy:日志 curl详情: 使用你提供的curl信息请求,没有发现你说的问题,正常代理。
我按照你的启动方式,proxy http -p :7777
,发现会出现成功的情况,但也有出现
Client端
curl: (52) Empty reply from server
Servrer端
2022/02/23 18:07:21.898899 http/http.go:638 WARN decoder error , from 61.144.144.15:57418, ERR:http decoder data line err:POST http://apissl.gifshow.com/rest/n/feed/selecti
是否proxy sps
跟proxy http
有所不同?
此外,我的版本是commercial_11.4
同样遇到在url中包含符号*(搜狗wx的链接),请求不正常,这是个bug吧
同样遇到在url中包含符号*(搜狗wx的链接),请求不正常,这是个bug吧 不是字符的问题,和字符无关,问题已经定位,下个版本中已经修复。
下个版本:
1、优化了http/sps代理,新增--http-header-buffer
参数,单位字节,设置读取http头部buffer大小,用来支持当http头部很大的时候的情况,默认是4096。
2、优化了http/sps代理,新增--http-header-timeout
参数,单位毫秒,设置读取http头部超时时间,默认是1000毫秒。
下个版本: 1、优化了http/sps代理,新增
--http-header-buffer
参数,单位字节,设置读取http头部buffer大小,用来支持当http头部很大的时候的情况,默认是4096。 2、优化了http/sps代理,新增--http-header-timeout
参数,单位毫秒,设置读取http头部超时时间,默认是1000毫秒。
我的Headers只有 -H "Content-Type: application/x-www-form-urlencoded"
请教一下与buffer大小、timeout有什么关联?
和header无关,这个错误是程序设置的读取头部缓冲区默认1k,你的url超过了1K,所以无法读到后面的头部,自然不能解析头部,和你发的是什么数据,什么url,无任何关系。
有个问题要注意一下的,我改了之前版本的源码。header写死是4096是一个问题。另一个更加严重的问题是,golang 的read方法当数据包没有准备好的时候,他就返回了。所以当数据包比较大的时候,出现的必然bug就是读取的数据还没有完成。你代码里面的structs.go 里面的(*inConn).Read(buf[n:])这个函数,是个bug。看了一下解决方案,比较麻烦,就是解析http包头里面的Content-Length字段,然后再读后面的body出来。fyi https://zhuanlan.zhihu.com/p/351174167
这个地方,新版已经解决。
Current Behavior
通过CURL发起一个POST请求,具体内容如下:
返回的结果为
curl: (52) Empty reply from server
通过proxy输出的debug日志为
根据日志判断,有可能是代理在转发的时候,URL出现编码问题导致的
Possible Solution
将URL scheme由http换成https可以正常请求(但不符合正常请求逻辑,还是希望通过http的方式请求)
URL scheme不变,代理模式由http改成socks5,可以正常请求(由于爬虫暂时没有支持socks5代理,希望用回http代理模式)
Context (Environment)
proxy version is : commercial_11.4
full command is : proxy sps -p :7777 --bind-ip ppp*:7777 --max-conns-rate=0 --authcode xxx --log ~/debug.log -a test:test --debug
system is : CentOS 7.6
Possible Implementation
通过仔细排查,发现是在URL params里面的
device_info
参数导致,其具体的值为经由URL解码之后,发现包含了/字符,也就是
%252F
导致的,如果该字符出现在URL中,会导致http url格式出现问题。请问是否可以针对这种情况兼容处理?