关于request持久化的一点优化建议

cool

众所周知，Surge脚本类型HTTP Response中$request参数只有
$request.url, $request.method
因内存消耗问题 body及headers 不会支持(这点同意，坚决拥护！)
只能request时缓存，response处提取

但经常会遇到某些API将不同请求参数放入body中，并发多次访问同一地址，
如 $request.url https://abc.com/api
$request.body {action:123}或{action:789}
此时缓存标识ACTION
request时缓存的是{action:123}，若本次响应慢于并发的另一请求，到response处有可能提取到{action:789}

当然也有不优雅的解决方案，通过改写$request.url 显性传递特定标识ACTION123或ACTION789
https://abc.com/api?ACTION123 缓存{action:123}
https://abc.com/api?ACTION789 缓存{action:789}
这样在response处即可根据改写好的$request.url取出相应的持久化数据

所以是否有可能在脚本类型HTTP Response中的$request增加一个隐性传递参数
如 $request.KEY 字符串长度限制在16位以内

@SurgeTeam

SurgeTeam

cool 写入持久化存储时带使用 hashmap 结构带上 key 即可。

cool

SurgeTeam 似乎没有解决我的问题 response处无法靠原始的$request.url, $request.method识别出该response来自哪个$request.body请求

mieqq

cool
可以尝试在 http-request 脚本中获取请求信息，用 $httpClient 自己构造请求发送，得到的响应修改后再直接$done({response})

还是希望能增加多一些 $request 接口

cool

mieqq cool~ 好思路

SurgeTeam

cool 已在最新 beta 版本中加入请求 ID，可用作区分。

cool

SurgeTeam cool~ 赞

ztxtop

SurgeTeam 新加的请求ID若当作存储key，那当surge只跑了request没进response的情况（崩了或其它可能的情况）时，那存储的数据就变垃圾数据无法清除了（因为用户根本不知道这请求ID，也没有存储key显示列表功能）；若使用hashmap结构存储请求ID及数据，那出现并发请求时，hashmap结构数据的存储操作就可能是不安全的（数据覆盖）

还是希望能增加多一些$request数据或再开辟一个临时存储空间，surge启动时清空下这个临时空间的数据，避免存储垃圾数据

ztxtop

SurgeTeam 能否在$request中整一个请求后续流程能读取的空间，跟请求响应体处理那样，让用户可自行设置请求携带的隐性数据，若这样，会去设置携带数据的用户定然会考虑数据的大小

gengjiawen

mac端内存充足，不带request.body确实有点麻烦，跟大家分享下我的解决思路。

我是直接往headers塞入额外数据搞定了。

  if ($request.body?.includes(`user1`)) {
    let headers = $request.headers;
    headers['s_data'] = 'Surge';
    $done({headers});
  }

还是希望支持 HTTP Response 也支持 request body.