Interrogate default outgoing XMLHttpRequest headers, i.e. Accept-Encoding

There’s currently no good way to determine whether or not a browser / environment supports GZIP-deflated content entirely from the front-end. Servers can interrogate the Accept-Encoding header when they receive the request, but client-side JavaScript cannot see this value at all.

This is important when using a CDN that doesn’t facilitate selection of appropriately deflated content (e.g. AWS CloudFront). I’ve had projects where the initial HTML content is dynamically generated only so that the server can pass the Accept-Encoding header back to the client. That way, the client can adjust the other URLs it uses to pick pre-GZIPed files, e.g. blah.js.gz instead of blah.js all the time.

I was initially thinking that navigator.acceptEncoding could just be specified to contain the default outgoing value of this header, but it occurred to me that there are probably other headers where this is handy.

Should this be a function such as XMLHttpRequest.getDefaultRequestHeaders()?

Should all such headers just dangle from the navigator object as in my previous example?

I’d want the acceptable encoding / formats to be readable from navigator, especially since I might care about it in a scenario where I’m not touching XHR (for instance, populating <img> src attributes).

Heck, it would be nice for the other Accept header(s) to be queryable directly off navigator: this way I could read if the browser supports webm, or mng, or whatever image formats too. (Of course, fields like navigator.acceptLanguage are another fingerprinting vector, but they’re already a vector via XHR: it’s not like making clients unable to do it themselves is going to make users safer.)

Some of those headers vary based on context so navigator seems unsuitable. However, navigator.acceptEncoding makes sense. I recommend emailing the WHATWG list for that one. Is there a browser that does not support gzip though? Might be a baseline requirement these days.

True, the vast majority of browsers support it (although Microsoft just broke it in IE11: https://connect.microsoft.com/IE/feedbackdetail/view/950689 ). It stopped being something we really worried about after Netscape, I suppose.

Still, GZIP is not the only encoding format. For example, Chrome sends Accept-Encoding: gzip,deflate,sdch.

I’ve considered conflating GZIP support with either AppCache or localStorage, but it just doesn’t sit right with me.

Would you be willing to email the WHATWG list about the acceptEncoding property to avoid having to do such tests on the initial fetch and rewriting the response accordingly?

Perhaps we should update https://fetch.spec.whatwg.org/ to require gzip as well…

I’ll be on vacation for about a week, but I’ve put this on my Wunderlist and I’ll pursue this when I get back.

Did this ever end up getting picked up again?

Also, this is obvious but somebody should say it: exposing headers to a request, if doing so for actual requests (and not just querying content support), MUST NOT expose things like Cookie.

Sorry, I got real lazy, and then real forgetful. Not a great combination.

I’m just trying to subscribe to the mailing list now: https://whatwg.org/mailing-list#specs

I haven’t got the confirmation email yet, but I’ll follow through with this once that occurs.

I just emailed this to whatwg@whatwg.org . We’ll see how we go from here…

I’m interested in seeing how this works out, since I’m not otherwise certain how stuff is supposed to “graduate” from WICG.

Just one “no” response so far: http://lists.w3.org/Archives/Public/public-whatwg-archive/2015Aug/0008.html