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

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

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.

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

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

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

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

Charles

Received on Monday, 21 July 2008 16:19:16 UTC