[Standards] Proposed XMPP Extension: HTTP File Upload

Matthew Wild mwild1 at gmail.com
Mon Jul 27 16:28:23 UTC 2015

On 27 July 2015 at 17:01, Sam Whited <sam at samwhited.com> wrote:
> 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'll just quickly note that I don't see any security advantage to a
token in a header (if we're always over HTTPS, which I assume we are
if we care about this). The attacker guessing an unpredictable URL is
no different to an attacker guessing an unpredictable auth token.


More information about the Standards mailing list