[Standards] Proposed XMPP Extension: HTTP File Upload

Mickaël Rémond mremond at process-one.net
Mon Jul 27 17:03:18 UTC 2015


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 

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 

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 

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

> On Mon, Jul 27, 2015 at 9:37 AM, XMPP Extensions Editor 
> <editor at 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.

More information about the Standards mailing list