Re: HTTP Spec: PUT without data transfer, since hash of data is known to server

On 2015-10-08 19:47, Thomas Güttler wrote:
> Am 07.10.2015 um 16:26 schrieb Ed McClanahan:
>> Hmm... HTTP PATCH sounds like a problem then. Imagine that a previous PUT
>> of some other resource included said hash. A later PATCH modifies a portion
>> of that old resource. In order to be able to reference the new content of
>> that old resource, a new hash for the entire resource needs to be
>> recalculated. Not very practical for small PATCHes to large resources...
>
> Yes, a small PATCH to a big resource would result into a re-calculation
> of the hash sum. This re-calculation would need to scan the whole resource,
> although only a small part has changed. That's true.
> But "that's live", I see no problem. At least in my environment PATCH is hardly used.
> I see mostly this: Whole files get uploaded and downloaded.
>
>> Still, it seems HTTP PATCH also provides an elegant solution. Using PATCH,
>> they payload could be a simple "the data for my new resource has this hash"
>> rather than the data itself. The HTTP server could accept or reject the
>> PATCH request based upon whether or not it has seen this hash before. If
>> rejected, the client just does the normal PUT with unique data anyway.
>
> I am not sure if I can follow your thoughts.
>
> Do you want to use PATCH to implement uploads without data transfer, or
> do you want to use "sending data without transfer" for PATCH, too?
>
>>From RFC:
>
>   The PATCH method requests that a set of changes described in the
>   request entity be applied to the resource identified by the Request-URI.
>
> AFAIK you can only PATCH existing resources. My idea is to PUT new
> resources. The same way could be used for PATCH, but I would like to
> handle this later.

The resource always exists (it has a URI), it just might not have a 
GETable representation yet.

So yes, you can use PATCH in that case; it all depends on the PATCH 
semantics defined for the media type used in the request.

>...


Best regards

Received on Monday, 12 October 2015 07:28:00 UTC