w3ctag/packaging-on-the-web

Why not use `Content-Encoding`?

yoavweiss opened this issue · 2 comments

Maybe it's just me but I found the use of Transfer-Encoding to indicate a message part is compressed rather confusing. Why can't we use Content-Encoding the same way that it is used for entire messages?

As an aside: I don't think that compressing the entire package would make it less streamable from a decoding perspective. It may not make sense if it contains binary files, but issue 3 seems based on wrong assumptions.

Content-Encoding is a description of the actual content, so decoding it is part of handling to body. Transfer-Encoding means that the body needs to be decoded prior to its handling (like if it was a transient serialization).
Also compressing the whole passage means that you need to decompress everything instead of just skipping until the next boundary and process only what you need.

Content-Encoding is a description of the actual content, so decoding it is part of handling to body. Transfer-Encoding means that the body needs to be decoded prior to its handling (like if it was a transient serialization).

Isn't each part a body of its own? e.g. Content-Type also refers to the entity-body.

Also compressing the whole passage means that you need to decompress everything instead of just skipping until the next boundary and process only what you need.

I agree "seek"-like functionality is not possible without full decompression. That's not what issue 3 is saying though. It talks about "streamability" which I understand as streamed decoding, which is possible.