I need to serve web resources with unknown size. I work with a modified Jetty server and make sure that the initial response has Transfer-Encoding: chunked and there’s no Content-Length header in the initial response. The problem starts when a browser tries to resume the download. Apparently, Firefox and Chrome have some support for this: they don’t permanently fail when there’s a network error and give you an option to resume.

First I investigated Firefox. I found that in a range response not only Content-Length breaks things, but also Content-Range with a known total <size>

<unit> <range-start>-<range-end>/<size>

Sending this form leads to NS_ERROR_ENTITY_CHANGED. I made sure that the alternative form is used:

<unit> <range-start>-<range-end>/*

where <range-end> is a fake number large enough to fit any real content length. It seems to work: Firefox doesn’t complain if the actual data served doesn’t reach <range-end> and marks the download as successful.

In Chrome unfortunately having an asterisk (unknown) in Content-Range leads to an early fail and the download is permanently captioned as Failed - No file. Only if I send an explicit total <size> the download continues. The explicit size can also be fake (fake <range-end> + 1): Chrome marks the download successful even if the data size doesn’t reach <range-end>.

Which browser doesn’t follow the standard? Both of them? Can I use the approach above in production?