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

> 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

Received on Thursday, 28 August 2008 16:45:18 UTC