On Sun, Jun 28, 2015 at 7:25 AM, Daniel Gultsch <[email protected]> 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
