First, I am considering whether we need to take cover the huge request body. In
usually, that should upload scenario. And this scenario, it is not a good
resolution that is handled by the ext-plugin.
And then, do we need to consider about compatible?
————
Haochao Zhuang @dmsolr
> 2021年8月4日 上午11:11，ZhengSong Tu <tzssanggl...@gmail.com> 写道：
>
>>
>> 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.
>>
