[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: smart upload server



Hi Petr,

On Mon, May 24, 2010 at 11:25 AM, Petr Jašek <jasekpetr@gmail.com> wrote:
> The first thing i need to work out is what exactly should be send
> between server/client. My basic idea about commands is like:
>
> 1) client > server: BEGIN + .changes_file
> 2) server > client: OK or ERROR + error_message (bad signature, old etc.)
>
> and then foreach file in .changes
> 3) client > server: FILE + file content
> 4) server > client: OK or ERROR + error_message

sounds good so far.

What HTTP methods do you want to use? PUT, POST, or GET (PUT is
probably most appropriate)? It would be a good idea to not implement
methods that are not needed like TRACE that are vulnerable to XST
attacks. Is the protocol stateless? How does the client reference the
changes file in the second and later requests?

Will the protocol support aborted uploads through the Content-Range
header? It would be enough to implement this later but the server's
first response should be modified for that. The server should send
some information about which files and ranges have already been
uploaded.

Two other features that will be implemented later but may influence
the protocol's definition: How will delayed uploads be handled by the
protocol? How about dcut like commands files
(ftp://ftp.upload.debian.org/pub/UploadQueue/README)?

> After that there could be some message to server that it's done, but
> it's unnecessary because he should now that from .changes file.

I don't think that this is needed.

> Server could also ask before file transfer which one he wants to get,
> but I'm not sure if there is any usage (smaller files first maybe).

I cannot find a usecase, too.


Cheers,
Torsten


Reply to: