Adrian Cole

``` io.reactivex rxnetty-http 0.5.2-rc.4 io.reactivex rxnetty-common     0.5.2-rc.4 io.netty netty-buffer 4.1.5.Final io.reactivex rxjava 1.1.5 ```

I referenced some upstream issues on fasthttp as at some point it would be nice for these to be in the standard library underneath as well. Regardless, we'll need apis...

@antJack ok I think there are a couple things then. one is that fasthttp doesn't work with trailers, yet. https://github.com/mosn/mosn/issues/2145#issuecomment-1282305959 When we update here, we need a different type for...

My first thought was to add the extra apis to the existing http request/response types here https://github.com/mosn/pkg/blob/master/protocol/http/types.go another way could be to define new types RequestTrailers and ResponseTrailers, if that's...

I will work on an implementation, as after we should cut a version of api, pkg so that https://github.com/mosn/holmes/pull/129 and then eventually dapr can have api/pkg version alignment

sounds good. My plan was that even if the ResponseTrailers type is backed by fasthttp RequestHeaders one, the call sites don't change. I think we are eye-to-eye!

@antJack there are a few glitches we'll run into with fasthttp because the trailers are comingled with the headers. For example, logic like this either needs to be inaccurate or...

thanks for the advice @antJack!

@antJack I think maybe it is a good idea to release api and pkg just the version updates before I do this change. Then after we can follow-up and make...

cc @taoyuanyuan on ^^ basically I think safest way is to tag api/pkg before I change any logic in it, mainly to adjust for vendoring go 1.18 and fasthttp version...