[Bug 23348] The loaded property doesn't make sense when the body is compressed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23348

--- Comment #7 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Boris Zbarsky from comment #6)
> I think there is some confusion here.

There's some confusion in the meaning of the Content-Length header.  The
Content-Length is the size of the entity body, that is, *after* reversing
Transfer-Encoding.  It's not the number of bytes coming over the network (the
message body).  So, the message body doesn't need to be used here.

>  In general, you start off with some
> data (1).  Then you apply content-encodings to get a different set of data
> (2).  Then you apply transfer-encodings to get a third set of data (3).
>
> What's transferred over the network is (3): the RFC 2616 message-body.

(Note that you're describing this in reverse, from the POV of the sender rather
than the receiver.  That confused me a bit below, until I noticed it and
flipped it around mentally.)

> This is not a spec/definition problem; it's a pure implementation problem as
> far as I can tell.

Browsers should at least zero the field if they can't implement it, not give
bogus data that will turn into a web-compat issue.

A possible change would be for .total and .loaded to be the number of bytes
after decoding C-E, so they correspond with the data actually visible to the
XHR result.  That's more consistent, and for .loaded it's what implementations
are already doing.

However, that would mean .total wouldn't be known when Content-Encoding is in
use, and .lengthComputable would be false.  That would fix the inconsistent
results the OP is seeing, but means you can't show a progress bar for C-E:
gzip.

The advantage of using the entity body length is that the relative length is
known even with C-E, so you can show a progress bar more of the time.  That's
better, but only if browsers will implement it.  If implementors are planning
to fix this, I think the spec is fine the way it is now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 25 September 2013 17:18:48 UTC