# Feature request: map appropriate HTTP request methods to update calls

**URL:** <https://forum.dfinity.org/t/feature-request-map-appropriate-http-request-methods-to-update-calls/4303>\
**Category:** Developers\
**Created:** [May 25, 2021, 12:58am UTC](https://forum.dfinity.org/t/feature-request-map-appropriate-http-request-methods-to-update-calls/4303 "2021-05-25T00:58:52Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\
**Post date:** [February 14, 2022, 11:25pm UTC](https://forum.dfinity.org/t/feature-request-map-appropriate-http-request-methods-to-update-calls/4303/26 "2022-02-14T23:25:54Z")

</div>

> [@nomeata](#):
>
> uest will update the counter _and_ return the video? Not sure if returning large volumes of data via update calls is a good idea, but the current interface doesn’t allow “return this data from a query, and also perform an update”.

What are your issues with streaming large files? Is it 206 partial responses? If so see this thread: [Boundary node http response headers](https://forum.dfinity.org/t/boundary-node-http-response-headers/10747)

Basically in the long run the platform should be able to provide partial response capabilities for us (through the boundary nodes), but once they allow `Range` headers to pass through the boundary node whitelist I have a fork of the `certified-assets` canister that implements range requests.

I’m waiting on this for podcast audio hosting on the IC to work better (though it works now if users download the podcasts).

---

_[View the full topic](https://forum.dfinity.org/t/feature-request-map-appropriate-http-request-methods-to-update-calls/4303)._