RE: estimated Content-Length with chunked encoding

Adrien de Croy wrote:
> the use case relating to scanning at a proxy is actually very
> widespread.

I think that is an important use case, but the progress notification proposal 
makes more sense for it, since the client won't even receive the response 
header until the scanning is complete. Plus, you aren't really estimating the 
number of bytes remaining in the response but the amount of time the user will 
have to wait; usually the proxy will know exactly how many bytes will 
eventually be returned.

> Another area we see problems in is in requesting resources which take a
> very long time to generate.  E.g. logging into a webmail server with a
> huge index and number of folders on the back end, it can take several
> minutes before a single byte is sent to the UA.  Humans don't wait that
> long.  They hit the refresh button several times before that.

There are already lots of ways of solving that problem without any extensions. 
But, I can see how the progress notification proposal makes sense for it too.

However, I don't think it makes sense for the server to say "hey, I think I 
will return this amount--no wait, this amount--no wait I was right the first 
time--oh no, I was way off, sorry."

- Brian