Re: Re: smart upload server
Hi Torsten,
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.
I'm thinking of PUT for files and GET for commands. Or maybe combine both
two
and use just POST, which could make easier implementation for other
transport protocols.
What do you think?
Is the protocol stateless? How does the client reference the
changes file in the second and later requests?
Stateless if possible, with some time window for each changes file,
checksums are on server so he knows what should come.
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.
Hope so, I'll look at it and update the protocol.
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)?
There should be command requests, by them you can control it like with
command
files.
Something like:
client > server: COMMAND + command (format like in file?)
server > client: OK or ERROR with some message
Thanks,
Peter
Reply to: