Re: Draft for Resumable Uploads

Hi Austin, you ask good questions!



>

> Finally, I’m not sure I fully understand what the response 

> would indicate exactly. Shall the server actually support 

> “sparse documents” (where some bytes are undefined)? 

>



It's all up to how the client supports rendering the media type at hand. Regardless of serving my deliberately-broken image files as 200 or 206 for several years, some browsers "filled it in" with blocks of grey, others used their broken-image icon; some browsers went from broken-icon to filled-in image, while others regressed from filled-in image to broken-image icon. Some browsers behaved differently depending on platform, i.e. comes down to image-rendering libraries. All the server can really do, is somehow indicate to the client that the requested representation is incomplete, if the server knows that for a fact.



>

> This would allow users to upload segments out-of-order,

> and in parallel from different uplinks. If the client does 

> not support sparse documents, how should the server 

> respond? (Fill in the undefined regions with zeros?)

>



The server only cares about media-type, really. Oh, you need PNG? I have that. Just wanna let you know it's broken! Do with it what you will. I'll allow PUT/PATCH if you no likey and are authorized for those methods.



Distributed out-of-order uploads... Hmmm. I had to give that some thought, but it doesn't change my position. Any number of participating clients contributing to a file upload, just have to agree how to "fill in the blanks" on the returned representation until it's 200 OK.



I think you and mnot are correct that we need better-defined PATCH media types, I believe that's where to solve this problem, but how any media type is rendered has traditionally and properly been a client-side concern in HTTP.



-Eric