Re: PATCH vs PUT w/Content-Range

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

Received on Wednesday, 28 April 2004 17:42:08 UTC