I posted this at http://discourse.wicg.io/ a long time ago and forgot to
email the list about it, so here goes...

## original post

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?

## summary of responses

http://discourse.wicg.io/users/stuartpb seemed interested at the time.

- it's probably more appropriate to store them in navigator instead of
XMLHttpRequest

- it's probably a good idea to discuss this with the Fetch specification
people

- for security reasons, certain headers (e.g. Cookies) should not be
available this way

Reply via email to