Subject: RE: I-D for WebDAV methods - APPEND and PATCH

From: "Alex" <[email-masked]>
Date: Wed, 2 Aug 2006 19:12:42 -0700

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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Aug 2006 17:26:59 +0200

Alex schrieb:
> 
> 
> 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 

That's just a generic patch issue. If you define a patch format that 
allows seeking to a specific position and updating the content from 
there, that's sufficient.

> appended? Also how would it work in the context of version control.

The same way as PUT? (same for locking, ACLs, whatever).

 > ..

Best regards, Julian

---

From: "Suma Potluri" <[email-masked]>
Date: Fri, 4 Aug 2006 00:47:59 -0700 (PDT)

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

---

From: "Alex" <[email-masked]>
Date: Sat, 5 Aug 2006 12:03:38 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Suma Potluri
Sent: Friday, August 04, 2006 12:48 AM
To: Alex
Cc: [email-masked]
Subject: RE: I-D for WebDAV methods - APPEND and PATCH

Hi Alex,

-Suma