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

From: "Charles Fry" <[email-masked]>
Date: Fri, 18 Jul 2008 11:47:07 -0400

Based on all the feedback we received on this thread, we modified our
proposal to remove the 103 responses:

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

Everything remains the same at a high level, other than the fact that
clients must pro-actively query the server to determine which bytes it
possesses (rather than being able to rely on the 103s).

We'd love to any additional feedback that you have to offer.

thanks,
Charles

On Fri, Apr 11, 2008 at 9:43 AM, Henrik Nordstrom
<[email-masked]> wrote:
>
> fre 2008-04-11 klockan 10:32 +1000 skrev Mark Nottingham:
>> etc., and it's still HTTP/1.0 (although 2.7 will have a HTTP/1.1 mode,
>> and from the testing I've done, it's pretty conformant).
>
> Still no support for chunked requests. But it does respond with 411 if
> seeing one..
>
> Also no forwarding of 1xx responses yet, which is the primary reason why
> it's not enabled by default.
>
> Regards
> Henrik
>
>

---

From: "Charles Fry" <[email-masked]>
Date: Fri, 18 Jul 2008 11:52:00 -0400

[google-gears-eng is now gears-eng]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 19 Jul 2008 13:49:27 +0200

> We'd love to any additional feedback that you have to offer.

Hi,

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

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

Some more nits:

- some of the ETags in the examples are broken

- why use POST just to obtain information? why not HEAD?

- not sure what If-Resume is good for; what does it do what If-Match 
doesn't?

BR, Julian

---

From: "Charles Fry" <[email-masked]>
Date: Mon, 21 Jul 2008 12:18:24 -0400

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

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

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Jul 2008 20:47:48 +0200

> HTTP/1.1-compliant clients/proxies.

That sounds exactly right.

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

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

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

> it assumes a unique URL per upload. While we recognize that that is

I think that's a feature.

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

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

BR, Julian