>
> APISIX sends HTTPReqCallReq
> while reply from Runner isn't HTTPReqCallResp:
>
APISIX handle ExtraInfoReq
I feel there is some ambiguity here.
The reply from Runner to APISIX isn't HTTPReqCallResp = Runner wants
ExtraInfo, so why not just tell APISIX that it wants ExtraInfo. Or a
response that specifically identifies ExtraInfo.
I have two suggestions:
1. declare ExtraInfo in conf (has this been discussed before? I can't
remember, sorry), for example:
```
"ext-plugin-pre-req": {
"conf": [
{
"name":"foo",
"value":"bar",
"extra_info": {
"ngx.var.request_start_time": "1454670920"
}
},
]
}
```
2. Before processing the HTTPReqCallResp, the Runner adds a pre-processing
step: checking the required ExtraInfo, and returns a Required ExtraInfo
true/false response.(This is to add to the points I was wondering about)
I prefer the first one. I think developers know exactly what they want from
the ExtraInfo when they write the Runner plugin, so the way it's declared
is clearer.
In some situations, user may want to process request body that is greater
> than 16M.
Does this also include handling the body of the POST request? I have
encountered this problem before.
1 byte type + 3 byte zero + 4 byte length + body.
This is an upgrade to the protocol between Runner and APISIX? Sounds good
to me. This allows Runner to use some common TCP unpacking functions.
*ZhengSong Tu*
My GitHub: https://github.com/tzssangglass <https://github.com/membphis>
Apache APISIX: https://github.com/apache/apisix
Zexuan Luo <spacewan...@apache.org> 于2021年8月3日周二 下午8:54写道：
> Sometimes we need to use some information that can't be predicted
> before running the extern plugin. For example, access the
> `ngx.var.request_start_time` in the extern plugin.
>
> Hence, we add a pair of messages: ExtraInfoReq & ExtraInfoResp.
>
> Now a request from APISIX to Plugin Runner will be like this:
>
> ```
> APISIX sends HTTPReqCallReq
> while reply from Runner isn't HTTPReqCallResp:
> APISIX handle ExtraInfoReq
> APISIX sends ExtraInfoResp
> APISIX handle HTTPReqCallResp
> ```
>
> The ExtraInfo schema is:
>
> ```
> namespace A6.ExtraInfo;
>
> table Var {
> name:string;
> }
>
> table ReqBody {
> }
>
> union Info {
> // Get the `ngx.var.name`
> Var,
> // Get the request body
> ReqBody,
> }
>
> table Req {
> info:Info;
> }
>
> table Resp {
> result:[ubyte];
> }
> ```
>
>
> In some situations, user may want to process request body that is
> greater than 16M.
> Although handling a large body in the extern plugin is discourage, we
> still need to way to adapt it instead of just raise an error.
>
> To solve this problem, let's extend the current rpc header.
>
> Normally we have a header like this:
>
> 1 byte type + 3 byte length + body
>
> Since body can't be zero in all known types, we can introduce an
> extension with zero length placeholder.
>
> Now we can accept such a header to represent a body larger than 16M:
>
> 1 byte type + 3 byte zero + 4 byte length + body.
>
> Body larger than 4GB is unsupported since we will buffer the whole
> body both in APISIX and in Runner.
>
