Re: Draft for Resumable Uploads

>

> So then I think a simple modification of my “Partial Uploads”

> document (https://tools.ietf.org/id/draft-wright-http-partial-upload-01.html) would work 

> well.

>



Kudos for how well you've written your document. But please don't suggest using PATCH to create a resource? Best decision I ever made regarding httpd coding was only 3 years or so ago, I eschewed Windows compatibility in favor of tight coupling to UNIX filesystem attributes. Speaking in terms of static files for simplicity...



DELETE on my httpd doesn't remove the existing resource, it sets it to zero bytes, such that subsequent GET/HEAD requests respond 410, and may or may not Allow: PATCH. No file? 404, which may Allow: PUT. I can't help but think that a PATCH request to a nonexistent resource should return 404.



>

> First, it defines the message/byterange media type, 

> for making changes to a specific byte range. This is the 

> bulk of the desired functionality, I think.

>



I would encourage you to document that media type independently from the rest of your draft.


>

>---------------

Second, 2__ Sparse Resource would indicate that the resource has some regions filled in by the server, and might not be valid according to the media type definition. But I’m not confident that all user-agents would safely handle a 2__ Sparse Resource. If the resource represents executable code, the result could be very bad. Maybe I remove this? It seems wrong to me that a server could send back a document it knows is invalid according to the media type. Maybe there should be an error for clients that request a sparse resource without indicating they can support the response.

>---------------

>



Hmmm... I'm a bit rusty at explaining this, but here goes. Media-Type in HTTP has nothing to do with file format. My server intent may be to "view source" of an HTML file, so I use text/plain to prevent it from being parsed and rendered as HTML. My server intent may be to present a broken PNG, so I use image/png to have the client attempt to render it as such. Being a valid representation of said media type is not implied, and I assure you there's nothing wrong with that. If a UA fails to render, it reports the error to the User i.e. "broken image icon". Application-layer error, not protocol-layer error.



I think you've gone astray by essentially modeling "sparse" as a subtype of any given media type. Or qualifying a resource ('s representation) as being the result of executable code -- excluding static files of expected types, 99% of my resources map to server-side processes. Receiving a borked representation has no effect on the executable, because the server-side resource coding is decoupled from its representations, and hidden behind a Uniform Interface.






-Eric