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