Re: Draft for Resumable Uploads

[Eric J Bowman <[e-mail]>]

All snark aside (sorry about that, Austin, all)...









>

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

https://httpwg.org/specs/rfc5789.html#patch:




If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.





So as long as the PATCH media type can describe creating a resource (which this does), PATCH can create resources.

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

>








The reason I think this is bad protocol design to the point it makes my brain explode, is it introduces the notion that method semantics vary by media type. The interface is now resource-specific, rather than generic. Transparency is lost because the message is not self-descriptive, e.g. intermediaries would require a lookup table of media types in order to determine method semantics.



>

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

This is also my understanding of how filesystems work. You don’t have a separate create operation, any write to a file creates it (depending on the flags that are set). You can even write to a nonzero offset and it will create a sparse file.

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

>








My bad for bringing up OS / FS. A uniform network interface to a collection of resources is its own problem space. An OS doesn't need to worry about an unreliable connection, let alone intermediaries, for filesystem ops.



>

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

>





> But how would the user-agent know this isn’t intentional?

> How would it know the file is actually incomplete?

>







Because 206 response code.







Ok, so undefined byte ranges would not be returned by the server, is this your understanding?

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

>







My understanding is that the server only knows it never received the entire upload. It isn't attempting to render the payload, in order to determine anything about *how* the partial upload breaks due to not being complete, let alone convey that information to the client -- because surely the client can figure that out by diff'ing the 206 response payload.



>
>----------------
All clients see the same resource, correct? Suppose I’m doing a segmented upload, and I finish the first half of the upload. If I make a GET request, I would expect to see 206 showing the defined bytes. But what about other users that don’t support this response? How do I ensure they’re not downloading a mangled file? Should this return a 4xx error if the client doesn’t support partial content responses?

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




>



Mangled representations are a fact of life on the Web. So are 200 OK responses which say "not found" in the message body. If you're concerned that a failed upload shouldn't result in a borked retrieval, don't update the resource. If you want to give user-agents a hint about where the upload failed, I suggest 206; and acceptance of the fact that a 200 OK response doesn't imply a valid representation, which is a feature of Web architecture, not a bug -- tightly-coupled architectures fail to scale, while the Web has scaled exponentially for 30 years by allowing this sort of thing.



-Eric