RE: estimated Content-Length with chunked encoding

> If the server could send the unencoded length in the header then the 
> client could provide a perfectly accurate download progress bar as long as it 
> decodes the content-encoding as it downloads. I would be very interested in 
> such an extension and I think UA implementers would be quick to implement it.


This is the specific use cause I was thinking of, when proposing the extension.  Perhaps a better, more specific, way to implement this is by stating exactly what is known.

Instead of "Estimated-Content-Length" how about "Unencoded-Content-Length".  This accomplishes the same thing, without the confusion over the estimation.

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Brian Smith
Sent: Monday, October 20, 2008 9:56 PM
To: adrien@qbik.com; wrowe@rowe-clan.net
Cc: ietf-http-wg@w3.org
Subject: RE: estimated Content-Length with chunked encoding

Adrien de Croy wrote:
> William A. Rowe, Jr. wrote:
> > Adrien de Croy wrote:
> could be interesting.  My original use case was to prevent user
> timeouts due to lack of perceived progress, so all the 1xx responses
> would be sent prior to any data (chunked or otherwise)... but I can
> see some good potential for being able to write to the UI of a UA
> during chunked data download as well - like a multiplexed data stream.

By far the most common case, in my experience, is when the server is 
dynamically compressing the response (e.g. mod_deflate). In that case, the 
server often knows exactly the unencoded length but doesn't know the encoded 
length. If the server could send the unencoded length in the header then the 
client could provide a perfectly accurate download progress bar as long as it 
decodes the content-encoding as it downloads. I would be very interested in 
such an extension and I think UA implementers would be quick to implement it.

I'm not sure that UA builders are going to care so much about the other 
proposed uses. There are already workarounds for those use cases (using AJAX 
and with the progress information encoded in custom message formats). In order 
to be useful for AJAX applications, the information would have to be exposed 
in the XHR object. Further, it is really confusing or the end user to see an 
estimate of progress that is inaccurate, so I doubt UAs are going to be eager 
to display anything that is just an estimate. It seems like a lot of 
specification work, followed by a lot of implementation work, just to show the 
user information that is often likely to be inaccurate and misleading.

> Although I thought chunk extension headers could only occur on the
> final chunk?  Or are they different to attribute extensions... bit
> rusty on those...

I think you are thinking about trailers. Chunk extensions can occur on any 
chunk, AFAICT, according to the specification. However, I wouldn't be 
surprised to see real world interoperability problems with them.

Regards,
Brian

Received on Thursday, 6 November 2008 20:46:18 UTC