我正在使用新的2.X NEST客户端。这部分很重要，因为有很多重大变化会影响到这里的潜在答案。
以前，我使用Glimpse Elasticsearch插件查看NEST生成的基础查询。但是，看起来该插件不再与2.X NEST兼容。因此，我试图找到一种解决方法来查看JSON查询。这里的问题是访问response.RequestInformation以获取请求正文的旧方法已经消失。它似乎已被ApiCall，CallDetails和DebugInformation的组合所取代。这里的问题是，在所有这些中，请求字节数组为空，除非您将.DisableDirectStreaming()添加到传递给ConnectionSettings的{{1}}实例中。问题在于我使用Ninject使用依赖注入来处理所有这些问题，因此在类似控制器操作的情况下，我无法访问ElasticClient实例来进行此类更改。我想我可以在全局添加ConnectionSettings，但我不知道它的潜在后果是什么，而且这方面的文档令人沮丧地稀疏。
所以，这里有一些答案的途径，我接受的任何一个答案。首先，如果有人设法使用2.X获得Glimpse插件，我很想知道你做了什么。然而，基于底层API发生了巨大变化这一事实，我的假设是插件从根本上被打破，直到某人将其分支为2.X或者Elastic出现了他们自己的版本（据说它在某个未确定的点上出现）未来的）。
其次，如果有一些方法来获取请求正文而不禁用直接流式传输，我只是错过了它。我非常感谢那里的指导。
第三，如果有人对如何在控制器操作级别禁用直接流式传输有任何想法，而不影响我的Ninject设置或全局应用它，请随时插入。
最后，如果来自Elastic团队的人能够启发我关于禁用直接流式传输的影响以及可能产生的潜在问题，那将是很好的，因此我可以确定在全球范围内应用它是否明智或不。
答案 0 :(得分：2)
将.DisableDirectStreaming()设置为true，请求字节和响应字节在内存流中缓冲，以使它们分别通过response.RequestBodyInBytes和response.ResponseBodyInBytes在响应中可用。
默认情况下，它设置为false，因此请求类型为SearchDescriptor<T>，SearchRequest<T>等直接序列化到http请求的请求流，类似地，响应流从响应流中反序列化。因此，将其设置为true的开销是将响应的生命周期内的请求和响应字节保留在内存中（并且GC启动）。
使用连接设置，最好在应用程序的生命周期内拥有一个实例;每个连接设置都会缓存序列化设置，以及字段和属性表达式的缓存。目前还没有办法在每个请求的基础上保留请求和响应字节，即临时内省，但我认为这将是一个有用的补充;我将为它添加一个问题：）
我个人并不过分熟悉Glimpse集成，但我认为由于某些变化，需要更新才能与NEST 2.x合作。简单地看一下，这些变化看起来非常简单。看起来这样做可以在不必将.DisableDirectStreaming()设置为true的情况下完成，但只需在将请求字节写入请求流之前抓取它们。