Re: Draft for Resumable Uploads

>

> Explain for me how a Unix filesystem makes PATCH impractical?

>



Wrong takeaway entirely. I was trying to bring the discussion around to a filesystem paradigm that's been agreed upon since before I was born, because sometimes it helps to do so when discussing HTTP in theory... this is one of those times, I think, unless I've introduced confusion -- in which case I apologize, pragmatism is always my goal.



A resource has to exist first, before it can support PATCH. Leaving it possible to PATCH a DELETEd resource back into existence -- 410 implies a defined resource in a way 404 does not (however, no consensus on my preference there). It just isn't pragmatic to expect consensus around using PATCH to create a new resource, in the face of both POST and PUT having creation semantics which have always been excluded from PATCH... and GET, for that matter.



>

> I think it will make more sense if you think of PATCH as a superset of PUT.

>







If pigs had wings they could fly.



>

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

PUT /upload-target HTTP/1.1


Content-Length: 400


Content-Type: text/plain



[400 bytes...]






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

>



200 OK, 201 Created, 202 Accepted...




>

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

PATCH /upload-target


Content-Type: message/byterange



Content-Range: 0-399/400

Content-Type: text/plain



[400 bytes...]






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

>







404 Not Found.



Unless you're coding an endpoint instead of a resource, in which case the only help I can offer you, is to think in terms of resources not endpoints. My first AI-coding effort leading to Data and Lore chucking endless rocks, reminded me of the value of Roy's thesis -- sometimes we create things that work in unexpected ways, requiring further study to understand. Which came first, WWW or REST? Now that REST explains the hows and whys of WWW, it makes sense to me to work within that paradigm...



Because of the nature of a globally-distributed IP-based network.


 It's a choice between hacking around reality (Data and Lore throwing endless rocks at one another, if you read my other recent posts) vs. playing to its strengths -- REST explains why the WWW succeeded beyond anticipation, despite being created for a distributed, unreliable network. So much easier to code Data and Lore by starting with a 1-1, reliable network.



>

> The effects will be identical.

>







Only if you can get consensus on the magical thinking that PATCH has "create" semantics, sorry. That's like saying Data and Lore are identical by virtue of being twins.



>

> The advantage of the PATCH form is that you can start writing 

> at a non-zero offset, or create the file while indicating it’s larger

> than the enclosed body. PUT cannot do these.

>



Nor can PATCH create a resource. Nothing wrong with using a zero-byte PUT to create a PATCHable resource, btw, fwiw.



>

>>

>> Hmmm... I'm a bit rusty at explaining this, but here goes. 

>> Media-Type in HTTP has nothing to do with file format.

>>

>

> Well, the media type tells you how to decode the response. 

> 



Correct. Isn't that amazing? A jumble of bytes can be successfully interpreted in more than one way! Gopher never grok'd that. TBL certainly earned his knighthood there. Accepting that, has led to intelligent media-type design e.g. JPEG XL still works as image/jpeg.



>

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

> How would it know the file is actually incomplete?

>







Because 206 response code.



>

> Suppose I am uploading an executable binary, how would

> I ensure that users cannot download it while it’s still incomplete?

> 



By coding your server properly? Sorry. Until the server has accepted an upload, it will continue to respond as it did before; maybe 404, maybe 200 with Etag... the Etag changes when the upload completes... If the resource is meant to be the executable file itself, what does it matter if it's incomplete? I have enough trouble dealing with non-corrupted executables to worry what might happen to those I can't compile let alone execute. ;)



But seriously, if you have /resource generating representations, but want to change how those representations are generated by changing /resource and replacing the executable outright... makes sense to go out-of-band from HTTP... which is why webhosting providers still offer FTP.



-Eric