It's unclear that we want to or plan to implement this. In past discussions, the //net team was generally opposed to adding support for HTTP trailers and exposing them as part of the Web Platform.

This is probably better suited through ensuring that "Trailer" attribute is tracked as a feature request via the appropriate status dashboards (e.g. chromestatus.com, https://webkit.org/status/, https://developer.microsoft.com/en-us/microsoft-edge/platform/status/ )

And for those just joining the bug:
https://github.com/whatwg/fetch/issues/34 was where concerns were raised about implementation and the negative signals were expressed. It might be appropriate to close this as "WontFix" and leave chromestatus.com to track any plans (of which there are none at present, AFAIK)

rsleevi@, is there simply no support for trailers in the net stack, does everything work as if they are just arbitrary (expected or unexpected depending on Content-Length) bytes at the end of the response?

tyoshino@, since you filed https://github.com/whatwg/fetch/issues/473, what do you think should be done here? The public signals from "Chrome" now look rather mixed.

Sorry that I've been away from the thread for long time though I was the person who filed it. I intended that the decision whether or not Chrome implements it was delegated to Ryan and David when they chimed in, and louiscryan@ has been representing the customer (gRPC team) directly, and therefore I've not been following that well.

Note also https://github.com/whatwg/fetch/pull/344 where pretty much only Googlers, including a Chrome engineer, reviewed and approved the change to the standard.

I see. I understand that the interaction there might have impressed you that Chromium has switched to just support it. In some of the activities, people just did their job requested (e.g. proof reading, answering question, etc.) without thinking about such a possible implication. There should have been good coordination.

We can also say that it should have clearly confirmed at https://github.com/whatwg/fetch/issues/34 that Ryan and David are fine with the plan given that they stated clear objection as Chromium developers.

For the meantime, it seems we should stop and make sure we get signal from Firefox, Edge and WebKit, and signal from developers in addition to Louis as Ryan suggested in #3 to be able to evaluate the impact and compare it with the complexity to be introduced which has already been briefly estimated by Ryan for Chromium.

> get signal from

Maybe this would happen in response to the bugs filed by Anne https://github.com/whatwg/fetch/issues/34#issuecomment-279470908

Has anyone from the vendors expressed signal in HTTP workshop?
https://github.com/whatwg/fetch/issues/34#issuecomment-235318684

For HTTP, we just ignore trailers.  H2 I'm less sure of (Our low-level H2 code support them, higer layer code just doesn't support getting them for normal HTTP requests, so not sure what happens when we get them, in practice).

I'm with David and Ryan that this is a pretty major time investment with potential security risks, even if we didn't do things like supporting ETags in trailers, and is very likely to lead to compat problems, both between browsers, and between websites and weird proxies.

Removing the HTTP label - very little of the complexity in implementing this is at the HTTP-parsing layer.  It's everywhere else that HTTP responses go through, both in terms of ust passing around data, and in terms of the many, many things that monitor HTTP headers.

(And when I say HTTP "ignores trailers", I believe we just delay sending the EOF message upstream until we see the end of the trailers)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Untriaged -> Available.

There isn't an option on chromestatus.com for "Status in Chromium: Opposed", otherwise I'd add an entry. Can't we just close this issue WontFix?

Ryan: It's unfortunate that this is closed as wontFix, as it would be really useful to gRPC.   We (gRPC) use HTTP/2 trailers in our protocol and it would be helpful if  Chrome surfaced them.   (even if no semantic meaning is attached)

Would you be opposed to a patch to wire the trailers up to the fetch response, if someone from gRPC put the code together?

As noted earlier in the bug, yes, we would be opposed to patches to wire the trailers up to the Fetch response. As Matt summarized in Comment #11, exposing this information has significant, and non-trivial, implementation considerations and risks. This is not just about doing the work (launching), but about making sure that we can support it in an ongoing and secure fashion (reviewing + maintenance for landing), and that's not something we are prepared or able to do at this time.

Ryan: I had read through this, and Matt's comments seemed to be focuses on the time  aspect: "...is a pretty major time investment...".  Also, the Etag support is a semantic change correct?  I am specifically interested in the non-semantic functionality, which would be akin to Chrome ignoring the headers as it does today.  

Also, without any further detail about what "potential security risks", it doesn't seem possible to address them.   Could you add more detail about what kind of risks exist for this?

