W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2015

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

From: Manfred Baedke <manfred.baedke@greenbytes.de>
Date: Wed, 7 Oct 2015 17:10:31 +0200
To: Thomas Güttler <guettliml@thomas-guettler.de>, w3c-dist-auth@w3.org
Message-ID: <561535E7.9010805@greenbytes.de>
Hi Thomas,

This is the wrong mailing list - the topic is plain HTTP.
> I want a official spec
It's already there. PUT and ETags are defined by the HTTP spec, see 
RFC7230-RFC7235.

Best regards,
Manfred

On 07.10.15 08:06, Thomas Güttler wrote:
> I  have seen a lot of useless uploads when syncing a local file system with a remote WebDAV server.
>
> I thought about this and asked on stackoverflow.
>
> My idea is to have a PUT which uses ETAgs or a ETag like way, so that the
> data-transfer can be omitted if the server already knows the hash-sum of
> the data.
>
> I got a really good answer from someone who knows the HTTP-specs much
> better than I do:
>
> http://stackoverflow.com/questions/32794863/http-spec-put-without-data-transfer-since-hash-of-data-is-known-to-server
>
> Maybe my goal is too high .... but I don't want to implement this. I want a official spec :-)
>
> What do you think?
>
> Could something like this become an official recommendation?
>
> BTW, I can't decide about the **how** to implement this. My knowledge
> of the http spec is too low at the moment.
>
> At this moment I want to ask:
>
>   - Is it possible at all to create a spec for http put which ommits
>     the data, if the server knows the hash-sum (like depulicating file systems)?
>
>   - If yes, then what is the next step?
>
> PS: Of course the spec should be optional. The server can support it, but don't need to.
>
> Regards,
>    Thomas Güttler
>

-- 
Manfred Baedke

<green/>bytes GmbH
Hafenweg 16
D-48155 MŸnster
Germany
Amtsgericht MŸnster: HRB5782
Received on Wednesday, 7 October 2015 15:10:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:46 UTC