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

Ilari,

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.

Regards,

  
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