[Standards] Request HTTP upload slots over XMPP

Sam Whited sam at samwhited.com
Sat Jul 4 22:07:30 UTC 2015


On Sun, Jun 28, 2015 at 7:25 AM, Daniel Gultsch <daniel at gultsch.de> wrote:
> I would like to get some comments before I actually put this down into a
> XEP.

After playing with this a bit today, the only real requirement that I
don't like from the initial spec is that the GET URL be known when the
HTTP upload slot is requested. Eg. one might imagine the situation
where the server is storing the file in blob storage for the sake of
having deduplication (eg. storing the files as `file_sha1') and does
not care about the original filename. Eg. the get request might be
`download.domain.tls/file_sha1'. Since the file hash won't be known by
the server until after the upload is complete, it would be nice if the
GET URL could optionally be deferred until the upload is complete.
Maybe via another IQ requesting the GET URL which the client could
initiate when it finishes uploading, or via the initial PUT's
response. This effectively changes the verb from PUT to POST (since
we'd be letting the server decide the final name for the object we're
creating, and we have no way to "update" that object later).

I'd also like to see some way to provide the client with some HTTP
headers to use when uploading. Eg. the server might want to delegate
the upload to some API. Let's say that API requires authentication via
an oauth token, the server could send down the PUT URL (eg.
'api.someservice.tld/a_piture.webp'), and an HTTP header which the
client should use to auth to the service (eg. "Authentication: Bearer
one_time_use_oauth_token").

Using HTTP upload allows the server to receive the upload itself (if
supported), or to delegate the upload elsewhere (without having to act
as a proxy). This probably wouldn't be the case if the upload
mechanism were Jingle File Transfer. For this reason, I like the idea
of keeping this proposal entirely HTTP based (I think, I keep changing
my mind).

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com



More information about the Standards mailing list