As I explained previously, the time cost is not a single-cost, but an ongoing resource cost that will be perpetually paid, as every feature will need to consider the interactions with and implications of trailers. Writing the code is, unquestionably, the easy part - reviewing it for correctness, maintaining it for cross-browser interoperability, interacting with the rest of the networking and loading stack are significant and non-trivial costs. As we explained on the issue as well ( https://github.com/whatwg/fetch/issues/34 )

That also discusses security risks. From a product perspective, only supporting it for non-semantic expression is equally not a desirable nor interoperable outcome.

I appreciate your interest, but I think the decision to WontFix is based on a holistic evaluation of the cost of this feature, and leaving it Available for over a year is not a good representation that this has been reviewed, triaged, and actively rejected as something we want to support.

I understand there is a high and ongoing cost with the feature.  I don't have budget for doing it myself, but I think you should take into account the upside value as well.  This would be roundabout but hear me out:

gRPC provides a way to do first class streaming and error handling in a consistent way across browser<->server.  Right now the way this is done is with WebSockets.  If trailers are added, it reduces the barrier for gRPC, which in turn moves streaming and other API calls away from WebSocket and into formal HTTP (whether than be HTTP/2 or QUIC).  Correct me if I'm wrong, but the security of the browser would be easier to understand if substantially all JS interaction was through the fetch API, rather than both fetch and WebSockets.  

Again, I understand there is a high cost (and I actually read that whatwg in its entirety before coming here).  But that said, there is value to adding this functionality, and I am exposed to the requests for this feature more frequently than this issue tracker.  

Thank you for your time.

WebSockets isn't going away at this point, so adding trailers is only an additive cost.

Given that HTTP/2 is gaining support for WebSockets (and thus, by proxy, so is QUIC), doesn't the benefit of supporting trailers simply devolve into a question of whether the gRPC implementation is syntactically cleaner expressed over HTTP Request/Response pairs versus WebSockets?

That is, it doesn't seem like it's a difference of capabilities - a difference that would exist if H/2 didn't support WebSockets - but rather a difference in syntax.

Given that we're not going to deprecate WebSockets anytime soon, because it's part of the Web Platform, reasoning about the security and interactions doesn't see any particular win by supporting trailers. If anything, having the application-layer protocol like gRPC expressed fully using application-layer framing, as required by WebSockets - that is, without conflating the HTTP layer - seems like a win. We can treat the application as fully sandboxed in its impact and influence, without having to worry about semantic confusion between the application-layer expression and the HTTP-layer expression - such as worrying about trailers.

I can't speak authoritatively, but as I understand it, HTTP/2 accepted as an RFC shortly after the gRPC Wire protocol was made.  HTTP/2 is a very good fit for gRPC semantics (and vice versa) due to being developed at nearly the same time.  It was decided at the time that, since HTTP trailers were uncommonly used, and the HTTP/2 was newly minted, depending on them as part of the wire was okay.  (as opposed to duplicating our own header and trailer formats).  Additionally, H2 provides flow control and multiplexing, stream management, pinging, etc. all things that gRPC would support.  

This is to say gRPC was intended to use the features of HTTP/2, not be a layer on top of it.  Given Chrome's involvement with SPDY, QUIC, and HTTP/2, it seems very strange that the features of these protocols would not be made available to applications.

Deprecating WS is not going to happen.  The question I am asking is if  substantially all usage was on vanilla HTTP/2 (possibly with gRPC), would security be simpler? (for both Chrome users and developers)

No, the browser's security model is incompatible with exposing low-level features of HTTP/2 directly. That has always been the case.

The browser's network stack and even an individual socket is used by multiple mutually-distrusting origins at once. Exposing features must always start from that premise and not what low-level knobs exist in the protocol. The low-level transport protocols exist for the browser's net stack to implement the must higher-level APIs exposed to the application in a way that respects the security requirements. They are not there for the application directly.

There are other elements of H/2 that, while specified, are not well-specified nor well-implemented (example: HTTP/2 PUSH semantics, which have a host of problems on the Web Platform).

To the extent Chrome exists to serve the Web Platform and have an opinionated set of features to support, HTTP/2 trailers is not a compelling feature given the existing Web Platform alternatives, but with considerable complexity and challenges in implementation and integration with the Web Platform.

gRPCs usage of HTTP/2 does not simplify, and arguably complicates, the reasoning about how gRPC and the Web Platform interact. That's because the Web Platform will not expose all of the HTTP/2 capabilities to developers (for example, header blacklists or requiring CORS). Thus, as a protocol, using HTTP/2 does not help, and to some extent hinders, the ability of developers to reason about the Web Platform. While it does provide a number of compelling benefits for gRPC developers (such as flow control, multiplexing, etc), that's a great reason to use H/2 - but there are limits to how much the two can be in harmony and serve two very different use cases.

David: If origins do not trust each other, then how can headers be considered substantially different than trailers?  

Ryan: Agree on PUSH; In fact we avoid it completely in gRPC.  As for trailers: there are uses for them that are not feasible to do with Websockets or as a higher layer protocol:

* They indicate if a stream succeeded or failed in a data agnostic way (i.e. as served from a proxy)
* They provide additional error detail when the form of the data frames cannot be modified.
* They are generally safe to ignore (unlike other channels from the server to the browser)
* They are HPACk compressed, avoiding costly extra data being sent over the wire.

I don't have a good answer for CORS (the grpc-web protocol has work around).   The use cases I am thinking of are all from the same origin, which seems like a workable starting point.

I don't wan tot belabor this much further, but I would feel more comfortable accepting the WontFix status if it was clear that Chromium Developers fairly evaluated both the pros _and_ cons before arriving at this decision.  From the discussion here, it mainly seems focused on the cons, which is why I feel the need to speak on Trailers' behalf.

I appreciate your advocacy. We did consider a number of these pros, and while not documenting it here, the costs alone meant that there needs to be significantly more compelling benefits. As noted, there are other technologies in the Web Platform that allow the Web Platform users to achieve equivalent functionality, and as Chromium is focused on the Web Platform, we use that to evaluate the features and protocols we support and invest our limited resources in.

Ryan, did you see this response?
  https://github.com/whatwg/fetch/issues/34#issuecomment-119857226

It feels like you're still arguing against something that is not this proposal.

I appreciated you (like everyone) are resource-limited, but the rejection here seems especially hand-wavy; the security risks referred to above have never been explained, AFAICT, and the nature of the purported compat problems aren't described either. 

@mnot: Yes. We saw it.