- From: Alex <alex@ubudesign.com>
- Date: Sat, 5 Aug 2006 12:03:38 -0700
- To: "'Suma Potluri'" <suma@soe.ucsc.edu>
- Cc: <w3c-dist-auth@w3.org>
Hi Suma, Actually I am not sure of how the client should behave. On the server side it wouldn't matter if it was some sort of a pause request or any error during the PUT or even a previous APPEND. Of course http does not keep the connection open so for the server it always looks like an error. If the server wants to support APPEND with "resume" option then it should maintain logs of these errors and partial transfers in some temporary location and maybe with some sort of expire date too. What I think is this: 1. The client should know that it had made an APPEND or PUT request. 2. Something stopped it during transfer. Some error or the client stops the transfer. 3. It then has two things to choose from A. Another new PUT B. A PROPFIND with request for info about the status of that last resource. On the server if it supports APPEND with resume then it maintains information about partial transfers. So it would respond by providing that information in a PROPFIND regardless of this resource being an existing or non existing temporary resource is. and then the client can send a APPEND from that section on... Of course if the server supports the resume of APPEND it would need to maintain the information about the partial data in a temporary location and log those rather then make it like normal resources displayed to client. I'm not sure of those details. For partial GET it would be very simple if the server supports sending partial data. This is not a very well thought idea on my part but I think resume is more usable then append alone as it also takes care of transfer errors but here is a pseudo example not very well written but just to give you my idea and I am not sure how it would effect other things. Client Request: PUT /somefile --- Something stops the transfer Client: Request PROPFIND /somefile Server Responds: not found Client: Request PROPFIND for property let say "resume" of /somefile (knowing that APPEND is an OPTION and there was some error in a previous PUT) Server Responds: MULTISTATUS partial data exists and some status of what happened for this and any error info etc Client: Requests APPEND and the "resume" of the parts of /somefile -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Suma Potluri Sent: Friday, August 04, 2006 12:48 AM To: Alex Cc: w3c-dist-auth@w3.org Subject: RE: I-D for WebDAV methods - APPEND and PATCH Hi Alex, The initial idea for the APPEND method was to perform a basic append. Could you be more specific on what kind of a behaviour you are expecting when you say pause/resume like in ftp? Do you expect the server to return the size of the data appended so far when paused? And how do you pause it (when the connection was lost??) Maybe I am missing something here. -Suma > Would it be possible to use APPEND similar to pause/resume like in ftp? If > so then maybe a start point of the byte from which it's being appended? > Also > how would it work in the context of version control. > > > > Maybe I am not understanding it that well and thinking of it differently > but > even as basic append it's a great idea. > > > >
Received on Saturday, 5 August 2006 19:04:03 UTC