WEBVTT 00:00.000 --> 00:14.000 Okay, thank you, everyone, and now we're welcoming my use plan for resumable uploads on the web. 00:14.000 --> 00:15.000 Good for users. 00:15.000 --> 00:16.000 Thank you. 00:22.000 --> 00:24.000 The last talk was on security. 00:24.000 --> 00:26.000 That's always a bit tough to swallow. 00:26.000 --> 00:29.000 This one's going to be a bit easier to digest, I promise. 00:29.000 --> 00:32.000 It's about resumable uploads. 00:32.000 --> 00:34.000 My name is Miles Kleidel. 00:34.000 --> 00:38.000 I work as a back and engineer as stream currently. 00:38.000 --> 00:42.000 I'm building a lot of back and services for cloud services. 00:42.000 --> 00:44.000 But this story isn't about me. 00:44.000 --> 00:45.000 It's about file uploads. 00:45.000 --> 00:52.000 And we're going to start where to all begin with the mighty humble input element, the file type. 00:53.000 --> 01:01.000 As far as I can tell, that was first introduced in RFC 1867 in 1995. 01:01.000 --> 01:03.000 I'm not sure if it existed before that. 01:03.000 --> 01:07.000 I wasn't born though, I wasn't on internet, but at least that's what I found. 01:07.000 --> 01:16.000 And it's a really powerful element, because for the first time you really had the opportunity to transmit files from your user's device to the server. 01:16.000 --> 01:20.000 And you have to do it like you wrap it in a form element. 01:20.000 --> 01:22.000 You add some submit button to it. 01:22.000 --> 01:25.000 And then it's submitted as a multi-part request to your server. 01:25.000 --> 01:29.000 That's, yeah, you see the ink type, multi-part form type. 01:29.000 --> 01:32.000 That's how it's transmitted to the server site. 01:32.000 --> 01:36.000 And it's nice that works great until it doesn't. 01:36.000 --> 01:41.000 And there's especially two situations where you will run into issues with this. 01:41.000 --> 01:44.000 The first of all is if you have unreliable networking. 01:44.000 --> 01:46.000 We all know this. 01:46.000 --> 01:48.000 Move mobile cellular data. 01:48.000 --> 01:52.000 We constantly run into situations where we don't have receptions. 01:52.000 --> 01:54.000 The receptions incredibly slow. 01:54.000 --> 01:58.000 You know, I'm not sure who of you has reception down here, I don't. 01:58.000 --> 02:01.000 So we constantly run into these issues. 02:01.000 --> 02:09.000 And of course if the upload is ongoing and suddenly the network disappears, then the dialogue load is basically fresh. 02:09.000 --> 02:13.000 And this gets especially worse if you have large files. 02:14.000 --> 02:16.000 Files sizes are constantly increasing. 02:16.000 --> 02:18.000 You know, there's a video recording being made here. 02:18.000 --> 02:21.000 I'm not sure how big that video recording is going to be. 02:21.000 --> 02:24.000 It's going to be in the gigabytes, terabytes. 02:24.000 --> 02:28.000 And if you transfer large files and then suddenly the network disappears, 02:28.000 --> 02:32.000 users are going to be frustrated because your upload is broken again. 02:32.000 --> 02:37.000 And all you can do is then again upload the same file again. 02:37.000 --> 02:38.000 Try it again. 02:38.000 --> 02:40.000 This waste resources. 02:40.000 --> 02:42.000 This annoys the user. 02:42.000 --> 02:45.000 This is just a really inefficient process. 02:45.000 --> 02:49.000 And like these two situations, they don't. 02:49.000 --> 02:52.000 They aren't distinct, right? 02:52.000 --> 02:57.000 Many people record videos on your phones and try to share them with their family. 02:57.000 --> 02:59.000 Upload them to the cloud. 02:59.000 --> 03:04.000 So these situations, unreliable network and large files, they constantly happen together. 03:04.000 --> 03:07.000 So how can we do better, right? 03:07.000 --> 03:10.000 We want to have a great user experience. 03:10.000 --> 03:12.000 So how can we make uploads better? 03:12.000 --> 03:15.000 Well, there's a zoom will upload for this. 03:15.000 --> 03:17.000 And this isn't a new idea. 03:17.000 --> 03:21.000 Resumable uploads have been around for basically ever. 03:21.000 --> 03:24.000 This isn't a new problem we just thought about the last year, 03:24.000 --> 03:27.000 but this has been around forever. 03:27.000 --> 03:31.000 So how can we improve the situation? 03:31.000 --> 03:34.000 So let me try to illustrate this. 03:34.000 --> 03:38.000 On the left hand side, this phone is supposed to be a client. 03:38.000 --> 03:42.000 On the right hand side, this cabinet is supposed to be a server. 03:42.000 --> 03:48.000 And there's a small video between that that we want to transmit from the client to the server. 03:48.000 --> 03:50.000 Now the upload begins. 03:50.000 --> 03:51.000 Everything's going fine. 03:51.000 --> 03:55.000 But suddenly, we have an interruption in our connection. 03:55.000 --> 04:04.000 And the connection is that severely halted that it even TCP retransmissions can't help anymore. 04:04.000 --> 04:08.000 Now with normal traditional uploads, this will be lost. 04:08.000 --> 04:10.000 We have to start from zero again. 04:10.000 --> 04:20.000 With resumable uploads, we change this by making the server keep track of how much data it received and what data it received. 04:20.000 --> 04:23.000 This is illustrated by this small cloud there. 04:23.000 --> 04:27.000 In our example, the server received about 50%. 04:27.000 --> 04:32.000 It retains the data because this allows the client to resume afterwards. 04:33.000 --> 04:36.000 There's one important step before I can resume. 04:36.000 --> 04:41.000 And that is the client has to offer the server how much data did you receive. 04:41.000 --> 04:49.000 This is an important step because the server might have received less data than a client sent. 04:49.000 --> 04:53.000 Now in our case, the server received about 50%. 04:53.000 --> 04:56.000 So it tells the client, hey, I got 50%. 04:56.000 --> 04:58.000 I only need the remaining data. 04:58.000 --> 05:00.000 I don't need the first half of the file. 05:00.000 --> 05:02.000 And that's exactly what the client does. 05:02.000 --> 05:07.000 It just uploads the remaining 50% as indicated by this half error down there. 05:07.000 --> 05:09.000 And then we're all happy. 05:09.000 --> 05:13.000 The upload succeeded. The file was transferred from the client to the server. 05:13.000 --> 05:17.000 And we didn't have to retransmit the first half of the file. 05:20.000 --> 05:23.000 No more duplicate transmissions. That's nice. 05:23.000 --> 05:27.000 This is a vast improvement for user experience. 05:28.000 --> 05:33.000 It allows uploads to automatically recover from transient failures. 05:33.000 --> 05:38.000 I've talked about connection drops that are usually a common one. 05:38.000 --> 05:42.000 But it can also be because by networks which is right. 05:42.000 --> 05:45.000 Right now in the Wi-Fi you go outside of the Wi-Fi range. 05:45.000 --> 05:52.000 You phone switches to cellular and then the network can drop and the upload can halt. 05:52.000 --> 05:58.000 It can also be that the server crashes, that the proxy crashes, that your client crashes. 05:58.000 --> 06:06.000 It can also be a user error that I'm accidentally turning off my phone while my 10 gigabyte video upload is running. 06:06.000 --> 06:08.000 And then it's lost again. 06:08.000 --> 06:12.000 This is all annoying and can be avoided with presumably upload. 06:12.000 --> 06:17.000 But besides this error recovery and this resilience aspect, 06:17.000 --> 06:25.000 there's also another aspect that it offers new capabilities to the user interaction. 06:25.000 --> 06:29.000 Can also allow the user to simply pause and resume the upload as they want. 06:29.000 --> 06:33.000 They usually know best what their network conditions are going to be. 06:33.000 --> 06:37.000 They know best when it's a good time to upload. 06:37.000 --> 06:42.000 But it also gives the device itself more capabilities. 06:42.000 --> 06:50.000 For example, when you're entering a video call and you're already on a connection that has, 06:50.000 --> 06:52.000 let's call it says a less bandwidth. 06:52.000 --> 06:57.000 You don't want to have uploads in the background like from your backup. 06:57.000 --> 07:00.000 Be running and ruining the video call. 07:00.000 --> 07:08.000 So you could have the operating system or the browser automatically pause uploads that are less priority. 07:08.000 --> 07:12.000 Then, for example, video calls. 07:12.000 --> 07:16.000 And therefore, again, improving the experience of the video call. 07:16.000 --> 07:22.000 But it's also possible to pause the upload space on network conditions, right? 07:22.000 --> 07:28.000 Like, I know if my device recognizes that it's which is from Wi-Fi to a meter cellular connection. 07:28.000 --> 07:34.000 I don't want to be wasting my entire volume on my meter connection with upload. 07:34.000 --> 07:38.000 So I can also just help me in the background when I'm back home again. 07:38.000 --> 07:41.000 Dresumable uploads allows us to do it. 07:41.000 --> 07:43.000 It can say, okay, just pause this upload. 07:43.000 --> 07:47.000 I'll resume it in an hour when I'm back home. 07:47.000 --> 07:51.000 And all of these benefits can be brought to you by resumable uploads. 07:51.000 --> 07:54.000 As mentioned, this isn't a new idea. 07:54.000 --> 07:57.000 People have been doing this for quite a long time. 07:57.000 --> 08:03.000 But in the early days, you usually have to choose one of the lesser eagles. 08:04.000 --> 08:09.000 Either you go and implement your own proprietary solution for this. 08:09.000 --> 08:13.000 This is what has been done by big platforms like YouTube or Dropbox. 08:13.000 --> 08:16.000 They all have their own implementation of something like this, 08:16.000 --> 08:20.000 but these are not accessible to you unless you work there. 08:20.000 --> 08:26.000 There are, and where are few open source projects that targeted exactly this problem. 08:26.000 --> 08:30.000 But they were usually focused on either a specific platform, 08:30.000 --> 08:32.000 such as the web. 08:32.000 --> 08:35.000 But that didn't make them usable on Android on iOS, 08:35.000 --> 08:42.000 or when you wanted to integrate it with an external API that you provide to your customers. 08:42.000 --> 08:47.000 Or it was specific to a specific stack like PHP on the back end. 08:47.000 --> 08:51.000 But whatever you're running Python or something else, then you can't use it. 08:51.000 --> 08:54.000 So there wasn't really a standard for this. 08:54.000 --> 08:57.000 There wasn't a common way to do this. 08:57.000 --> 09:02.000 And we ran into exactly this problem in 2013, 09:02.000 --> 09:05.000 when we wanted to offer reasonable uploads on our platform. 09:05.000 --> 09:07.000 And we thought, okay, what can we do? 09:07.000 --> 09:10.000 We build our own solution that is proprietary. 09:10.000 --> 09:13.000 But we decided to do something else. 09:13.000 --> 09:18.000 And we started an open source project called TUS.IO in 2013, 09:18.000 --> 09:21.000 with exactly the goal of improving the situation. 09:21.000 --> 09:25.000 Instead of creating another specific implementation, 09:25.000 --> 09:30.000 we started with designing an open HTTP-based protocol 09:30.000 --> 09:33.000 for reasonable uploads. 09:33.000 --> 09:36.000 The designing a protocol is actually pretty simple. 09:36.000 --> 09:41.000 All you do is you write down a spec that can be as loose or as vague as you want it to be. 09:41.000 --> 09:44.000 You publish it on GitHub or your own domain. 09:44.000 --> 09:50.000 And then that's it. You're a protocol designer. 09:50.000 --> 09:55.000 Besides that, what the benefit of a protocol is, 09:55.000 --> 09:58.000 that it is the couple from the implementations. 09:58.000 --> 10:02.000 So the protocol can involve and then you can have different implementations of these. 10:02.000 --> 10:07.000 And all of these implementations will work together if they obey to the protocol. 10:07.000 --> 10:11.000 And that is exactly what kind of came out of this. 10:11.000 --> 10:16.000 We fostered a community that created many implementations. 10:16.000 --> 10:20.000 We also create a few implementations. 10:20.000 --> 10:24.000 But this is really the benefit of having a protocol and then different implementations. 10:24.000 --> 10:25.000 They can all interrupt. 10:25.000 --> 10:30.000 And one of the best way I think that the can be shown is 10:30.000 --> 10:37.000 the TUS project and its implementations are not only used by applications internally. 10:37.000 --> 10:44.000 But the upload protocol is also used in external API from different organizations. 10:44.000 --> 10:46.000 I'm not endorsing these companies. 10:46.000 --> 10:49.000 For example, if you upload stuff to cloudflare, 10:49.000 --> 10:52.000 you may be actually using the TUS upload protocol. 10:52.000 --> 10:54.000 And that's kind of the power. 10:54.000 --> 10:57.000 It's not a specific implementation that we're building, 10:57.000 --> 11:01.000 but we're building an open protocol that can be used by anybody. 11:01.000 --> 11:05.000 I want to give a brief shout-out to transloaded who have been sponsoring a lot of this. 11:05.000 --> 11:10.000 I'm very important quite a lot of money in there and enabling people to work on open source. 11:11.000 --> 11:13.000 So enough talking about this. 11:13.000 --> 11:16.000 Now how does this protocol actually look like? 11:16.000 --> 11:18.000 We haven't discovered this yet. 11:18.000 --> 11:22.000 So let's get back to the example from the beginning. 11:22.000 --> 11:24.000 We have our client. 11:24.000 --> 11:26.000 We want to upload the video to the server. 11:26.000 --> 11:28.000 How does this work? 11:28.000 --> 11:36.000 The client initiates the upload by announcing it to the server through a simple post request, for example. 11:36.000 --> 11:39.000 The post request includes some additional metadata. 11:39.000 --> 11:51.000 For example, the file size, but it could also include the media type information for authentication or association of the uploaded file. 11:51.000 --> 11:56.000 The server then has to create what we call an upload resource. 11:56.000 --> 12:03.000 This upload resource keeps track of the data that has been uploaded and how much data has been uploaded. 12:03.000 --> 12:08.000 It's kind of the thing that the server needs in order to retain information. 12:08.000 --> 12:15.000 And it includes the upload resources location in a response back to the client. 12:15.000 --> 12:20.000 So the client can be aware of the upload resource. 12:20.000 --> 12:24.000 Now we imagine the upload continues. 12:24.000 --> 12:29.000 The client is sending data, but then suddenly the interaction happens. 12:29.000 --> 12:34.000 Now the client knows, okay, I want to resume this upload, but how does it do that? 12:34.000 --> 12:40.000 It starts a head request to the upload resource, right? 12:40.000 --> 12:44.000 See that we have now the same endpoint as the upload resource. 12:44.000 --> 12:48.000 And this query is the state of the upload resource. 12:48.000 --> 12:53.000 The server responds by saying, okay, I've got 50%. 12:53.000 --> 12:56.000 We call that the offset. 12:56.000 --> 13:03.000 So the offset of 10,000 would be the half of the 20,000 that is totally uploaded. 13:03.000 --> 13:08.000 The offset is then the point at which the client can resume the upload. 13:08.000 --> 13:10.000 And it does so. 13:10.000 --> 13:17.000 It sends a patch request as a follow-up to the upload resource, saying, hey, I want to modify this upload resource. 13:17.000 --> 13:22.000 By appending the remaining data that I have from transmitted yet. 13:23.000 --> 13:30.000 It announces again the offset, just to be sure that we're both talking about the same offset and we're not accidentally corrupting the file. 13:30.000 --> 13:36.000 But once the remaining data is completely uploaded, the upload is fine again. 13:36.000 --> 13:38.000 And this is the rough schema. 13:38.000 --> 13:47.000 There's a few more details to make this work properly, but this is the rough layout that you need to have resumable uploads as implemented by task. 13:47.000 --> 13:56.000 I now see upload with a post request, optionally resumed by ahead, and transmit all data using patch. 13:56.000 --> 14:00.000 And all of that is already implementable in the browser. 14:00.000 --> 14:07.000 You just use the file API and either the fetch API or XML, XML, sorry. 14:07.000 --> 14:12.000 XML HTTP request if that's the only thing that's available. 14:12.000 --> 14:17.000 And yeah, we have libraries for that. 14:17.000 --> 14:19.000 They already implement this. 14:19.000 --> 14:24.000 We not only have an open protocol, but we also have many implementations. 14:24.000 --> 14:28.000 Many of them are built by the community for the community. 14:28.000 --> 14:31.000 On the client side, we have a JavaScript client. 14:31.000 --> 14:37.000 The small astrogus year like this is because it's not only for the web, but it's also like for anywhere. 14:37.000 --> 14:46.000 It runs in Node.js, it runs in the browser, it runs in DNO basically wherever you have a fetch API available. 14:46.000 --> 14:51.000 We also have clients in Java, if you enter that kind of stuff. 14:51.000 --> 15:01.000 Android and iOS, of course, as well, because those are the major platforms where you will be running on unreliable networks. 15:01.000 --> 15:09.000 On the server side, we have a implementation in Node.js, for example, in Go, Java, and.net. 15:09.000 --> 15:16.000 But there's many more community contributed ones in Python and Ruby and Rust in many other languages. 15:16.000 --> 15:22.000 And they all interrupt because they all speak the same open protocol. 15:22.000 --> 15:30.000 But the thing is that we're implementing this based on the APIs that the environment provides us. 15:30.000 --> 15:35.000 So we're fundamentally limited by the capabilities that this environment brings us. 15:35.000 --> 15:43.000 For example, in the beginning, I said that, hey, would be nice if we could call pause uploads in the background when, for example, real-time video is appearing. 15:43.000 --> 15:47.000 That needs the upstream bandwidth. 15:47.000 --> 15:54.000 In the web browser, of course, conduit is, because I'm not sure what the other web pages or applications on device are doing. 15:54.000 --> 15:58.000 The only one who really knows is the operating system at the end of the day. 15:58.000 --> 16:14.000 So we do are pausing an upload because more priority or higher priority traffic is, or occurring, isn't possible for us with implementations that are happening, I can use our space, so to say. 16:14.000 --> 16:18.000 For that to happen, we actually need to implement it on a lower level. 16:18.000 --> 16:25.000 Maybe directly inside the HTTP or networking stack that your device is running on. 16:25.000 --> 16:33.000 And, of course, another problem is every application needs to bring their own client that's kind of annoying, increases bundle sizes. 16:33.000 --> 16:35.000 So what can we do about this? 16:35.000 --> 16:41.000 This has actually a question that Apple was faced a few years ago. 16:41.000 --> 16:48.000 They wanted to bring resumable uploads into their HTTP stack because they realized that this could be beneficial for the platform. 16:49.000 --> 16:57.000 Then they saw the test project and they were like, hey, this is kind of nice, but we can't implement test in our own HTTP stack. It's not official enough, right? 16:57.000 --> 17:02.000 Because it was just a document that we published on our web page. 17:02.000 --> 17:12.000 But we said, okay, we can actually improve this by making it more official. 17:12.000 --> 17:26.000 And by making it more official, I mean that we reached out to the ITF, the internet engineering task force, which has the working group on HTTP, which is, you know, taking care of HTTP standards that are out there. 17:26.000 --> 17:35.000 And we proposed idea that we should have a standard on resumable uploads for HTTP. 17:36.000 --> 17:41.000 And they accepted it, we got it adopted. 17:41.000 --> 17:57.000 With the idea of bringing resumable uploads into HTTP implementation correctly, meaning inside clients, inside browsers, inside proxies, so that you don't have to ship them anywhere on your own. 17:57.000 --> 18:08.000 It also helps us get more stakeholders involved, right? We're mostly application developers. We're not developing on proxies or infrastructure, but they have their requirements and their concerns as well. 18:08.000 --> 18:16.000 So by going to the ITF with this, we get a lot more valuable feedback on how things should be working the proper way. 18:16.000 --> 18:33.000 It's currently working good bus call, so fingers crossed that this will complete soon. There's already implementations of this. So if you have a current iPhone or Mac, it's actually implemented already in your networking stack. So you could use it nowadays. 18:33.000 --> 18:45.000 It includes many nice features that we discovered would be great while doing tasks. For example, it can transparently upgrade from classic uploads that I initially mentioned to resumable. 18:45.000 --> 18:55.000 And two resumable uploads. This happens by one XX response, but they're not available in user space by the Fetch API. 18:55.000 --> 19:06.000 So let's think about bringing it inside the browser, right? Why don't we have a resumable property in the Fetch API for example? 19:06.000 --> 19:14.000 Then we don't have to bring the own resumable upload client anymore in your application. The browser will take care of everything. 19:14.000 --> 19:20.000 It can take care of automatically enhancing the upload to being resumable if that's available. 19:20.000 --> 19:30.000 It could pause the upload to prioritize real-time traffic. It could pause the upload when the device awakens after it has gone to sleep network has disappeared. 19:30.000 --> 19:40.000 All of these things will be available if it was in the Fetch API, because then it's handled by a lower level that has all of this information available. 19:40.000 --> 19:50.000 But this is a proposal, isn't it? If you think this should be the case, then comment on the good update there. 19:50.000 --> 20:00.000 But yeah, that's all I have to say. You've probably heard a lot already today, and we'll hear a lot more tomorrow. So here's a few key takeaways for you. 20:00.000 --> 20:14.000 Resumable uploads offer a great improvement for the user experience. You can use them nowadays using existing open source solutions just head over to test.io and use any of the available implementations. 20:14.000 --> 20:19.000 Support is hopefully coming to more devices next to you soon. 20:19.000 --> 20:27.000 But besides that, I also want to just say, you can just start your protocol, right? You don't have to be a protocol engineer. 20:27.000 --> 20:33.000 You just write a spec, publish it, and then you're done. It can really iterate easily. 20:34.000 --> 20:44.000 But if you want to have it more mature and get people from or input from more people, then head over to the ITF, W for C or any other standard organization. 20:44.000 --> 20:49.000 Where you can usually get a lot of helpful feedback that you've not discovered before. 20:49.000 --> 20:59.000 But yeah, that's all I have. Thank you for your attention. I'll be outside if you have any questions of that as well. I think we have some time left. 20:59.000 --> 21:01.000 Thank you for your attention. 21:02.000 --> 21:03.000 Thank you. 21:06.000 --> 21:09.000 And we have five minutes left for questions. There's one there. 21:15.000 --> 21:18.000 Hello, great talk. Thank you. 21:18.000 --> 21:26.000 Maybe I missed it, but how do you make sure that the file being uploaded is actually the same, the exact same file as it was before. 21:26.000 --> 21:33.000 Like, is there like a hash you're comparing it against? And it's so is the hashing algorithm part of the spec? 21:33.000 --> 21:40.000 The responsibility of making sure that the same file is resumed is usually the client's responsibility. 21:40.000 --> 21:49.000 So they have to make sure that they're uploading the same file that they, when they resume, they have to make sure that's the same file as before again. 21:49.000 --> 21:58.000 This is also made sure because the upload resource is unique to the file you're uploading. So for every file you have your own upload resource. 21:58.000 --> 22:02.000 So if you're uploading multiple files, you will have multiple upload resources. 22:02.000 --> 22:08.000 And this is the client's responsibility to make sure it sends the data to the right upload resource. 22:08.000 --> 22:10.000 Thank you. 22:10.000 --> 22:15.000 Thank you. It was very digestible. So great talk. 22:15.000 --> 22:23.000 What I want to ask is whether when you started this project and you wrote that's protocol, like I guess whatever you wrote down back then. 22:23.000 --> 22:29.000 Did you already had a mind that it was the idea to be standardized or to be more official? 22:29.000 --> 22:34.000 No, we didn't come from that background, so we had no experience with the idea of whatsoever. 22:34.000 --> 22:44.000 And for many years, we didn't really consider it until some people reached out to us and were like, hey, if you would make it more official, this is the way to go and we can help you with that. 22:44.000 --> 22:49.000 So it took us a few years to realize that this is the possibility. 22:49.000 --> 22:59.000 Okay, thank you. 22:59.000 --> 23:08.000 How reliable have you found it to be uploading the file after just given an offset without any sort of hashing? 23:08.000 --> 23:20.000 Like does that, do you ever run into scenarios where part of the upload, where something I corrupted near the end of a stream, for example? 23:20.000 --> 23:25.000 We haven't discovered much, it's just with that actually, no. 23:25.000 --> 23:31.000 It's the, again, this is puts a bit of responsibility on the client to make sure it actually retains the same file. 23:31.000 --> 23:38.000 If, of course, the file is changing because it's a document you currently editing, then you will run into issues with this. 23:38.000 --> 23:43.000 But then again, this is kind of more of the upper layer issues. 23:43.000 --> 23:53.000 But yeah, it's a very important, the offset is basically the most important element we have to kind of prevent corruption. 23:54.000 --> 23:57.000 There was another question somewhere here. 23:57.000 --> 23:59.000 Hello. 23:59.000 --> 24:05.000 What about the data retention policy for incomplete uploads on server sites? 24:05.000 --> 24:11.000 This is a very good question and usually depends on your application needs. 24:11.000 --> 24:21.000 What I usually like to recommend is that the upload resources kept around vong enough to allow the client to retry once more. 24:21.000 --> 24:29.000 Because there's a specific failure mode where the upload is complete, but the client doesn't receive the lost response from the server. 24:29.000 --> 24:34.000 Then the server already thinks, okay, my upload is complete, but the client doesn't know it. 24:34.000 --> 24:40.000 So it has to do one more round trip and ask the server like, hey, did you actually get the entire upload or not? 24:40.000 --> 24:46.000 So I usually recommend to keep it around for a short period of time, but you don't have to keep it around for hours. 24:46.000 --> 24:51.000 If that's not what your application needs. 24:51.000 --> 24:59.000 Sorry if this was mentioned already before, but do you have any insights as to why browsers haven't already included this? 24:59.000 --> 25:01.000 It's actually the question that I get a lot. 25:01.000 --> 25:02.000 Sorry. 25:02.000 --> 25:05.000 Why are you, no, no, no, it's not that. 25:05.000 --> 25:08.000 I get the question often, like, why are you still working on this? 25:08.000 --> 25:10.000 It seems so basic, why haven't you done this? 25:10.000 --> 25:12.000 It hasn't been done years ago. 25:12.000 --> 25:22.000 And I think this boils down to is that if you control the client and the server, you can build your own thing and it will work just fine because you're in your wall garden. 25:22.000 --> 25:32.000 So I think the pain to actually go out and start to interrupt their protocol was not too high, so people have just not done it. 25:32.000 --> 25:39.000 And they're kind of okay with, you know, using implementations that work in user space, so to say. 25:39.000 --> 25:47.000 But I think now there's been some momentum to actually get it to a stage where it's integrated into HTTP networking itself. 25:47.000 --> 25:53.000 So let's hope this actually happens now. 25:53.000 --> 25:59.000 Earlier in the talk, you mentioned that standardizing on this also allows proxy to support it. 25:59.000 --> 26:05.000 Do you see any role for them in the resumability beyond just passing the traffic on to the server? 26:05.000 --> 26:12.000 So there's a specific mode where the proxy can translate between resumable uploads and normal uploads. 26:12.000 --> 26:21.000 This is especially handy if you have legacy applications, for example, that don't support resumable uploads or you don't want them to support it at all. 26:21.000 --> 26:29.000 Then you can have a proxy that recognizes how resumable uploads work and automatically takes care of concatenating data together. 26:29.000 --> 26:34.000 And that is something that could be implemented in proxy. 26:34.000 --> 26:36.000 Well, thank you so much. 26:36.000 --> 26:41.000 Times running out, but if there are other questions, I'm sure you can discuss. 26:41.000 --> 26:43.000 All right, thank you very much.