W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: [google-gears-eng] Re: Deploying new expectation-extensions

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 15 Sep 2008 16:16:04 +0200
Message-Id: <7AA55802-218D-4607-8CBE-39FE980963B3@greenbytes.de>
Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "Julian Reschke" <julian.reschke@gmx.de>, "Charles Fry" <fry@google.com>, gears-eng@googlegroups.com, "Alex Rousskov" <rousskov@measurement-factory.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
To: "Brian McBarron" <bpm@google.com>

Am 15.09.2008 um 15:41 schrieb Brian McBarron:

> >On Sun, Sep 14, 2008 at 10:10 PM, Mark Nottingham <mnot@yahoo- 
> inc.com> wrote:
> >[...]
> >Sorry, I *really* don't buy that. You're pushing more complexity  
> and ambiguity (see previous post) onto the clients, which >history  
> shows are more numerous, harder to implement and easier to stuff  
> up. On the server side the difference between using >URIs and using  
> ETags is more a matter of style than implementation complexity.
> Rather than waving hands about history, let's keep the conversation  
> a bit more pragmatic.  If we can find agreement that one of the  
> models is sufficient, I'd be happy to narrow the specification.

I agree with Mark that optional features/alternate behaviours make  
clients more complex and results usually in poor interoperability.  
But, boy, do I dislike ETags. They are like visits to the dentist,  
necessary but no pleasure.

How would a client cancel an upload scenario which just uses ETags?  
(With temp URIs the obvious solution seems to be a DELETE on that  
uri. I sure would feel uncomfortable with a DELETE/if-match: Etag on  
the original POST target...)


<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Monday, 15 September 2008 14:31:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC