W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Deploying new expectation-extensions

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 4 Apr 2008 18:10:52 -0700
Message-Id: <3173C7D0-7078-480E-9B99-E174AD2001DA@gbiv.com>
Cc: google-gears-eng@googlegroups.com, "Charles Fry" <fry@google.com>, "Mark Nottingham" <mnot@yahoo-inc.com>, "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>
To: Brian McBarron <bpm@google.com>

On Apr 4, 2008, at 6:50 AM, Brian McBarron wrote:
> What we need to implement http://code.google.com/p/google-gears/ 
> wiki/ResumableHttpRequestsProposal is a mechanism which:

Don't reimplement TCP on top of HTTP.  The result will be not work
as well as TCP.  Among other reasons, the connection will be reset
at the TCP level and the RST will rollback the TCP windows to the
point where your little client will never see the ack from the server.

Re-think your solution instead.

Consider this.  Any server that is capable of supporting such a
mechanism will have to maintain temporary files that are uniquely
accessible to that client for the amount of time that the server
is willing to allow resumption.  So, let's give that resource a URI.

The first request is sent to the origin server without needing
to know if it (or anything along the path) understands the extension.

    POST /my/favorites HTTP/1.1
    Host: example.com
    ....

If the server receives that message with no Via field or with a
Via field that indicates no HTTP/1.0 intermediaries, then the server
can respond immediately with

    103 Resumable
    Location: http://example.com/my/favorites;r123

Note that the URI above is created by the server, so it could be
anything, though a sensible security policy would limit it to a
suffix of the requested POST URI.  You'll have to try it to see
if this works in practice with HTTP/1.1 user agents -- you may
need an additional request header to indicate it if not.

If the connection drops, the client can then do

    HEAD /my/favorites;r123 HTTP/1.1
    Host: example.com

to determine how much of the content was successfully transferred
and stored on the origin server, and append to that content with
a simple

    POST /my/favorites;r123 HTTP/1.1
    Host: example.com

and repeat as necessary.  Auth/access control can be added as normal.
I suggest, however, that anything as fragile as a resumed request
be accompanied with some sort of integrity check, like content-md5.

The extension is therefore achieved with the addition of one status
code and should work with any HTTP/1.1 compliant server chain.
If it doesn't, you are no worse off than before (and HTTP is not
complicated and constipated by unnecessary Expect fields).

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Saturday, 5 April 2008 01:11:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:46 GMT