W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Issues addressed in the -24 drafts (and getting to IETF Last Call)

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 30 Sep 2013 13:14:57 +1000
Cc: "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>
Message-Id: <5B8FDCC8-04AB-405E-9A99-11E78232526A@mnot.net>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>

The problem is that doing so isn't interoperable; i.e., you can't do a Content-Range on any PUT and know that the server will honour it. Effectively, they're creating a private protocol *based* upon HTTP, because you have to have out-of-band information that the resource will honour Content-Range on PUT. It's not HTTP, though.


On 28/09/2013, at 7:37 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

> On Thu, Sep 26, 2013 at 04:38:28PM +1000, Mark Nottingham wrote:
>> Please have a look at the issues below; barring objections, I'll close them. 
>> Issues are linked from <http://trac.tools.ietf.org/wg/httpbis/trac/report/15>.
>> non-specific
>> #475  Strengthening SHOULDs
> Content-Range with PUT is used in the wild.
> Specifically, often to upload huge amounts of data (I have seen 36GB+ 
> transfer lasting for days) with client being able to resume transfer
> from where it left off if the connection fails partway for any reason.
> Here's docs for one:
> https://developers.google.com/youtube/2.0/developers_guide_protocol_resumable_uploads
> And there are probably several inspired by that protocol (I'm
> aware of one such thing, that also happens to insta-400 any PUT
> without Content-Range).
> And I don't see how full and partial PUT could be confused, unless
> servers ignore Content-Range, which violates MUST-understand-or-reject
> requirement in RFC2616 (but that wouldn't really be surprising,
> given what happened to Expect) or client is just plain buggy
> (in which case all bets are off).
> -Ilari

Mark Nottingham   http://www.mnot.net/
Received on Monday, 30 September 2013 03:14:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC