[Standards] Proposed XMPP Extension: HTTP File Upload
mremond at process-one.net
Tue Jul 28 15:11:21 UTC 2015
As a follow up, as promised, here is what we have implemented and tested
with Amazon S3:
I hope you will find some ideas could be valuable for Daniel's proposal.
On 27 Jul 2015, at 19:03, Mickaël Rémond wrote:
> 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
> 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
> - 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
More information about the Standards