2.x.x - Trailer headers

[adam-fowler]

Trailer headers are output as the return value from the response body writer

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1e3b93d) 83.08% compared to head (39d0843) 83.12%.

Additional details and impacted files

@@            Coverage Diff             @@
##            2.x.x     #330      +/-   ##
==========================================
+ Coverage   83.08%   83.12%   +0.03%     
==========================================
  Files          92       92              
  Lines        5037     5048      +11     
==========================================
+ Hits         4185     4196      +11     
  Misses        852      852              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Pull request benchmark comparison [ubuntu-latest] with '2.x.x' run at 2024-01-05T10:43:29+00:00
Pull request had performance regressions

[Joannis]

Many users won't use the trailing headers, does it make sense to support an additional closure that's (still) defines as -> Void for users that don't need trailing headers? We could then make the trailing headers return a non-optional, so it's clearly distinct.

[adam-fowler]

Many users won't use the trailing headers, does it make sense to support an additional closure that's (still) defines as -> Void for users that don't need trailing headers? We could then make the trailing headers return a non-optional, so it's clearly distinct.

I tried having two different init one with a handler that returned Void and one with a handler that return HTTPFields but it confuses the compiler. If you have a closure where it isn't obvious what the return value you get an error. I think I have a solution though checkout the last commit.

[Joannis]

I like this a lot better, now one more idea to play with: Can we make the any HBResponseBodyWriter an inout? This would make it harder to incorrectly wield this API.

[adam-fowler]

I'm not sure what you are getting at there. What do we gain from making any HBResponseBodyWriter inout. That closure is called by HTTPChannelHandler and any Middleware that want to process response bodies. ie very few people will be calling it.

Are you seeing a situation where you would want to the write function to mutate the HBResponseBodyWriter?

[Joannis]

No, I don't see a situation where we'd want to mutate. I see a risk in people trying to escape that HBResponseBodyWriter out of this closure

[Joannis]

I don't want to hold up this PR for this topic though, since it's not caused by this PR

[adam-fowler]

ok I see, by making it inout you make it harder but it could still be done. I could make ~Copyable I don't know if that'd help

[adam-fowler]

Forgot that HBResponseBodyWriter is a protocol not a struct

[adam-fowler]

Adding an issue to chase this up #342