> 1. declare ExtraInfo in conf
I used to solve it with this. But this way is too cumbersome. It let
me think about Java's check exception. You have to add a new exception
handler when the function you called has changed. There will be the
same with the ExtraInfo
> Does this also include handling the body of the POST request? I have
encountered this problem before.
Yes
ZhengSong Tu <tzssanggl...@gmail.com> 于2021年8月4日周三 上午11:11写道：
>
> >
> > 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.
> >
