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

Hi Charles,

thanks for the update.

Comments below...

Charles Fry wrote:
>> 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>.

Great.

>> 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.

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).

>> 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

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).

> 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!

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

> 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

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).

> 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.

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.

> ...
>>> 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?

Why wouldn't that be 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.

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

>> 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!

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

Received on Friday, 29 August 2008 13:14:32 UTC