[Standards] Proposed XMPP Extension: HTTP File Upload

Mickaël Rémond 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.

Mickaël Rémond

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

More information about the Standards mailing list