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

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 19 Sep 2008 09:01:48 -0700
Message-Id: <87D88D4C-D9DC-47A5-99DC-7AC1CD4493D9@gbiv.com>
Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "Jamie Lokier" <jamie@shareable.org>, "Brian McBarron" <bpm@google.com>, gears-eng@googlegroups.com, "Julian Reschke" <julian.reschke@gmx.de>, "Alex Rousskov" <rousskov@measurement-factory.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
To: Charles Fry <fry@google.com>

On Sep 19, 2008, at 7:28 AM, Charles Fry wrote:
> A few more thoughts on URLs and ETags:
> - While it isn't clear in the examples on the wiki page, the initial
> handshake is optional. In other words, it represents one extreme end
> of the protocol, but the primitive requirement is that unique
> identifier (whether URL or ETag) be obtained. This could very well be
> present in an HTML page, for example, allowing a resumable upload
> without the initial handshake.
>  - Regarding ETags vs. URLs, one point of reference for me is CGI
> scripts. A single CGI script running behind a fixed URL should (in my
> mind) be able to perform a resumable upload, but this would require a
> unique identification mechanism other than the URL.

That isn't relevant -- any CGI script (and just about any part of a
server's URI space) can be overlapped as many times as you want.
In any case, ETag is not a unique identifier.

I already explained how to do this functionality in
<mid:3173C7D0-7078-480E-9B99-E174AD2001DA@gbiv.com> on Apr 4.

The ETag examples you provide don't make any sense.  Etags only
have meaning within the scope of a resource's current representations.
If you are posting to a service that has no corresponding resource
mapping, the etag in response must correspond to the etag that you
would have received if the request were a GET on that service.
In essence, this allows a service to be versioned, though such
interfaces are not typically used on the Web because we prefer to
use backwards compatible services rather than strict version coupling.

So, the short answer is that only the URI solution fits within
the current web architecture.

Received on Friday, 19 September 2008 16:02:26 UTC

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