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

Charles Fry wrote:
>> first of all, I find the number of options (Location or not, HTTP/1.1 or
>> not, and so on) totally frightening. It seems to me the proposal would be
>> much easier to understand if there'd be exactly one way to do it (with
>> potential workarounds for HTTP/1.0).
> 
> At least with respect to HTTP/1.0 vs. HTTP/1.1, we have gone through
> the mental exercise of combining the two proposals, but haven't yet
> combined the documents. The idea would be that the 103 interim
> response would be optional, and reserved for use with
> HTTP/1.1-compliant clients/proxies.

That sounds exactly right.

> As for Location vs. ETag, I don't disagree that it would be nice to
> just specify I single type of behavior. And my preference would be to
> always use ETags. However both comments on this list and discussions
> we've had internally suggest that many people prefer the Location
> solution. At this point I don't see allowing this option as limiting
> the utility of the protocol specification. Indeed, any given
> implementation (including the mod_resume I am working on) will
> probably only implement one of these. Maybe you have a better vision
> than I of how something like this will unfold in the long-term, but I
> see the current option as leaving the door open for this to be
> customized to various use-cases with different requirements. That
> said, I'd love to better understand why you are so skeptical about the
> Location vs. ETag option.

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?

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.

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

> communicate byte range information. The two other minor differences
> you have already commented on: HEAD vs. query request (which I comment
> on below), and optional vs. required Location (which I commented on
> above). In other words, I think we're basically doing just what Roy
> suggested. If I'm missing something key from his proposal that you
> think we should include (other than the two differences already called
> out) please specify what it is.
> 
>> Some more nits:
>>
>> - 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>:

    entity-tag = [ weak ] opaque-tag
    weak       = "W/"
    opaque-tag = quoted-string

So something like

    ETag: vEpr6barcD

is invalid, it should be

    ETag: "vEpr6barcD"

(if it is a strong etag).

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

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

>> - not sure what If-Resume is good for; what does it do what If-Match
>> doesn't?
> 
> If-Resume is not part of the current proposal whose link I just sent
> out. I have not yet updated the old (HTTP/1.1) proposal (I assume you
> must have browsed to find the link?), so it may contain antiquated
> references. My request for comments was only for the HTTP/1.0 proposal
> whose link I just sent out.

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

> Thanks for the feedback. We appreciate you taking time to think about
> and comment on this proposal.
> 
> Charles


BR, Julian

Received on Tuesday, 22 July 2008 18:48:33 UTC