Brian McBarron wrote:
I want to call out one point here. In our proposal, the server is in
full control of the upload URI and the presence/absence of an ETag.
This has several advantages:
1) The server can decide whether it is most convenient (from an
implementation point of view) to identify operations via a unique URI
and/or an ETag.
2) Regardless of the two potential mechanisms which can be used, a
server only needs to use one. The server never has to "implement all of
them".
3) The client or intermediary will always have a URI to deal with,
regardless of whether it is unique or not. Indeed, the client doesn't
have enough information to know if a URI is unique.
4) Thus, the only added complexity to the system of supporting
either/both methods, is that a client or intermediary must correctly
forward an ETag when it _optionally_ appears.
OK, so a server can just choose one approach, and for the client it
doesn't matter.
So the only overhead is in the specification, which, I think, is still
sub-optimal. I'd really prefer a single way to do that if that doesn't
conflict with another goal.
To me, the overhead of (4) is very minor considering the power and
flexibility of (1).
Correctly using ETags is something we really should require from parties
using this protocol (so I wouldn't even consider that an "overhead").
On another note, I think it's very much worth designing a protocol that
is compatible with our original intent, which I summarize below. While
this isn't feasible while intermediaries are not 1.1 compliant, we can
hope that will change eventually, enabling this extension to really
shine, IMO.
Assume that a client is conducting requests as normal, with no regard
for whether the server supports this extension. At some point, it makes
any non-idempotent request to the server, and based on the
characteristics of the request, the server realizes the operation has a
probability of failure due to network disconnect. This could be due to
a particularly long running upload, a lossy network connection, or a
back-end delay in processing the request (such as a credit card
transaction). Dynamically, the server decides to enable resumability
for the request, by pushing down a 103 intermediate response. If the
client is compliant, it will either ignore the 103 if it doesn't support
resumability, or it will properly enable support for continuing the
request in case of network failure. In the case of an upload, it means
we can continue where we left off. In the case of a long-running
credit-card transaction, it means we can safely poll for the final
response code, without the risk of double billing the user. The benefit
is that no additional planning had to be done between the client and
server ahead of time, so there is no overhead in regular traffic.
Good summary.
It seems to me that if we can rely on HTTP/1.1 throughout, this is
relatively easy to achieve. My recommendation is to define the simplest
possible extension based on HTTP/1.1 (optimal number of optional stuff:
zero :-), and only then consider extensions/workarounds to get it work
with HTTP/1.0. -- Speaking of which, for HTTP/1.0 is there anything
besides the missing 1xx status codes?
Best regards, Julian
