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

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

Received on Monday, 30 September 2013 14:14:05 UTC