Re: The case for Content-Unencoded-Length

Hi Roy,

A zstd stream can contain one or more frames, so the decompressed size of an individual frame would not be the full file size. Similarly gzip archives can be concatenated to create a combined archive. We will need to define new compression formats in order for that to work.

Guoye

> On Jul 17, 2026, at 02:58, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> If the decompressed size is known in advance then it should be present inside the zstd format (see Frame Content Size). In general, metadata inside the content coding is vastly preferable to a header field if the format allows for it.
> 
> I think there was also an informational header field for communication of progress (as a percentage) when using chunked. Or maybe that was a chunk extension? Anyway, nobody used it.
> 
> ....Roy
> 
> 
>> On Jul 16, 2026, at 10:48 AM, Guoye Zhang <guoye_zhang@apple.com> wrote:
>> 
>> Hi,
>> 
>> We recently enabled zstd support in Safari and received complaints that downloads from a popular cloud storage website are no longer showing progress and no longer resumable. Turns out that they are doing streaming zstd compression so they don’t know the Content-Length.
>> 
>> Are there interests in standardizing a new header field Content-Unencoded-Length (similar to Unencoded-Digest)? I'm also interested in discussing a new range unit unencoded-bytes for download resumption.
>> 
>> Thanks,
>> Guoye Zhang