Re: PATCH vs PUT w/Content-Range

On Wed, Apr 28, 2004 at 02:41:51PM -0700, Lisa Dusseault wrote:
>...
> I do mention one reason in the draft -- the problem of write-through 
> caches.  The cache (if an intermediary) could see a PUT with a body and 
> save the body as the new body for the resource, even though the PUT 
> request body is only a diff or content range.  Greg Stein expressed

Right. The intermediaries aren't *supposed* to do that, but if one does...
BAM. You're SOL.

> this better than me: PUT works a certain way, and has been known to 
> work a certain way for at least a decade, and it's very difficult to 
> change its semantic meaning without breaking things.
> 
> Another concern I have is that HTTP servers that allow PUT may ignore 
> the Content-Range header since it's not defined as a PUT header.  This

And in fact, a good number of them *do* ignore the header. When the Apple
guys were building their DAV filesystem client, they ran into this
problem. And it is a major pain -- if an app changes a single byte, you
really don't want to have to do a PUT on that entire 3 gig file. I'm not
sure what solution they ended up with, but the general solutions says that
you cannot trust a proper response from the server.

Now, the HTTP spec says that an unhandled and/or not-understood Content-*
header should generate an error response. Most servers don't follow that
requirement, however. IIS/6 and Apache certainly don't. (I just tested the
former against www.microsoft.com, and I already know Apache doesn't)
So... since a server isn't going to punt on an unhandled Content-Range,
then you really can't rely on just sending it and assuming the server will
fail back to you if it doesn't understand it.

> is even worse -- the authoritative source will then replace the full 
> resource with a corrupted, partial resource.  I suspect clients have 
> tried this already and found it not to work in practice.  Similarly,

Yep and yep.

> HTTP servers that support PUT today simply won't understand a new 
> header defined in an extension draft.  It *might* work for the client 
> to ask the server for support for the header on the specific resource 
> that the client would like to alter, before using PUT -- but that 
> wouldn't solve the intermediary or cache misunderstanding problems.

Agreed, especially given the problems around proper Content-* header
handling. IMO, we simply need a new method designed which explicitly
accounts for these different behaviors (along with definitions for
intermediaries' handling).

Cheers,
-g

> Lisa
> 
> On Apr 28, 2004, at 2:26 PM, Justin Chapweske wrote:
> >
> > Hello Lisa,
> >
> > Could you please expound upon the reasons why PUT with a Content-Range
> > is a dangerous operation?  In your draft you state:
> >
> >    The PUT method is already defined to overwrite a resource with a
> >    complete new body, and MUST NOT be reused to do partial changes.
> >    Otherwise, proxies and caches and even clients and servers may get
> >    confused as to the result of the operation.
> >
> > But it is not clear to me why this is a problem.  I would appreciate
> > your thoughts on this issue, and it may be worthwhile to expound upon 
> > it
> > a bit in your draft.
> >
> > Thanks,
> >
> > -Justin
> >
> > -- 
> > Justin Chapweske - Founder, Onion Networks
> > http://onionnetworks.com/
> > 651-340-8787
> >
> > Transfer large files 900% faster than FTP with Onion Networks' WAN
> > Transport(tm).  http://onionnetworks.com/products_wantransport.php

-- 
Greg Stein, http://www.lyra.org/

Received on Wednesday, 28 April 2004 19:28:21 UTC