最近在研究HTTP2，发现一个名为“trailer”的对象，RFC说可以追加到请求中。现在我的问题是，是否可以在没有服务器响应的情况下向请求添加预告片。也就是说，客户端和服务器建立连接后，可以直接发送带有trailer的请求吗？
还有一个问题是，如果上面的操作可行的话，它在实际应用中的人口情况如何，我很少能找到它的相关内容。
我尝试在客户端和服务器之间实现一个中间件，它的功能是过滤一些流。我的想法是，一旦在检查其请求标头帧后确定要过滤流，就将 rst_stream 发送到客户端和服务器。但现在我面临一个问题，在客户端向该中间件发送请求后，中间件将检查请求标头帧，如果需要过滤流，则将 rst_stream 帧附加到原始数据，并将其发送到客户端和服务器。但是，由于网络拥塞或其他问题，客户端可能会在中间件向其发送 rst_stream 后继续发送相关流中的数据，这导致我必须检查并删除中间件收到的数据包中的相关帧，否则会出现一次连接错误服务器继续接收来自客户端发送的“RSTed”流的帧。但是由于HEADERS预告片的可能存在，我必须仔细处理需要删除的帧，如果我删除预告片HEADERS帧，客户端和服务器的动态表之间就会产生差异。由于空间有限，在找到拖车之前我无法存储数据。
希望您能帮助我并给出优化的想法
现在我的问题是，是否可以在没有服务器响应的情况下向请求添加预告片。也就是说，客户端和服务器建立连接后，可以直接发送带有trailer的请求吗？
是的。
从技术上讲，您发送一个带有请求信息（URI 和标头）的 HEADERS 帧，后跟零个或多个 DATA 帧，最后是另一个包含预告片的 HEADERS 帧。
您可以在请求和响应中发送预告片。
还有一个问题是，如果上面的操作可行的话，它在实际应用中的人口情况如何，我很少能找到它的相关内容。
这确实是一个很少使用但有时又是必要的功能。
典型用法是在预告片中添加请求或响应中发送的数据的校验和或数字签名，以避免篡改。
gRPC 等协议大量使用预告片；请参阅此处。
关于你所说的其余部分，都是真的。
是的，你必须小心掉帧。
是的，您必须小心正确维护 HPACK 状态。
如果您从头 HEADERS 帧决定是否重置流，那么您不应该将 DATA 帧存储在一边；您只需丢弃它们，直到找到尾部标头帧，您对其进行处理（以维持 HPACK 状态），然后丢弃。
但是，我不得不说，这应该是你不需要担心的，除非你从头开始重新实现 HTTP/2。
如果您使用现有的库，当您的应用程序呈现 HEADERS 帧（标头或尾部）时，HPACK 状态已被处理，因此您的应用程序无需担心：它只决定是否转发帧或放下它。
[免责声明：我是 Jetty 维护者]
如果您使用 Java，通过 Jetty HTTP/2 库，您可以编写一个应用程序，您不必担心 HPACK 状态，而只需实现您的删除逻辑。
有关更多信息，请参阅此处了解服务器和此处了解客户端。