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: Tue, 16 Sep 2008 16:03:11 +0200
Message-Id: <EC97F46E-F834-4489-903C-3BB8AAC23211@greenbytes.de>
Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@yahoo-inc.com>, Charles Fry <fry@google.com>, gears-eng@googlegroups.com, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: Jamie Lokier <jamie@shareable.org>


Am 16.09.2008 um 15:19 schrieb Jamie Lokier:

>
> Julian Reschke wrote:
>>
>> So my concern is that we use two different types of ETags on the same
>> resource.
>
> I agree, this is a good point.
>
> Why use the Etag header for resumable POSTs?  If Etags are used (and
> why not - it's handy not to have to carve out special URL space), I
> still don't see any advantage to using the ETag _header_ for it in
> resumed POSTs, as opposed to inventing a Resume-POST header.


Not that it is important, but *I* do not understand why there is a  
discussion about a new protocol feature when URI space management is  
able to solve the problem most elegantly. URI usage seems even easier  
for clients, so the burden is on the server implementation where  
there are not so many.

The use case I heard about is adding resumable upload to a cloud at  
the very edge by some sort of server proxy. Such a proxy is not  
master of the served namespace and cannot simply invent new URIs. So  
such proxy would need additionally a namespace of their own, but that  
does not sound like a show stopper. It would allow for load  
balancing, as was already mentioned here.

If someone would be so kind as to help me overcome my ignorance in  
this matter? Thanks.

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Tuesday, 16 September 2008 14:04:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT