[Standards] Proposed XMPP Extension: HTTP File Upload

Sam Whited sam at samwhited.com
Mon Jul 27 16:01:58 UTC 2015

As mentioned off list, I have two concerns with the protocl as it stands:

While the simplicity is laudable, the proposals use is extremely
limited by the fact that headers can not be defined. I would like to
see a methohd for passing down arbitrary headers which should be sent
with the PUT request. This would allow a few different use cases:

1) Authenticated requests (eg. generate a 1 time use oauth token, tell
the client to use an `Authentication: Bearer <token>` header)
2) Easily match signed requests; I did an example implementation where
the server delegated storage to Amazon S3. The server would generate a
pre-signed upload URL with a limited TTL, then the client would make a
PUT to this URL. However, the headers did not match, so I had to
modify the client to add a Content-Type header which was required by
Amazon. Other headers might be required as well, and this would mean
implementaitons which use services like this would only be compatible
with certain clients
3) It would allow (in the simplest case) for sending down a nonce over
XMPP which the client would send back up, thereby validating that the
client is actually the one doing an upload (and the URL wasn't just
guessed by an attacker).

I don't think this would add a great deal of complexity to the
protocol, but it does make it much more powerful.

My second (and less pressing) concern is that the GET url must be
known up front. One can imagine the case of a blob storage service
which stores files by hash and does not want to maintain
infrastructure to map hashes to filenames. They would not know the
final GET url (eg. myservice.tld/somefilehash) until after the file
had been uploaded. To fix this an optional to support IQ should be
added. If the file name is not available, a random token or other
means of looking up the file would be sent down instead of the <get>
request (or it could always be sent down if your server supports it),
then, after the client performs the PUT it could send an IQ requesting
the GET url with that token as an identifier. This also does not add a
lot of complexity to the XEP, but would require that XMPP server
implementors (not storage providers) maintain a mapping of that random
token to GET url's (these could also have a timeout so that they don't
need to be stored very long). If this is optional and a server DOES
always know the GET URL up front, they could ignore it and return a
not-implemented error if the client sends this IQ.


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.

Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list