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

From: "Charles Fry" <[email-masked]>
Date: Thu, 28 Aug 2008 12:44:34 -0400

> ETags are good. No problem with that.
>
> That being said, I liked Roy's proposal in where the resumable request gets
> a separate URI assigned, exposed in the Location header. Maybe I read
> something the wrong way, or maybe I'm confusing what the two documents
> propose, but wouldn't it be best to always use that design?

To help keep things clear, I combined the two documents into
<http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal>.

> The problem in offering widely differing ways to do the same thing is that
> at least in the beginning, clients and servers would need to implement all
> of them in order to achieve some kind of interoperability.  It would be
> great if this could be avoided.

Good point. We'll definitely consider that.

>>> You said "based on all the feedback" -- did you indeed consider what Roy
>>> wrote
>>>
>>> (<http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0082.html>)?
>>
>> Indeed we actually used his proposal a starting point for our
>> proposal, though it has admittedly evolved since then. The most
>> substantial difference I see is that we've attempted to formalize
>> important details such as how the Range and Content-Range headers
>
> It would be interesting to hear why you think these additional parts are
> needed.

Content-Range request header: used to specify which byte range is
being sent. Roy's proposal simply suggested appending bytes, but that
leads to requests which are non-idempotent. Further it differs from
the precedent of byte-range GETs. If a byte-range POST is being
performed, then by all means let's specify which range of bytes are
being sent!

Range response header: used to specify which which byte range the
server already possesses. Roy proposed accomplishing this with HEAD.
That works fine, except it doesn't account for the fact that a request
might not contain the entire byte range. What does the server do when
it receives an incomplete byte range? The most efficient response
would include the byte range the server has, avoiding an extra round
trip just to figure that out. And again, this is closely mimicking the
precedent set in byte-range GETs.

>>> - some of the ETags in the examples are broken
>>
>> Can you please explain why? The only hint of anything different that I
>> can find in the spec is the inconsistent use of "", though not being
>> documented (where I was looking) I assumed those weren't required.
>
> ETags have exactly two syntactic forms, defined in
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.11>:

Wow. I'm surprised that section 3.11 isn't referenced from section 14.19.

>>> - why use POST just to obtain information? why not HEAD?
>>
>> It's funny that you say that, because we initially did use HEAD
>> (having re-started with Roy's proposal). The problem with HEAD is that
>> it assumes a unique URL per upload. While we recognize that that is
>
> I think that's a feature.

Not necessarily. In order not to violate the HTTP semantics of HEAD,
this implies that the newly POSTed content is accessible behind a GET
from the same URL. What if that is not desirable?

There is also the previously-mentioned issue with HEAD being that it
doesn't covor all the use cases where we need to return the byte range
held on the server, and it seems clean and simple to have a single
byte-range-reporting mechanism.

>> one way it could be implemented, it also seems valid to allow the use
>> of ETags to uniquely identify distinct uploads, allowing for the use
>> of a single URL to process all uploads (e.g.
>> http://example.com/upload). In cases where a single URL is used, HEAD
>> (even with an ETag) is clearly abusive. More generally, HEAD is
>> semantically opposed to POST (though admittedly it would be a good fit
>> for PUT) as POST makes no gaurentees about creating a new resource.
>
> Again, I have the gut feeling that everything would be much simpler if any
> resumable operation had exactly one URI assigned. Apparently you see a
> problem with that approach. Which?

Well, I don't see how everything would be much simpler. The only
simplification is the removal from the proposal of discussions of the
ETag use cases. That would in no way change the proposal in any other
manner (more specifically, it wouldn't simplify the non-ETag part of
the protocol). But if you see some simplification we're missing, we'd
love to hear about it!

> The HTTP/1.0 proposal still has the link to the HTTP/1.1 proposal in it,
> which of course contributed to my confusion.

Yeah, we should have just combined the two documents long ago. I
finally did that, adding an optional 103 (Checkpoint) to the protocol,
which was the only feature which hadn't already been migrated to be
HTTP/1.0 compatible.

Charles

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Aug 2008 15:13:46 +0200

Hi Charles,

thanks for the update.

Comments below...

> <http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal>.

Great.

> Good point. We'll definitely consider that.

I think the biggest simplification would be to select either the ETag 
based approach or the URI-based approach (where I think the latter works 
better).

> leads to requests which are non-idempotent. Further it differs from

It depends. If the "append" operation always uses POST/If-Match, then 
each of these requests is idempotent (it will either succeed, or the 
server will reject it because the ETag isn't current anymore).

> performed, then by all means let's specify which range of bytes are

I think sending the Content-Range header is harmless, but not required 
for the whole thing to work.

> might not contain the entire byte range. What does the server do when

Not sure.

If the nonentity has N bytes, then the total number of bytes the server 
has will always be n, where 0 <= n <= N.

What additional information except "n" does the server need to reveal 
(and that would be what HEAD/Content-Length returns).

> precedent set in byte-range GETs.

It seems to me the proposal would be simpler and more robust if it would 
work without the Range headers. That being said, adding them to provide 
additional information may be good.

> ...

Why wouldn't that be desirable?

> byte-range-reporting mechanism.

If Content-Range is necessary, it would be simple just to state that it 
MUST be returned for HEAD on the resume URL.

> the protocol). But if you see some simplification we're missing, we'd

As far as I can tell, if you use the ETag based approach, and multiple 
clients try to post to the same collection (POST URI), then you'll have 
to disambiguate the requests. That problem would go away if each of them 
would use a different URL.

It also would make it easier to apply access controls.

> ...

BR, Julian