HTTP/1.1 Allow Response Trailer Headers

[benaadams]

Now (shortly?) reading request header trailers #619; ability to add them to chunked encoding responses?

Currently supported by System.Web (Misleading)

Don't think browsers pay attention to them; but some discussion on whatwg/fetch#34 as to their importance for CDNs etc; and whether to include them in the fetchapi

[benaadams]

Would need design

[halter73]

I don't think this is super important.

If you really want this, I think you should be willing to manually chunk your response which you can do if you explicitly set Transfer-Encoding: chunked. So nothing is topping you from sending response trailing headers today. We just don't make it easy.

[madelson]

@halter73 how do you send response trailing headers using existing APIs?

[halter73]

@madelson I'm not aware of any way to do this using HttpClient APIs. You would probably have to build something on raw sockets.

[Tratcher]

Proposal: Request and response trailer headers belong in their own collections. These should get there own features. These features should also have a HasStarted type flag indicating if the trailers have been started or finished yet. The response trailers feature may even have a Flush method to end the body and send the trailers immediately.

Today kestrel puts request trailers into the normal request headers collection, but this may cause conflicts or concurrent modification errors.

[NickCraver]

I hit a desire for these today, in MiniProfiler. There's now a Server-Timing header, which really can't get its content until quite late in the pipe. While I can send the profiler ID (which is saved at the end of a request, but fetched in another request), putting the entirety of the profiling summary in a header send before anything happens has some fundamental issues with respect to our current linear understanding of space-time.

But Trailers! It's ideal here. At the end of the request (the very last step pretty much), we have a complete picture of what happened. In fact in the examples of Server-Timing, it's even recommended. This is definitely a feature I'd use in MiniProfiler, and I totally agree with them being in their own collection (of the same type).

There is a minor question open here, where in the initial headers collection needs knowledge a trailer exists. I'm not sure the best API for that - perhaps there's just a method (called before headers are sent) that takes a header name, which registers them for the Trailers header sent in the initial collection?

[cesarblum]

There is a minor question open here, where in the initial headers collection needs knowledge a trailer exists. I'm not sure the best API for that - perhaps there's just a method (called before headers are sent) that takes a header name, which registers them for the Trailers header sent in the initial collection?

Yeah, you'd have to signal that you'll set a trailer before the response is started. Otherwise the response would be invalid. If you set trailers early enough that could be done automatically, but this wouldn't work for things like Server-Timing where you set the trailer just as you're finishing the response.

[NickCraver]

Just throwing out ideas - perhaps something like this:

context.Response.RegisterTrailerHeader("Server-Timing");

[Drawaes]

What if the body ends up not being chunked?

[Drawaes]

How about this?
Sample Code

[Tratcher]

Why not just response.Headers.Append("Trailers", "Server-Timing");?

[Drawaes]

Does it write the trailing header?

[Drawaes]

There are 2 issues you have a header you need to write... that has which headers are in the trailer and write the trailing headers themselves. This middleware takes a call back to write the header content later. When you register it indeed populates the response.headers ["Trailers"] for you but it also takes over chunking for you and then calls your call back after writing the zero chunk but before closing doing the last /r/n

Why they didn't call them footers instead of trailing footers I guess will remain one of life's great mysteries

[NickCraver]

@Drawaes much appreciated - I agree that's a tenable solution (some perf increases to be had there), but not something I'd consider doing in a library...that's quite dramatic on the impact to an application to change out in middleware of a profiling library (IMO).

I think that yes we can do this, but without core support, it'd be ethically questionable for me to do that ;)

[Drawaes]

Ethics, meh. Yeah it's a POC not prod ready code, for instance it doesn't handle the case where no body should be sent. But it's tenable, As for the library question if it's a feature people enable or disable then it's up to them. As for the perf if it was optimised, should be able to be pretty much a single method dispatch the rest of the code is very similar to what the chunker is doing now it's just been replaced with a custom one.

As with all things direct framework support would be better.