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

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Sep 2013 16:38:28 +1000

Everyone,

As Julian has mentioned, we've published the -24 round of drafts related to HTTP/1.1.

Please have a look at the issues below; barring objections, I'll close them. 

Sharp-eyed observers will note that we don't have any open, current issues against this document set. They've all been through multiple Working Group Last Calls, and, once these issues are closed, I believe we have consensus on the document set, and will be recommending them to our AD for IETF Last Call.

Issues are linked from <http://trac.tools.ietf.org/wg/httpbis/trac/report/15>.

non-specific
#475  Strengthening SHOULDs

p1-messaging
#343 chunk-extensions
#497 Fine-Tuning when Upgrade takes effect

p2-semantics
#303 400 response isn't generic
#458 Requirements upon proxies for Expect
#467 Expect/Continue and "final" status codes
#468 Expectation Extensions
#491 does 205 allow chunked encoding?

p4-conditional
#455 PUT + If-Match over-constrained?
#498 Conditionals and caches

p6-cache
#486 Requiring proxies to process warn-date

p7-auth
#473 Forwarding Proxy-*

--
Mark Nottingham   http://www.mnot.net/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Sep 2013 00:37:02 +0300

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Sep 2013 18:11:11 +1200

> Content-Range with PUT is used in the wild.

A very good reason for the MUST being added. Such implementations are 
not interoperable with middleware lacking Range support.

> https://developers.google.com/youtube/2.0/developers_guide_protocol_resumable_uploads

Which is severaly broken. Any application which attempts to do that 
through a framework that auto-redirects following the standard for 308 
(http://tools.ietf.org/html/draft-reschke-http-status-308-07) will find 
themselves in an infinite loop of repeated PUT + "Content-Range: bytes 
*/*" as they are instructed by the 308 to repeat the request without 
changing it.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Sep 2013 13:31:15 +0200

On 2013-09-28 08:11, Amos Jeffries wrote:
>>> Issues are linked from
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/report/15>.
>>>
>>> non-specific

And Google has already stated that that protocol is being phased out.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Sep 2013 13:14:57 +1000

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,

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 30 Sep 2013 17:13:39 +0300

On Mon, Sep 30, 2013 at 01:14:57PM +1000, Mark Nottingham wrote:
> 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.

Well, the vast majority of resources that support PUT don't support
Content-Range. I suppose a majority of those don't implement the
RFC2616 requirement (MUST) that the request be rejected in that case.

Actually, thinking about it, it is very likely that majority of those
things don't implement the requirement:

E.g. Consider PHP over Apache (pretty common on small sites[1]).
The part that needs to implement the support-or-reject requirement is
the PHP script[2]. And I really don't think most such things are going
to bother doing anything with Content-Range (which breaks the support-
or-reject requirement for PUT).

I suppose the same would be true with other scripting languages
and other webservers too.

So looks like this is another case of widely broken MUST, likely
even worse than the expect(not 100-continue) one.

[1] And given the usual distributions in things like this, there
is going to be A LOT of smaller sites.

[2] Majority of those are going to be written badly by programmers
that most likely never have read HTTP specifications.

-Ilari