I often need to generate content dynamically from a servlet / restlet or whatever, and don't know the length ahead of time. If the client is a browser, the progress bar doesn't work properly, because I haven't set the Content-Length header. Is there any way of setting an estimated content length, so the progress bar works "more or less"?
Not clear what you're asking. You can always set the Content-Length header yourself, though it needs to actually match the amount of data you're sending. The standard way to handle dynamic data where you don't know anything about the length ahead of time is to buffer the output, find the actual length, set the header, then dump the output. Not really answering what you appear to be asking, but I think what you're asking is impossible.
The only way to do this (as decribed in an RFC) is not to set the Content-Length header, ie. the response header does not contain a Content-Length line. In this case the browser does not know how long the body is, so the server "tells" the browser that all of the body has been sent by closing the connection.
I'm not sure whether the Java container will automatically close the connection in this case or if you can do it yourself via some kind of Filter.
To answer your question: I do not think that it is possible to give the browser an estimate.
No, the Content-Length value must be the exact content length:
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.
So you cannot send just an estimated Content-Length value to get a progress bar.
If the length of your content is not known beforehand you can use the “chunked” content encoding (as per HTTP version 1.1). This will not solve your progress bar problem, though—and there’s just no way to make it work unless you know how much content you are going to send.