I would prefer that they can be exposed.

Can you explain why disallowing to do that is a good idea? You just close an extension point; this shouldn't be done without a very good reason.

I haven't done anything. I just want to document what happens now. If we ever expose trailers that will need to be done through a new feature, as Mark suggests.

(In reply to comment #2)
> I haven't done anything. I just want to document what happens now. If we ever
> expose trailers that will need to be done through a new feature, as Mark
> suggests.

What happens now happens because UAs do not handle Trailers at all. If they did, exposing them as response headers would be the natural thing to do. What's the point in disallowing it?

Because the behavior of getResponseHeader() would change after the point it is normally considered to be stable, depending on the resource you are requesting. That is not acceptable.

(In reply to comment #4)
> Because the behavior of getResponseHeader() would change after the point it is
> normally considered to be stable, depending on the resource you are requesting.
> That is not acceptable.

Why isn't it acceptable? Please provide a concrete reason.

> Why isn't it acceptable? Please provide a concrete reason.

IMO the reason is that the getResponseHeader() / getAllResponseHeaders() part of the spec is basically about documenting the implementations that already exist (and have existed for many years now). 

I don't think there is much compat risk from existing content if we change them, but it's still troubling to introduce a potential not-easily-discoverable incompatibility between browsers by requesting a change in an API that's considered stable. IMHO a new, easily discoverable method would be better for authors here (when such discoverability matters will always be a judgement call, BTW).

Test (asserting that current non-spec'ed behaviour is correct):
http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/getresponseheader-chunked-trailer.htm

I think the way to fix this in the specification is to make it clear in http://fetch.spec.whatwg.org/ that Response's headers do not include trailers.

(In reply to comment #7)
> I think the way to fix this in the specification is to make it clear in
> http://fetch.spec.whatwg.org/ that Response's headers do not include
> trailers.

That would make it impossible to return information from trailers, unless you add a separate API for that. Are you going to do that?

Maybe at some point. I think it would have to be a separate API as the information comes in after the response entity body is in (and definitely after all headers are assumed to be in, with which the entity body is decoded and such). Unless I'm missing something.

(In reply to comment #9)
> Maybe at some point. I think it would have to be a separate API as the
> information comes in after the response entity body is in (and definitely
> after all headers are assumed to be in, with which the entity body is
> decoded and such). Unless I'm missing something.

Well. Support for trailers is spotty because there's a chicken-and-egg problem. Unless I'm missing something, up to now, a XHR implementation was allowed to support Trailers. Don't forbid it now without creating an alternative.

That's not how it works.

> Well. Support for trailers is spotty because there's a chicken-and-egg problem.

The chicken-and-egg analogy isn't necessarily apt for Web technology features. Or, if there is an analogy it may be the case that chunked HTTP response trailers was an egg that no bird wanted to lie on, so it didn't hatch..

In general, it's not a problem as such if a web technology feature dies due to being unused *and* not in demand. I do agree with you that chunked responses and trailing headers fulfil a need, but it seems people are generally not aware of having this potential need.. and thus the feature is not in demand.

HTTP/1.1 has been with us for a while. If there was demand for trailing headers in XHR, browser vendors would have implemented it IMO. As of today, I've verified that IE, Opera, Chrome and Firefox agree on NOT including trailing headers in XHR data, further, I find a grand total of *0* bugs requesting HTTP Trailer support for XHR in Mozilla's, WebKit's and Opera's bug trackers. That's pretty strong evidence that there is very little demand for this feature.

> Unless I'm missing something, up to now, a XHR implementation was allowed
> to support Trailers. Don't forbid it now without creating an alternative.

As I already said, we're documenting a stable API here. If demand emerges we should absolutely add xhr.getTrailingHeader('foo') and xhr.getAllTrailingHeaders() or some such. However, web technology is so complex by now that I guess any feature needs some evangelist, some shiny demo, some articles teasing regular developers with good stuff. It seems odd to assert that technical development depends on PR, but maybe that's the way it is now. So if you want to "rescue" Trailer maybe you need to find somebody who can write about the value on A List Apart or something, and see if demand happens..?

https://github.com/whatwg/xhr/commit/2df06f57db953258c1bac6849a00bf9104fb9add