{“lastseen”:”2025-09-15T16:34:27″,”description”:”Part of my role at Mozilla is making sure we’re focusing on the right features, and we got onto the topic of fetch upload streams. It’s something Chrome has supported for a while, but it isn’t yet supported in either Firefox or Safari.\\n\\nI asked folks on various social platforms what they thought of the feature, and what they’d use it for. The most common answer by far was \\”to measure upload progress\\”, but\u2026 using it for that will give inaccurate results, and may even lead to bad implementations in browsers.\\n\\nLet’s dig in\u2026\\n\\n## Response streams\\n\\nStreaming responses have been available in all browsers for years now:\\n \\n \\n const response = await fetch(url);\\n const reader = response.body.getReader();\\n \\n while (true) {\\n const { done, value } = await reader.read();\\n if (done) break;\\n console.log(value);\\n }\\n \\n console.log(‘Done!’);\\n\\nThis lets you get the response chunk-by-chunk, so you can start processing it as you receive it.\\n\\nThis is even easier with async iterators:\\n \\n \\n const response = await fetch(url);\\n \\n for await (const chunk of response.body) {\\n console.log(chunk);\\n }\\n \\n console.log(‘Done!’);\\n\\n\u2026but that isn’t supported in Safari. I’ve proposed it for interop 2026.\\n\\nThe chunks are `Uint8Array`s, but you can use `TextDecoder` to get the chunks as text.\\n\\n### But they’re not ideal for measuring download progress\\n\\nYou could try to measure download progress like this:\\n \\n \\n \/\/ THIS DOESN’T ALWAYS WORK!\\n const response = await fetch(url);\\n const contentLength = Number(response.headers.get(‘Content-Length’)) || 0;\\n let downloaded = 0;\\n \\n for await (const chunk of response.body) {\\n downloaded += chunk.length;\\n if (contentLength) {\\n console.log(\\n `Downloaded ${((contentLength \/ downloaded) * 100).toFixed(2)}%`,\\n );\\n }\\n }\\n\\nThe good part is that you’re measuring the point at which you have the data, which is what matters when it comes to download. Let’s say you were receiving three packages via mail \u2013 you’re measuring the point each package arrives in your possession, which is fine.\\n\\nHowever, this all falls down if the response has a `Content-Encoding`, because in that case the `Content-Length` represents the encoded size, but the chunks are _decoded_ chunks. This means your `downloaded` value is likely to exceed the `contentLength` value.\\n\\nThere’s a feature request for a way to get the raw body, without decompressing.\\n\\n## Request streams\\n\\nRequest streams are basically the same as response streams, but for uploads rather than downloads. Imagine a video uploading app that did some transcoding\/processing of the video before uploading:\\n \\n \\n \/\/ Get a video from disk, or from the camera\\n const videoStream = getVideoStreamSomehow();\\n \/\/ Process it in some way, e.g. editing or transcoding\\n const processedVideo = videoStream.pipeThrough(new SomeVideoProcessor());\\n \\n \/\/ Upload the stream\\n await fetch(url, {\\n method: ‘POST’,\\n body: processedVideo,\\n duplex: ‘half’,\\n headers: {\\n ‘Content-Type’: ‘video\/mp4’,\\n },\\n });\\n\\nIn this model, the video processing can happen in parallel with the uploading. More traditional methods would require processing the whole video before the upload begins, which is potentially much slower.\\n\\n### Restrictions\\n\\n`duplex: ‘half’` means that the request must complete before the response becomes available. This ‘reserves’ a future feature where browsers can support handling the request and response in parallel.\\n\\nIf you want to have a request and response in parallel, you can perform two fetches \u2013 one that streams request data, and another that streams response data.\\n\\nAlso, since the `Content-Length` of the request isn’t known, the feature is restricted to transports that are already used to handling request data in chunks, which is HTTP\/2 onwards.\\n\\n### But they’re bad for measuring upload progress\\n\\nI’m not even going to show the code for this because it’s too unreliable.\\n\\nWith _request_ streams, you end up measuring the point at which the data is taken from your stream. In terms of the postal metaphor, you’re measuring the point each package is collected by the courier, which does not represent the delivery of those packages.\\n\\nFetch is the courier. It will take some chunks off your hands and start handling the network parts. Successfully sending those chunks will happen later, or maybe it will fail.\\n\\nThis is normal behaviour with streams, and it helps keep everything running as smoothly as possible in cases where parts of the pipe flow quicker than others. Each stream has a \\”high water mark\\”, which is essentially an ideal amount to buffer.\\n\\n### Using streams to measure upload progress could cause problems in future\\n\\nIf you try to use streams to measure upload progress, the results will be inaccurate, but it may also limit the quality of this feature in future.\\n\\nLet’s say browsers ship this, and do a fairly small amount of buffering. If folks use this for upload progress, it won’t be right, but it might be close enough.\\n\\nThen let’s say a browser discovers that they can get better performance by buffering more within fetch. If large parts of the web are using this feature for upload progress, that browser faces two choices: Ship the change, which means these websites’ upload progress measurements become even less accurate, or avoid shipping the general improvement. I don’t want browsers to end up having to make a compromise here.\\n\\n## How to measure upload progress\\n\\nUpload and download progress is unfortunately a missing feature in fetch. If you want progress events _today_ , the best way is to use XHR:\\n \\n \\n const xhr = new XMLHttpRequest();\\n \\n \/\/ Upload progress\\n xhr.upload.onprogress = (event) =\\u003e {\\n if (event.lengthComputable) {\\n console.log(\\n `Uploaded ${((event.loaded \/ event.total) * 100).toFixed(2)}%`,\\n );\\n }\\n };\\n \\n \/\/ Download progress\\n xhr.onprogress = (event) =\\u003e {\\n if (event.lengthComputable) {\\n console.log(\\n `Downloaded ${((event.loaded \/ event.total) * 100).toFixed(2)}%`,\\n );\\n }\\n };\\n \\n xhr.open(‘POST’, url);\\n xhr.send(blobOrWhatever);\\n\\n## But in future\u2026\\n\\nLuke Warlow from Igalia is currently working on an API for fetch to add progress events for both uploads and downloads.\\n\\nThe API might change before it lands, but right now it looks like this:\\n \\n \\n const response = await fetch(url, {\\n observer(requestObserver, responseObserver) {\\n requestObserver.onprogress = (event) =\\u003e {\\n if (event.lengthComputable) {\\n console.log(\\n `Uploaded ${((event.total \/ event.loaded) * 100).toFixed(2)}%`,\\n );\\n }\\n };\\n \\n responseObserver.onprogress = (event) =\\u003e {\\n if (event.lengthComputable) {\\n console.log(\\n `Downloaded ${((event.total \/ event.loaded) * 100).toFixed(2)}%`,\\n );\\n }\\n };\\n },\\n });\\n\\nThis should give us all the modern benefits of `fetch`, while plugging the progress feature gap!\\n\\nIf you’re interested in using request streams for things other than progress events, there’s an Interop 2026 proposal for them. We also want to gauge developer interest via this survey, or via the interop GitHub thread.”,”published”:”2025-09-15T01:00:00″,”modified”:”2025-09-15T01:00:00″,”type”:”jakearchibald”,”title”:”Fetch streams are great, but not for measuring upload\/downloading progress”,”source”:””,”references”:””,”id”:”JAKEARCHIBALD:86F958B36A61EDE7753356DC1A0F7F12″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/jakearchibald.com\/2025\/fetch-streams-not-for-progress\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-09-15T16:34:27″,”description”:”Part of my role at Mozilla is making sure we’re focusing on the right features, and we got onto the topic of fetch upload streams….<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,161,13,33,7,11,5],"class_list":["post-17458","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-jakearchibald","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n