W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: PATCH vs PUT w/Content-Range

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 14:41:51 -0700
Message-Id: <DBEF17F2-995C-11D8-B566-000A95B2BB72@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>, greg stein <gstein@lyra.org>
To: Justin Chapweske <justin@chapweske.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:30 GMT