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. Best, Sam 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. > -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
