Re: PATCH vs PUT w/Content-Range

On Apr 28, 2004, at 4:41 PM, 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 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 
> 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, 
> 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.
>
> 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

On Apr 28, 2004, at 6:27 PM, Greg Stein wrote:

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

<http://lists.w3.org/Archives/Public/ietf-http-wg/1997OctDec/0011.html> 
gives the reason why PUT-RANGE wasn't left in the HTTP 1.1 
specification and 
<http://www.w3.org/Protocols/HTTP/Issues/BeforeLastCall.html#PUT-RANGE> 
is where PUT-RANGE was officially removed from Rev-02 of the HTTP 1.1 
spec.

Yes, Apple's WebDAV file system client still has to deal with the 
performance problems of not having better range operations. When a 
large resource is  opened, modified and closed by a file system client, 
the entire resource has to be downloaded with a GET and then 
re-uploaded to the server with a PUT -- even if just a single byte is 
changed.

I like the PATCH proposal because it provides clients with:

1 - The ability to change the size of a resource independent or in 
addition to changing the data. PUT doesn't do this unless you change 
the current meaning of the byte-content-range-spec passed in a 
Content-Range header so that */100 means "set the length of the 
resource to 100 -- truncate the resource if its current length is more 
than 100, zero extend the resource if its current length is less than 
100".

2 - The ability to change multiple ranges and optionally the size of a 
resource with a single request. On high latency connections, our 
performance problems are often causes by the number of transactions, 
not the amount of data transfered.

Received on Thursday, 29 April 2004 11:58:09 UTC