插件的咨询 about bumblebee HOT 9 CLOSED

try this
e.Request.Stream.ReadString(..)

from bumblebee.

.

您介绍的方法的确可用，读过post参数后（stream被读过后），即使把stream.position=0置位后，后面正常请求依然会报错。

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

首先感谢解答。
我想实现的是类似于聚合的一个插件，我也看了Bumblebee.Aggregation.dll中的实现，现在例子中的方法只支持get请求。
我想拿到客户端post请求上的参数，在插件中判断，如果包含某个特殊的key, 那么除了完成客户端原来的这次请求外（根据控制台配置的路由），还另外发起一次单独的请求，然后把两次请求的结果聚合一下，返回到客户端。

基于目前插件的机制和开放的api情况，我觉得不修改Bumblebee源码，基本无法实现。

from bumblebee.

Bumblebee.Aggregation的实现其实是基本requesting来做的，拦后自己用httpclient请求响应，并不走网关内部

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

首先感谢解答。
我想实现的是类似于聚合的一个插件，我也看了Bumblebee.Aggregation.dll中的实现，现在例子中的方法只支持get请求。
我想拿到客户端post请求上的参数，在插件中判断，如果包含某个特殊的key, 那么除了完成客户端原来的这次请求外（根据控制台配置的路由），还另外发起一次单独的请求，然后把两次请求的结果聚合一下，返回到客户端。

基于目前插件的机制和开放的api情况，我觉得不修改Bumblebee源码，基本无法实现。

为什么不通过URI / HEADER的参数来判断呢，这样才比较符合实际吧。
另外单独请求，理论上不应该走网关内部，要自己实现。
那么我觉得，插件是可以实现这样的需求的。

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

首先感谢解答。
我想实现的是类似于聚合的一个插件，我也看了Bumblebee.Aggregation.dll中的实现，现在例子中的方法只支持get请求。
我想拿到客户端post请求上的参数，在插件中判断，如果包含某个特殊的key, 那么除了完成客户端原来的这次请求外（根据控制台配置的路由），还另外发起一次单独的请求，然后把两次请求的结果聚合一下，返回到客户端。
基于目前插件的机制和开放的api情况，我觉得不修改Bumblebee源码，基本无法实现。

为什么不通过URI / HEADER的参数来判断呢，这样才比较符合实际吧。
另外单独请求，理论上不应该走网关内部，要自己实现。
那么我觉得，插件是可以实现这样的需求的。

的确如您所说的，参数是可以放在header中的，现在我的变通方案也是这么做的。
之前放在业务参数中传参，主要是为了VUE中调用起来方便。
聚合的请求如果不走网关内部，那么我在控制台设置的server的权重等设置控制项就要自己实现一次。

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

首先感谢解答。
我想实现的是类似于聚合的一个插件，我也看了Bumblebee.Aggregation.dll中的实现，现在例子中的方法只支持get请求。
我想拿到客户端post请求上的参数，在插件中判断，如果包含某个特殊的key, 那么除了完成客户端原来的这次请求外（根据控制台配置的路由），还另外发起一次单独的请求，然后把两次请求的结果聚合一下，返回到客户端。
基于目前插件的机制和开放的api情况，我觉得不修改Bumblebee源码，基本无法实现。

为什么不通过URI / HEADER的参数来判断呢，这样才比较符合实际吧。
另外单独请求，理论上不应该走网关内部，要自己实现。
那么我觉得，插件是可以实现这样的需求的。

的确如您所说的，参数是可以放在header中的，现在我的变通方案也是这么做的。
之前放在业务参数中传参，主要是为了VUE中调用起来方便。
聚合的请求如果不走网关内部，那么我在控制台设置的server的权重等设置控制项就要自己实现一次。

并不需要自己实现。
例如本地网关 http://127.0.0.1:9000/，外网 http://10.0.0.1:9000/
客户端请求：http://10.0.0.1:9000/api1
聚合插件用 HttpClient 额外请求网关地址:http://127.0.0.1:9000/api2 .
这样你两次的请求都是走网关的。

至于 e.Request.Stream 可以尝试下 CopyTo 方法复制一个对象。我没试过，就算成功这也不是个好办法。

from bumblebee.

这个IRespondingHandler现阶段只是用于记录响应的流修改，无法修改调整。这些功能只能修改代码来完成。

首先感谢解答。
我想实现的是类似于聚合的一个插件，我也看了Bumblebee.Aggregation.dll中的实现，现在例子中的方法只支持get请求。
我想拿到客户端post请求上的参数，在插件中判断，如果包含某个特殊的key, 那么除了完成客户端原来的这次请求外（根据控制台配置的路由），还另外发起一次单独的请求，然后把两次请求的结果聚合一下，返回到客户端。
基于目前插件的机制和开放的api情况，我觉得不修改Bumblebee源码，基本无法实现。

为什么不通过URI / HEADER的参数来判断呢，这样才比较符合实际吧。
另外单独请求，理论上不应该走网关内部，要自己实现。
那么我觉得，插件是可以实现这样的需求的。

的确如您所说的，参数是可以放在header中的，现在我的变通方案也是这么做的。
之前放在业务参数中传参，主要是为了VUE中调用起来方便。
聚合的请求如果不走网关内部，那么我在控制台设置的server的权重等设置控制项就要自己实现一次。

并不需要自己实现。
例如本地网关 http://127.0.0.1:9000/，外网 http://10.0.0.1:9000/
客户端请求：http://10.0.0.1:9000/api1
聚合插件用 HttpClient 额外请求网关地址:http://127.0.0.1:9000/api2 .
这样你两次的请求都是走网关的。

至于 e.Request.Stream 可以尝试下 CopyTo 方法复制一个对象。我没试过，就算成功这也不是个好办法。

感谢解答。聚合请求中再向网关发起一次请求，的确是一个好方法。再配合通用参数的存法，应该是可以解决我眼下的问题。

单就讨论这个post参数的话题：
e.Request.Stream.CopyTo ，我之前也试过，可以拿到post参数，但是因为Request的流被读取了，也会影响网关执行完插件后续的代码执行。

from bumblebee.