# Estimated-Content-Length Should Exist

An HTML header problem without a solution
html js
October 8, 2023

A recent problem at work cropped up that required creating an HTTP handler where I didn’t know the content size (streaming a multi-gigabyte zip file, created on the fly) before I was finished. I quickly found out that not including `Content-Length` in your HTTP respnose makes downloads look like this:

A non-progress bar or infinite spinny, depending on your browser. This is pretty unpleasant UX, especially when the download can take multiple minutes. However, when creating a streamed response you often don’t or can’t know how big your own response is going to be.

I took multiple stabs at vaguely estimating what the download size would be- but I also found that if you don’t get your `Content-Length` exactly right, your download will hang indefinitely, or your server framework will complain, or any number of other things. `Content-Length` is meant to be exactly right, or not present at all.

Something like an `Estimated-Content-Length` header, exclusively to satisfy these download bars or to just give a vague idea of how big a streamed response will be, would be perfect for this. But to my surprise, there’s no such thing - Even though the idea has been kicked around since 2008!

There’s workarounds, but unpleasant ones - like writing your own file download with File System Access API, streaming a `fetch` call directly into a file. This API isn’t totally available yet across all browsers, and you need to make your own progress bar.

An `Estimated-Content-Length` header has some niche, but very real use cases - big downloads where the file size is not known, because the entire ‘file’ is never in server memory. But hey, what’s one more?

↑ Top

Tags
Tags!
← Previous
Trimming My Site Dependencies
The easy part is done, at least
Next →