Fiber: 馃 Trailer Headers?

Created on 7 Feb 2020  路  11Comments  路  Source: gofiber/fiber

Question description

馃憢 I was pleasantly surprised by this library and wanted to learn about adding (advocating?) for HTTP Trailer support.

I would like to try this library out with a problem that requires streaming and trailers are very helpful in this case.

Further reading: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer

I reviewed the documentation for Fiber to learn if this was possible. It does not appear to be the case. I did further research and it seems that the underlying http layer does not yet support Traillers (yet) https://github.com/valyala/fasthttp/issues/210. The messaging in the Issue is promising and so I was wondering/hoping if this is something the Fiber team could get behind and advocate for as a desired use case?

Best of luck on this project!

Most helpful comment

I @Fenny @erikdubbelboer I really appreciate your attention to my question. I believe we can close this issue because there is an alternative.

All 11 comments

Thanks for opening your first issue here! 馃帀 Be sure to follow the issue template!

@rhodee, I will leave this issue open for now. I will take a look at the RFC 7230 and see if we can help out to implement this in fasthttp.

You could ask @erikdubbelboer here if he could help implementing this, he is one of the core maintainers of fasthttp.

I will do just that @Fenny thank you for giving this a look!

@rhodee I'm guessing we are talking about receiving Trailers here or responding with Trailers? At least not sending them in an outgoing request right?

Hi @erikdubbelboer I am seeking an approach where I can define Trailer Headers, then set them after writing the chunk response. I think the semantics which best capture my intent are in this URL:

https://golang.org/pkg/net/http/#example_ResponseWriter_trailers

Does that make sense? If not I can try to explain further.

The problem I'm having with this is that fasthttp will always wait with sending a response until the handler function has returned. The only ways to send the response body after the handler has returned are SetBodyStream() and SetBodyStreamWriter(). These functions allow you to either specify an io.Reader to read the body from or write it yourself to an bufio.Writer. Neither of these give us the ability to allow you to add trailers after it all.

So to be able to send Trailers we'll need to add some form of API that allows you to set these after the handler has returned already.

In your use case, what are you using? SetBodyStream or SetBodyStreamWriter?

@erikdubbelboer this is a very helpful discussion. I am starting the fiber project from scratch (moving away from a gRPC implementation) and wanted to use Trailers (which I have in my gRPC implementation). So it is a clean slate 馃槃

What will the trailers be used for? Is your response body so big that you can't wait with returning the initial headers until it is completely generated? I'm curious as I have never seen a use case for trailers before.

Is your response body so big that you can't wait with returning the initial headers until it is completely generated?

They will not be. I use the trailer for timings or arbitrary messages, however it is trivial to meet my needs without Trailers.

I @Fenny @erikdubbelboer I really appreciate your attention to my question. I believe we can close this issue because there is an alternative.

Thanks @erikdubbelboer for jumping in :+1:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

faultable picture faultable  路  3Comments

Terisback picture Terisback  路  3Comments

jeyraj picture jeyraj  路  4Comments

bashery picture bashery  路  4Comments

Badrouu17 picture Badrouu17  路  4Comments