[fetch] Response content-length header almost always wrong (#67)

While debugging various issues in our SW implementation I've noticed that we get a lot of warnings about bad content-length headers.  It seems this might be a consequence of the current spec:

1) The network response contains a gzip'd body with a content-length matching the compressed length.
2) Response.text() and friends return the decoded data.  So gzip is stripped.
3) Therefore respondWith() will always see uncompressed data stream while the content-length header talks about compressed length.

This problem is propagated through things like the Cache API which preserve the headers.

Should we consider fixing up the content-length header once we know the full length of the stream?  Or force Response to always use chunked encoding?

Right now I think this is just a nuisance, but it seems it could cause problems in the future.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/67