Hello,
Interesting talk, I would like to contribute a bit to the discussion.
A bit of context: we (at ProcessOne) have been working on an HTTP
transfert protocol that is in production for some of our ejabberd SaaS
customers. The goal is to allow to use a third party backend for storage
(like S3) and to let the XMPP server be just a helper to make that
happen.
That said, I am not saying it is perfect, but some of the pitfall we had
to address may be useful to build upon Daniel's proposal if this makes
sense.
The issue we wanted to solve is generally that the server owner will be
paying for the storage, so for obvious reasons the "master key" that
grant access to the storage need to be on XMPP server.
The general workflow is as follow:
1. Sender request an upload URL. XMPP server return an upload URL and a
file ID. This is the step to ensure that the master key is not shared,
as client will only receive a temporary URL, only valid for a given file
(based on its MD5). The requirement for the MD5 could be discussed of
course. At some point we needed it for S3 API upload delegation.
2. Sender upload the file and can share the file ID.
Download URLs are typically not permanent. A storage backend could purge
them or change them. The main reason of that HTTP upload / download
protocol is to be asynchronous. We do not know when the receiver will
receive the file notification (when back online) so we needed to cope
with possibly changing file URL.
Moreover, with a service like S3, the download URL is not permanent.
Having a file ID allow us to decouple the file from the actual download
URL.
3. The receiver ask the XMPP server and URL based on the file ID.
It has two benefits:
- The XMPP server can use the "master key" to generate a temporary URL.
- If the server wants to do some XMPP level credentials checks it is
possible (but not mandatory).
- It protect against leaked URL having the file "permanently" available
to any third-party.
I think this should address a few of the concerned expressed here, by
Sam, Rick and Evgeny. We may need to open to more straightforward cases,
where the final download URL is constant, but we are willing to help.
I do not think three steps is that complex, but, tell me :)
The plan is that we publish the doc on what we have tomorrow on Github
(We need to convert to Markdown). That will makes things clearer and
maybe we can pick a few ideas from there for the XEP.
I hope this helps,
--
Mickaël Rémond
http://www.process-one.net/
On Mon, Jul 27, 2015 at 9:37 AM, XMPP Extensions Editor
<edi...@xmpp.org> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: HTTP File Upload
Abstract: This specification defines a protocol to request permissions
from another entity to upload a file to a specific path on an HTTP
server and at the same time receive a URL from which that file can
later be downloaded again.
URL: http://xmpp.org/extensions/inbox/http-upload.html
The XMPP Council will decide in the next two weeks whether to accept
this proposal as an official XEP.
