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, 6 June 2008 08:04:28 GMT